Да, вы правы, классическое chained comparison по стандарту описывает <, >, <=, >=.
В примере в статье это не "классическая цепочка сравнений", а обычная комбинация операторов, где == вычисляется первым, а затем результат участвует в сравнении с is. Поэтому Python и интерпретирует выражение как (55 == True) and (True is True)
Скорее всего вы воспринимаете статью слишком буквально :)
Это всего лишь выборка типовых вопросов, которые встречались на собеседованиях. На реальных интервью обычно проверяют гораздо больше аспектов: архитектуру, опыт работы с проектами, умение решать нетривиальные задачи вживую. Так что правильные ответы на все вопросы статьи это круто, но это не означает автоматического статуса "сеньора помидора"
- Нуууу, производительность - Нуууу, можно сделать на этом мемоизацию и еще специфический синглтон
На самом деле это и есть основные принципы зачем так сделано. А почему не сделать по другому - думаю нужно спросить у core девелоперов python. Или эксперты в комментариях подскажут :)
Понимаю, что иногда душа болит за то, что нахватавшиеся по верхам и не знающие корневых принципов работы ЯП хотят многаденяк. Кажется, что без знания некоторых вещей из показанных примеров все-таки можно писать годный код, но я не программист, хоть и приходится писать код на Python иногда.
У каждого свои приоритеты, кому-то просто не хочется потом тратить часы и объяснять на ревью, почему писать if a == True плохо и как работает наследование в python
Однако вот пример с def append_to_list(item, my_list=[]) меня, честно говоря, расстроил. Для меня не интуитивно, что при вызове функции без указания аргумента my_list не происходит создания нового списка и такое поведение интерпретатора мне кажется неправильным. То есть если в каких-то примерах действительно можно поразмыслить и понять, что {x for x in range(3)} -- это не словарь, т.к. тут нет пар key-value, но в примере с append нужно именно знать, что питон -- ленивая задница.
Да, кажется чем-то не очевидным. Но после пары раз, когда эта "ленивая задница" развалит нам весь прод, уже на такие вещи начинаешь смотреть внимательнее
В данном случае приоритет операторов другой: == выше, чем and, а is и and разделены. Python интерпретирует это как (55 == True) and (True is True). Можете проверить в REPL - результат будет False.
Но после этого примера читать статью уже не стал.
Буду рад, если все же дочитаете статью до конца, возможно, там найдете еще что-то полезное :)
Да, может быть ощущение, что рынок усредняет зарплаты и это демотивирует. Но как показывает практика, специалисты, которые растут и развиваются, в итоге уходят в более интересные роли и проекты с совсем другим уровнем ЗП
Знание "базы" само по себе не делает человека хорошим инженером, особенно если оно от "свежих курсов". Эти вопросы служат как быстрый фильтр на базовое понимание, чтобы отделить людей, которые действительно работают с языком, от тех, кто его видел только в теории. А полноценное собеседование, конечно, включает практические и прикладные задачи. В статье лишь выборка
Отвечаю на этот вопрос в комментариях уже не первый раз :) Ни у кого в последствии нет желания, интереса и времени, объяснять на ревью, как работает наследование в python и почему писать if a == True плохо. Собеседование не состоит только из таких задач, это лишь примеры, которые почему-то воспринимаются, как весь собес. Возможно мне нужно было это явно объяснить в статье, хотя мне казалось это очевидным
Это проверка базового понимания языка и инструментов, чтобы убедиться, что человек сможет писать поддерживаемый код без грубых ошибок. После этого в идут более практические и архитектурные задания, где и проявляется мастерство. Никому не интересно впоследствии тратить часы времени на ревью и объяснять, как работает наследование в Python
Встречается, да, особенно если место тепленькое и пригретое. Можно так насидеть 10 лет и ничего не знать
Просто потом никому не хочется исправлять чужие ошибки и чужой код в реальной работе. А также тратить время на ревью и объяснять, почему писать так плохо:
По ту стороны сидят такие же трудяги, которые также могут чего-то не знать. Ну или спрашивать чего сами не знают. Это страх большинства собеседующих, узнать, что кандидат умнее
Добрый день! Благодарю вас за комментарий и за то, что поделились своим опытом. Статья была написана на основе выборки из нескольких сотен собеседований и отражает обобщённые наблюдения, а не эмоции от конкретной ситуации.
Да, согласен, бизнес платит не за красивый код, а за работающий продукт. На собеседовании, как правило есть секция, написать автотесты, в статью это не включал, так как супер специфик кейс, но там тоже все плохо. Речь именно про AQA позиции
Встречаются кандидаты, с умеренным опытом, но как говорится: сразу видно человек "шарит в этой теме" и все у него ок, начиная с теории, заканчивая задачками и практикой. Думаю если кандидат работал 1 - 2 года, но при этом вкладывался в свое развитие, не обязательно на основной работе, он покажет очень хороший результат
Так и вопросы сами по себе не сложные, на уровне решения повседневных задач. Эта статья выборка из нескольких сотен собеседований, и как показывает практика, если на базовых задачах все плохо, про паттерны смысла спрашивать нет. От слова SOLID бросает в ужас
Не всегда так конечно, но частенько бывает. Да и сам процесс не мной придуман)
Иногда кандидаты видят тут подвох и финально отвечают True, потому что не может же быть все настолько просто? Если бы было базовое понимание этих операторов, то сомнение не было
В рамках этой статьи мы работаем с учебным API, который для нас — по сути, black-box. Мы не можем влезть внутрь и посмотреть системные метрики, так как это не наш сервис.
Поэтому в данной статье мы ограничимся клиентскими метриками — теми, которые нам даст HTML-отчёт Locust.
Цель этой статьи — не полноценный анализ архитектуры, а техническая сторона написания хорошо организованных нагрузочных тестов: как структурировать код, как задавать сценарии, как подключать сидинг, как запускать в CI/CD и т.д.
Если у вас есть доступ к системным метрикам (через Grafana, Prometheus, Datadog, NewRelic и т.д.), обязательно подключайте их в связке с Locust. Только так можно получить полную картину производительности.
Спасибо, что вы действительно внимательно прочитали и отнеслись к теме объективно — это очень ценно.
Кажется, что продолжать обсуждение с ним уже не имеет смысла: ни одного конкретного примера, при этом постоянная агрессия, обесценивание и токсичность. Думаю, на этом разумно завершить дискуссию.
Честно, я немного удивлен тому, что в статье есть и другие примеры, но в комментариях все свелось к обсуждению задачи с операторами :)
Да, вы правы, классическое chained comparison по стандарту описывает
<,>,<=,>=.В примере в статье это не "классическая цепочка сравнений", а обычная комбинация операторов, где
==вычисляется первым, а затем результат участвует в сравнении сis. Поэтому Python и интерпретирует выражение как(55 == True) and (True is True)Скорее всего вы воспринимаете статью слишком буквально :)
Это всего лишь выборка типовых вопросов, которые встречались на собеседованиях. На реальных интервью обычно проверяют гораздо больше аспектов: архитектуру, опыт работы с проектами, умение решать нетривиальные задачи вживую. Так что правильные ответы на все вопросы статьи это круто, но это не означает автоматического статуса "сеньора помидора"
Добрый день! Благодарю за комментарий!
На самом деле это и есть основные принципы зачем так сделано. А почему не сделать по другому - думаю нужно спросить у core девелоперов python. Или эксперты в комментариях подскажут :)
Добрый день! Благодарю за ваш комментарий!
У каждого свои приоритеты, кому-то просто не хочется потом тратить часы и объяснять на ревью, почему писать
if a == Trueплохо и как работает наследование в pythonДа, кажется чем-то не очевидным. Но после пары раз, когда эта "ленивая задница" развалит нам весь прод, уже на такие вещи начинаешь смотреть внимательнее
В данном случае приоритет операторов другой:
==выше, чемand, аisиandразделены. Python интерпретирует это как(55 == True) and (True is True). Можете проверить в REPL - результат будетFalse.Буду рад, если все же дочитаете статью до конца, возможно, там найдете еще что-то полезное :)
Да, может быть ощущение, что рынок усредняет зарплаты и это демотивирует. Но как показывает практика, специалисты, которые растут и развиваются, в итоге уходят в более интересные роли и проекты с совсем другим уровнем ЗП
Знание "базы" само по себе не делает человека хорошим инженером, особенно если оно от "свежих курсов". Эти вопросы служат как быстрый фильтр на базовое понимание, чтобы отделить людей, которые действительно работают с языком, от тех, кто его видел только в теории. А полноценное собеседование, конечно, включает практические и прикладные задачи. В статье лишь выборка
Отвечаю на этот вопрос в комментариях уже не первый раз :) Ни у кого в последствии нет желания, интереса и времени, объяснять на ревью, как работает наследование в python и почему писать
if a == Trueплохо. Собеседование не состоит только из таких задач, это лишь примеры, которые почему-то воспринимаются, как весь собес. Возможно мне нужно было это явно объяснить в статье, хотя мне казалось это очевиднымЭто проверка базового понимания языка и инструментов, чтобы убедиться, что человек сможет писать поддерживаемый код без грубых ошибок. После этого в идут более практические и архитектурные задания, где и проявляется мастерство. Никому не интересно впоследствии тратить часы времени на ревью и объяснять, как работает наследование в Python
В статье по мимо примеров с операторами есть еще другие, попробуйте смотреть шире
Встречается, да, особенно если место тепленькое и пригретое. Можно так насидеть 10 лет и ничего не знать
Просто потом никому не хочется исправлять чужие ошибки и чужой код в реальной работе. А также тратить время на ревью и объяснять, почему писать так плохо:
По ту стороны сидят такие же трудяги, которые также могут чего-то не знать. Ну или спрашивать чего сами не знают. Это страх большинства собеседующих, узнать, что кандидат умнее
Добрый день! Как будто тут каждому свое, вкусовщина. С python начать проще, поэтому и выбирают
Добрый день! Благодарю вас за комментарий и за то, что поделились своим опытом. Статья была написана на основе выборки из нескольких сотен собеседований и отражает обобщённые наблюдения, а не эмоции от конкретной ситуации.
Да, согласен, бизнес платит не за красивый код, а за работающий продукт. На собеседовании, как правило есть секция, написать автотесты, в статью это не включал, так как супер специфик кейс, но там тоже все плохо. Речь именно про AQA позиции
Встречаются кандидаты, с умеренным опытом, но как говорится: сразу видно человек "шарит в этой теме" и все у него ок, начиная с теории, заканчивая задачками и практикой. Думаю если кандидат работал 1 - 2 года, но при этом вкладывался в свое развитие, не обязательно на основной работе, он покажет очень хороший результат
Так и вопросы сами по себе не сложные, на уровне решения повседневных задач. Эта статья выборка из нескольких сотен собеседований, и как показывает практика, если на базовых задачах все плохо, про паттерны смысла спрашивать нет. От слова SOLID бросает в ужас
Не всегда так конечно, но частенько бывает. Да и сам процесс не мной придуман)
Иногда кандидаты видят тут подвох и финально отвечают
True, потому что не может же быть все настолько просто? Если бы было базовое понимание этих операторов, то сомнение не былоДобрый день! В статье про это написано
Спасибо, что вы действительно внимательно прочитали и отнеслись к теме объективно — это очень ценно.
Кажется, что продолжать обсуждение с ним уже не имеет смысла: ни одного конкретного примера, при этом постоянная агрессия, обесценивание и токсичность. Думаю, на этом разумно завершить дискуссию.