Да, в текущей реализации есть хитрый момент. Всё лишнее копится в буфере tty и отыгрывается потом. Зажмите стрелку на секунду — и машина продолжит ехать вбок ещё некоторое время после того, как вы отпустили. Это один из моментов который нужно проработать при "нормальной" реализации.
Я тоже одно время так думал. Но потом понял, что это ощущение не исчезло — оно просто переезжает в новые области.
Сначала для меня это была мобильная разработка, где долгое время приходилось экономить память, батарею и вычислительные ресурсы почти как в старые времена. Потом появились микроконтроллеры — и там снова вернулся тот самый кайф от работы в условиях жёстких ограничений.
Мне кажется, «радость простого программирования» не исчезает, она просто каждый раз находит новую среду.
А для кого-то сегодня похожие ощущения даёт вайб-кодинг: ты не погружаешься в детали реализации, а оркестрируешь процесс с помощью простых концепций. Лично мне такой подход не близок, но понимаю, почему некоторым он приносит те же эмоции.
Спасибо! 🙂 Но под «подключить библиотеку» я скорее имел в виду игровые движки и фреймворки вроде pygame, Godot и им подобные. Здесь же только стандартная библиотека Python, без каких-либо игровых зависимостей.
А про ZX Spectrum и остальное — очень понимаю этот вайб. Помню, как уже на 286 приходилось буквально бороться за каждый байт памяти: оптимизировал загрузчик, не загружал в ОЗУ то, что во время игры было не нужно, лишь бы освободить место для очередного уровня. Тогда такие микрооптимизации ощущались как настоящее инженерное достижение.
Прекрасно! Задумка сработала! Ряд таких "недочетов" там специально оставлена, чтобы у внимательных читателей был повод придраться, предложить улучшения и почувствовать себя ревьюером. Там есть ещё! :)
@homm Полностью согласен. Именно так я и поступаю на своих собеседованиях. Однако важно уточнить, что статья не о самих вопросах, а об особенностях языка, которые необходимо понимать перед собеседованием. Большинство вопросов и задач как раз строятся вокруг этих особенностей, поэтому их знание и понимание действительно имеет значение.
Ну так роли ведь разные бывают. Если человек идёт на позицию, где важен матан, то его сильная сторона как раз там — и логично, что пробелы по питону не критичны. А если наоборот — вакансия завязана на кодинге и питон основной инструмент, то странно игнорировать, что кандидат путается в базовых вещах. Не спросишь же у питон-разработчика интегралы, просто потому что “вдруг знает матан”.
Да, вы правы — в Python логическая интерпретация объектов не ограничивается только пустыми коллекциями, 0, None и False. У классов действительно могут быть определены специальные методы, которые задают собственное поведение в логическом контексте. Я упрощённо сформулировал мысль, чтобы подчеркнуть стандартные “ложные” значения, но стоит уточнить, что механизм шире.
Собственно, в этом и заключается суть — речь идёт о поведении именно функций, и неважно, как они определены: через lambda или через def. Особенность позднего связывания одинаково проявляется в обоих случаях.
Пример с funcs.append(lambda: i) действительно выглядит искусственным — тут нет никакой необходимости в функциях, можно хранить сами значения. Но как только задача сводится к тому, чтобы зафиксировать часть аргументов (а остальные подставлять при вызове), мы вынуждены оперировать именно функциями. И тогда уже приходится либо использовать аргументы по умолчанию, либо functools.partial, либо ещё что-то.
В данном случае суть проблемы не в том, что используется lambda — её хоть сразу перепиши на именованную функцию, особенность позднего связывания от этого никуда не денется. Чтобы избежать эффекта, нужно явно “фиксировать” значение переменной в момент создания функции, например через аргументы по умолчанию.
На самом деле a += [3] эквивалентно не append, а extend.
То есть правильнее сравнивать:
a += [3] # [1, 2, 3]
a.extend([3]) # [1, 2, 3]
А append() в этом случае даёт другой результат:
a.append([3]) # [1, 2, [3]]
Пример с += был больше как иллюстрация того, что оператор перегружен и работает со списками, а не как рекомендация к применению. В реальном проекте я бы тоже наругал за это.
Работать или нет в такой компании где задают подобные вопросы на собеседовании - это ваш выбор, и я ничего не имею против него. Но если у вас есть конкретные предложения по улучшению описания оператора +=, то будет здорово их увидеть.
На собеседованиях действительно можно услышать очень разные вопросы, и многое зависит и от роли, и от контекста, и от конкретного интервьюера (в том числе его настроения). Собеседование - это всегда субъективная история. Но есть ряд вещей в Python, знание и понимание которых показывает уровень зрелости разработчика — и именно про такие моменты статья.
Я и сам неоднократно сталкивался с этими вопросами, когда проходил интервью, и сейчас иногда задаю их кандидатам - живые примеры у меня на канале. Конечно, не всё подряд и не всем, а исходя из позиции и задач.
Попытка засчитана, код работает, но там конечно много чего нужно править, оставил замечания по самым критичным моментам в issues
Да, в текущей реализации есть хитрый момент. Всё лишнее копится в буфере tty и отыгрывается потом. Зажмите стрелку на секунду — и машина продолжит ехать вбок ещё некоторое время после того, как вы отпустили. Это один из моментов который нужно проработать при "нормальной" реализации.
Неплохо. Но вот тут у вас сейчас потенциальная ошибка
if direction == ‘RIGHT’:car = car + 1 if car < WIDTH else WIDTH - 1
Да, всё так! 🙂 Но, как я и упоминал в статье, с "нормальным" подходом мы быстро выйдем за лимит в 50 строк, который здесь был одним из условий.
И это, кстати, далеко не всё, что бросается в глаза в этом коде. Есть ещё несколько моментов, которые можно улучшить или сделать более идиоматичными.
Я тоже одно время так думал. Но потом понял, что это ощущение не исчезло — оно просто переезжает в новые области.
Сначала для меня это была мобильная разработка, где долгое время приходилось экономить память, батарею и вычислительные ресурсы почти как в старые времена. Потом появились микроконтроллеры — и там снова вернулся тот самый кайф от работы в условиях жёстких ограничений.
Мне кажется, «радость простого программирования» не исчезает, она просто каждый раз находит новую среду.
А для кого-то сегодня похожие ощущения даёт вайб-кодинг: ты не погружаешься в детали реализации, а оркестрируешь процесс с помощью простых концепций. Лично мне такой подход не близок, но понимаю, почему некоторым он приносит те же эмоции.
Спасибо! 🙂 Но под «подключить библиотеку» я скорее имел в виду игровые движки и фреймворки вроде pygame, Godot и им подобные. Здесь же только стандартная библиотека Python, без каких-либо игровых зависимостей.
А про ZX Spectrum и остальное — очень понимаю этот вайб. Помню, как уже на 286 приходилось буквально бороться за каждый байт памяти: оптимизировал загрузчик, не загружал в ОЗУ то, что во время игры было не нужно, лишь бы освободить место для очередного уровня. Тогда такие микрооптимизации ощущались как настоящее инженерное достижение.
Прекрасно! Задумка сработала! Ряд таких "недочетов" там специально оставлена, чтобы у внимательных читателей был повод придраться, предложить улучшения и почувствовать себя ревьюером. Там есть ещё! :)
Я думаю можно попробовать, и скорее всего получится, но будет очень минималистично :)
Ну должен же ИИ хоть на чём-то учиться :)
@homm Полностью согласен. Именно так я и поступаю на своих собеседованиях. Однако важно уточнить, что статья не о самих вопросах, а об особенностях языка, которые необходимо понимать перед собеседованием. Большинство вопросов и задач как раз строятся вокруг этих особенностей, поэтому их знание и понимание действительно имеет значение.
Ну так роли ведь разные бывают. Если человек идёт на позицию, где важен матан, то его сильная сторона как раз там — и логично, что пробелы по питону не критичны. А если наоборот — вакансия завязана на кодинге и питон основной инструмент, то странно игнорировать, что кандидат путается в базовых вещах. Не спросишь же у питон-разработчика интегралы, просто потому что “вдруг знает матан”.
Спасибо за комментарий!
Однако добавлю, что это пока не исключение, а предупреждение (SyntaxWarning) — просто на уровне языка теперь обращают внимание на такие случаи.
Вообще, 3.14 принесла много интересных изменений, надо будет отдельно про них написать!
Да, вы правы — в Python логическая интерпретация объектов не ограничивается только пустыми коллекциями,
0,NoneиFalse. У классов действительно могут быть определены специальные методы, которые задают собственное поведение в логическом контексте. Я упрощённо сформулировал мысль, чтобы подчеркнуть стандартные “ложные” значения, но стоит уточнить, что механизм шире.Собственно, в этом и заключается суть — речь идёт о поведении именно функций, и неважно, как они определены: через lambda или через def. Особенность позднего связывания одинаково проявляется в обоих случаях.
Пример с funcs.append(lambda: i) действительно выглядит искусственным — тут нет никакой необходимости в функциях, можно хранить сами значения. Но как только задача сводится к тому, чтобы зафиксировать часть аргументов (а остальные подставлять при вызове), мы вынуждены оперировать именно функциями. И тогда уже приходится либо использовать аргументы по умолчанию, либо functools.partial, либо ещё что-то.
В данном случае суть проблемы не в том, что используется lambda — её хоть сразу перепиши на именованную функцию, особенность позднего связывания от этого никуда не денется. Чтобы избежать эффекта, нужно явно “фиксировать” значение переменной в момент создания функции, например через аргументы по умолчанию.
На самом деле a += [3] эквивалентно не append, а extend.
То есть правильнее сравнивать:
А append() в этом случае даёт другой результат:
Пример с += был больше как иллюстрация того, что оператор перегружен и работает со списками, а не как рекомендация к применению. В реальном проекте я бы тоже наругал за это.
Да, вы абсолютно правы!
В Python функция round() по умолчанию использует стратегию округления, называемую “round half to even” (или банковское округление).
Работать или нет в такой компании где задают подобные вопросы на собеседовании - это ваш выбор, и я ничего не имею против него. Но если у вас есть конкретные предложения по улучшению описания оператора +=, то будет здорово их увидеть.
На собеседованиях действительно можно услышать очень разные вопросы, и многое зависит и от роли, и от контекста, и от конкретного интервьюера (в том числе его настроения). Собеседование - это всегда субъективная история. Но есть ряд вещей в Python, знание и понимание которых показывает уровень зрелости разработчика — и именно про такие моменты статья.
Я и сам неоднократно сталкивался с этими вопросами, когда проходил интервью, и сейчас иногда задаю их кандидатам - живые примеры у меня на канале. Конечно, не всё подряд и не всем, а исходя из позиции и задач.