Comments 23
Все это очень интересно, но причем тут собеседование? Вам разработчики нужны или стрессоустойчивые теоретики?
Upd: А, я понял, это же реклама курсов, типа как подготовить нормального разраба к типичному собеседованию.
У нас в голландском языке есть емкое слово "mierenneuker", что в буквальном переводе означает "тот, кто трахает муравьев". Общеупотребительное значение: "тот, кто придирается к мелочам."
Просьба к интервьюерам: не будьте такими.
Именно!
Люблю такие комментарии. И да, статья именно об этом! Мы никогда не знаем что нас могут спросить на интервью и зачастую интервьюеры начинают фокусироваться на каких-то частных деталях конкретной реализации отдельно взятого языка. Так конечно не стоит делать (если конечно это не относится напрямую к будущим задачам). А тут я как раз таки и попытался собрать и показать подобные примеры из практики прохождения интервью студентами.
А знаешь, каков максимальный размер списка в Python??
«Нет и не должен, потому что я хорошо знаю, что на практике это чисто справочная величина. Когда она нужна, я сверяюсь с мануалом. Я знаю, что я не должен это на память знать».
Всё так! Об этом и речь! Современные интервью зачастую наполнены вызовами, которые мало коррелируют с реальными задачами на рабочем месте. Искусственные задачи и запоминание мелких деталей, которые легко можно найти в документации, не демонстрируют реальный уровень компетенции кандидата. В конце концов, в реальных рабочих ситуациях успех зависит не от того, сколько мелких фактов вы помните наизусть, а от вашей способности понимать суть задачи и находить решения, опираясь на доступные ресурсы.
Судя по результатам моих непродолжительных поисков, это не справочная величина, и в мануале ее нет. SO говорит про константу в коде, но она зависит от разрядности и, судя по всему, всегда превосходит объем максимально адресуемой при этой разрядности памяти.
Поэтому правильным ответом должно быть "максимальный размер коллекции ограничен объемом оперативной памяти", чего, в общем-то, и следовало ожидать.
Я прямо сходу предположил, что размер завязан на INT_MAX, и, в общем-то, оказался прав более-менее.
В реализации listobject не видел в полях структуры ссылок на внутреннюю реализацию Int, которая не ограничена по хранимому значению и не переполняется, иначе бы сильно удивился и запомнил бы этот момент. Следовательно, поле "текущий размер" может быть объявлено никак иначе, кроме как через стандартные сишные числовые типы, а в максимуме это, собственно, INT_MAX. Для беззнаковых, соответственно, UINT_MAX, кажется. В любом случае, с порядком не ошибся.
Объем адресуемой памяти в данном случае "всегда" не может быть превышен. Вот именно потому, что не используется магия, увеличивающая разрядность максимально доступного числового типа в С.
Пример с bytearray не показателен в данном случае, потому что он не List, о котором был вопрос.
--
Что касается самой статьи, то про механику возврата из логических выражений могу сказать чуть более понятно. Кто не видел/писал кода вида:
a = a or b
А это вот оно и есть.
Добавлю: -Python компилируемый или интерпретируемый? (После очевидного ответа "интерпретируемый", следует вопрос -А что такое файлы .pyc, который появляются, когда запускаешь python файл?)
Python - это интерпретируемый язык, основной (дефолтный) интерпретатор которого, относится к типу компилирующих. То, что интерпретатор производит промежуточную компиляцию перед выполнением на виртуальной машине, не делает язык компилируемым. Это как наличие ног: оно не превращает вас в танцора.
Но тут внезапно CPython начал компилировать в машинный код
В альфа выпуск языка программирования Python 3.13.0a6 встроен JIT-компилятор
JIT компилятор - это тоже одна из особенностей реализации интерпретатора компилирующего типа. Ключевой момент здесь - CPython (интерпретатор) перешëл на использование JIT компиляции. Вот когда CPython станет компилятором, тогда можете говорить, что Python - компилируемый язык. Потому, что код, написанный на нëм, перед запуском, будет компилироваться в байт-код и кладываться в библиотечки, а потом они будут выполняться при запуске исполняемого файла. А сейчас программа на Python запускается по-умолчанию интерпретатором Python. Нельзя взять файлы .pyc, перенести на другую машину с аналогичной архитектурой и выполнить их без интерпретатора. Поэтому, язык и называется интерпретируемым.
Если что - я с вами не спорил. Просто хотел заметить, что словосочетание "промежуточную компиляцию перед выполнением на виртуальной машине" постепенно перестает быть определяющим.
Формально, да, грани между языками по типу исполнения стираются. Но, прошу обратить внимание, что если вы на собесе зададите этот вопрос кандидату, он сможет перевернуть его в свою пользу чисто психологически. Просто компиляция может быть этапом интерпретации. Ключевое здесь, всë-таки - это запуск программы. Интерпретируемые языки выполняются при помощи интерпретатора при каждом запуске. Даже если вы соберëте .exe, в нëм будет ваша программа, + код интерпретатора для запуска. А компилируемую программу можно переносить и запускать независимо от наличия компилятора на целевой машине.
Плюс, JIT компиляция не перестаëт быть промежуточной. Она, точно так же, выполняется между запуском интерпретатора и выполнением кода на виртуальной машине. Просто она не хранит .pyc файлы на диске, и не производит компиляцию заранее. Если вы будете пытаться рассказать кандидату, понимающему это, про то, что JIT- компиляция - не промежуточная, то, боюсь, вы потеряете этого кандидата.
Почему я спорю? Наверное, потому, что вопрос про компилируемость Python - это очень популярный маячок, показывающий приверженность разработчика к хайповым высказываниям без проверки истинности. Все сейчас носятся с этим бредовым "Python - компилируемый язык, вы слыхали"?! Хотя, тут достаточно начать спрашивать про то, какие бывают типы интерпретаторов, и почему интерпретаторы компилируемого типа не перестают быть интерпретаторами? Вот это, действительно серьёзные вопросы. Несколько фактов, которые я вам привëл, в частности, о том, что интерпретируемый язык не позволяет собрать программу для запуска без библиотек интерпретатора, в принципе, уже вывели вас из себя и вынудили увести разговор в сторону от спора.
Ага, это ещё один очень хороший и яркий пример из списка подобного рода вопросов. Конечно, это полезно знать и понимать и для кругозора и в целом, но к реальным задачам по написанию кода и решению задач при помощи кода зачастую не имеет никакого отношения.
Опытный разработчик при получении подобного вопроса должен просто встать и уйти. Пусть случайнозабежавший сотрудник кодит
Эзотерические вопросы -- хороший способ направить воронку подбора персонала к лесу передом, к себе задом.
- Не знаю. И сколько?
И тут может наступить неловкая пауза.
Использование символа _ для ненужных переменных в распаковке/цикле вообще довольно холиварный вопрос. С одной стороны действительно для читаемости довольно удобно, с другой - это всё ещё присваивание значения конкретному символу (как-то видела комментарий, что можно и в print присваивать значения, но зачем?). Ну и gettext принято импортировать как _ (что лично я нахожу странным, но так уж сложилось)
В начале задали вопрос. А затем на него не ответили. Потому спрошу в комментариях "каков максимальный размер списка в Python"?
Банановые шкурки на интервью Python-разработчика