У меня вопрос не в тему, Сколько закладывать времени на переезд 2-> 3 для Джанго проекта? Я бы месяца 2 попросил

куда-нибудь, откуда будет 100% выполняться эта строчка и где она тебе будет нужна

мне надо что бы из папки src все py файлы видели сраный модуль из папки libs/resto http://i.imgur.com/Rkuowg7.png

про вторую часть - бред

Я по личному опыту сужу.

А что вообще должен знать джуниор при устройстве в какую-то компанию?

? not again

А что вообще должен знать джуниор при устройстве в какую-то компанию?

Как мы выше выяснили — диапазон ну очень широкий.

У меня вопрос не в тему, Сколько закладывать времени на переезд 2-> 3 для Джанго проекта? Я бы месяца 2 попросил

даже месяца имхо должно хватить по уши

Хэх

больишнство либ должно поддерживать третий питончик

Джун в некоторых случаях котируется как миддл в других.

даже месяца имхо должно хватить по уши

Включая Джанго селери, море обвеса, и даже фабрик?

Джун в некоторых случаях котируется как миддл в других.

всё так. это я говорю как человек, который после трех лет мидлованья стал джуном, просто хуево пройдя собеседование

А что вообще должен знать джуниор при устройстве в какую-то компанию?

Основы языка. Что-то больше спрашивать у джуниора особо смысла нет. Ну может ещё такие вещи как алгоритмы и структуры данных.

всё так. это я говорю как человек, который после трех лет мидлованья стал джуном, просто хуево пройдя собеседование

Все бы джуниоры как ты были ?

Включая Джанго селери, море обвеса, и даже фабрик?

фабрик - standalone хуета, она не должна зависеть от версии питончика

ты еще supervisor на третеьм питоне потребуй, блядь

ты еще supervisor на третеьм питоне потребуй, блядь

ВОТ ЩАС ВОЗЬМУ

Основы языка. Что-то больше спрашивать у джуниора особо смысла нет. Ну может ещё такие вещи как алгоритмы и структуры данных.

Простейшие алгоритмы обязательно спрашивать, ящитаю.

ну хууууй знает

вы на потенциал смотрите, а не на то, что чувак заучка

Простейшие алгоритмы обязательно спрашивать, ящитаю.

А какие к примеру алгоритмы?

сортировки, очевидно

А какие к примеру алгоритмы?

Да элементарно пузырёк, фиббоначи, сумма последовательности.

bubble, quick, merge

поиска - опционально

bubble, quick, merge

только хотел про пузырек написать ))))

фиббоначи - да

bubble, quick, merge

Ну не, бабл достаточно.

не согласен quick или merge sort надо представлять хотя бы

если скажешь что в питоне timsort - заебись

Вообще открываешь acmp.ru, сортируешь по сложности и даёшь решить те задачи, которые до, ну скажем, 50% сложности (хотя там есть на 20%, которые я не могу решить, а есть и на 80% которые решал за 5 минут).

> а 20%, которые я не могу решить, а есть и на 80% которые решал за 5 минут парето сюда отлично вписывается ))

> а 20%, которые я не могу решить, а есть и на 80% которые решал за 5 минут парето сюда отлично вписывается ))

Вообще не вписывается. Я про процент сложности.

ну и ладно :(

Реальных задач у них, конечно, нет.

Алгоритмы - главное чтоб человек понимал почему Фибоначчи через рекурсию плохо, и что если хочешь искать быстрее чем за линию нужно использовать какую-нибудь структуру данных. Понимал, что в питоновской лист добавлять последовательно много элементов нельзя, будет аллокация. Лучше использовать сет, если порядок не важен.

парни, горю, ну не видит он эту либу, сделал вот так http://i.imgur.com/01w1AOi.png

вот структура http://i.imgur.com/AqckdK8.png

Алгоритмы - главное чтоб человек понимал почему Фибоначчи через рекурсию плохо, и что если хочешь искать быстрее чем за линию нужно использовать какую-нибудь структуру данных. Понимал, что в питоновской лист добавлять последовательно много элементов нельзя, будет аллокация. Лучше использовать сет, если порядок не важен.

и чтобы понимать, что в сете будет не меньше аллокаций, чем в листе

а также что перестраивание сета при увеличении размера буфера - операция более затратная, чем реаллокация вектора

Да! При чем это важно понимать уже на самом начальном уровне.

(вы ранее написали неправильно)

а также что перестраивание сета при увеличении размера буфера - операция более затратная, чем реаллокация вектора

Кстати как сделан сет в питоне ? Такие же бакеты как и например в java?

Точно) в голове держал поиск...

Да! При чем это важно понимать уже на самом начальном уровне.

Я вот нихуя не понял.

Кстати как сделан сет в питоне ? Такие же бакеты как и например в java?

вроде как словарь из значений в значения на одном буфере с открытой адресацией, но я могу ошибаться

?

А в джаве на списках (точнее походу в джаве 8 это уже не списки, а начиная с большого размера бакета деревья, что делается-то), так что фактически противоположным образом реализованы)

Алгоритмы - главное чтоб человек понимал почему Фибоначчи через рекурсию плохо, и что если хочешь искать быстрее чем за линию нужно использовать какую-нибудь структуру данных. Понимал, что в питоновской лист добавлять последовательно много элементов нельзя, будет аллокация. Лучше использовать сет, если порядок не важен.

Аллокация или релокация?

Алгоритмы - главное чтоб человек понимал почему Фибоначчи через рекурсию плохо, и что если хочешь искать быстрее чем за линию нужно использовать какую-нибудь структуру данных. Понимал, что в питоновской лист добавлять последовательно много элементов нельзя, будет аллокация. Лучше использовать сет, если порядок не важен.

Можно ещё очередь

Алгоритмы - главное чтоб человек понимал почему Фибоначчи через рекурсию плохо, и что если хочешь искать быстрее чем за линию нужно использовать какую-нибудь структуру данных. Понимал, что в питоновской лист добавлять последовательно много элементов нельзя, будет аллокация. Лучше использовать сет, если порядок не важен.

А что тогда делать, если добавлять много элементов нельзя?

Можно ещё очередь

можно, но лист скорее всего будет быстрее

пока мы добавляем только в конец

потому что deque - это двусвязный список из блоков фиксированного размера

получается O(n) аллокаций небольших областей памяти

а вектор (лист) вроде как растет вдвое

а можно делать insert(0) 8)

получается O(log n) реаллокаций увеличивающейся области памяти

а, аллокации все равно будут, да

а можно делать insert(0) 8)

а можно и не делать!

я не знаю, в питоновском списке есть сразу указатель на конец?

эм

Ушёл читать теорию*

что такое питоновский список?

list?

это вектор

ERROR: S client not available

это вектор

Он называется списком

да, просто бессмысленно спрашивать про указатель на конец, если он вычисляется как указатель на старт + размер

ясно. Просто вопрос его реализации. Где-то заявлено, что список это обязательно вектор?

или может попасться какая-нибудь реализация питона, где список это односвязный список?

ну а какую ты можешь придумать структуру данных с о(1) рандомным доступом и амортизированным о(1) аппендом

в жаве вон например LinkedList и ArrayList. И сразу понятно кто какой

а это вроде как заявлено

https://wiki.python.org/moin/TimeComplexity - во чо нашел

current CPython. Other Python implementations (or older or still-under development versions of CPython) may have slightly different performance characteristics.

Other Python implementations (or older or still-under development versions of CPython) may have slightly different performance characteristics. However, it is generally safe to assume that they are not slower by more than a factor of O(log n).

ага

Internally, a list is represented as an array

то есть законом не запрещено, парю где хочу

ну это про CPython

я тебе о том и говорил)

A deque (double-ended queue) is represented internally as a doubly linked list. (Well, a list of arrays rather than objects, for greater efficiency.)

то есть законом не запрещено, парю где хочу

Там вроде в 3.6 же dict меняли

короче deque не сильно хуже list

в смысле добавления в начало или конец или последовательного обхода

Там вроде в 3.6 же dict меняли

если я правильно помню, они просто разнесли ключи и значения по разным местам

вставка в середину там и там дорогая, но по разным причинам

что позволило сократить место на неиспользуемые ячейки

потому что теперь там только ключи

и заодно случайно помогло хранить порядок добавления

потому что в ключах хранятся автоинкрементящиеся индексы значений

короче deque не сильно хуже list

в начало deque лучше list

в конец не сильно хуже

в середину да

теоретически можно сделать деку на основе массива, который просто амортизирован с обеих сторон

наверно такое есть 8)

теоретически можно сделать деку на основе массива, который просто амортизирован с обеих сторон

теоретически да, но тут такая фигня, что если у нас интенсивные например добавление в конец и чтение из начала, наши данные будут ехать вперед и их надо будет регулярно копировать в середину

А в деке можно просто перебрасывать использованные бакеты из начала в конец