Уважаемый синьор daiver19 похоже принял слишком близко к сердцу эту проблему.
Почему-то он не приемлет синтетических примеров, ему подавай «из практики». Ну и что, что они на порядок сложнее и дольше в постановке. Школьные учебники с простыми синтетическими примерами его тоже, видимо, не устраивают.
Представляю себе как этот синьор скажет джуну в своей команде:
— Не пиши так.
— Но, мастер, почему..?
— Просто не пиши. Не хочу углубляться в подробности, но так делать нельзя! Я чувствую это.
— Х-хорошо, мастер. Я постараюсь запомнить.
Вот именно. Только это не проблема задачи, а проблема синьора, которого не смутила столь странная функция. Он даже не заподозрил подвоха увидев мутабельный объект в дефолтах. Он даже не вспомнил про этот сайдэффект.
Вы, похоже, только что меня убедили. Эта задача — довольно эффективный способ определения синьора-самозванца. Истинный синьор-питонист не потратил бы на эту задачу и минуты. Она уже решена в его голове.
Ваш пример ниже — просто грязный хак. Мы опять возвращаемся к моему первому комментарию — если у вас на проекте такие хаки — это норма, задавайте подобные вопросы сколько угодно.
Да блин, какого черта? Я ж написал, что в проде так не делают.
А ещё уже несколько раз писал в этой баталии, что синьор должентакие вещи понимать даже в плохом коде. Что за синьор, который не может объяснить джуну как делать не следует и почему?!
Я не спорю с вами о том, что такой вопрос на собеседовании синьора неуместен.
Я пытаюсь донести до вас, что любой вопрос и любая задача в учебных целях приемлема, если она хорошо выполняет свою роль. Для контроля знаний джуниора эта задача тоже приемлема. И в учебниках во всех по питону она есть именно по этой причине. Хотя вам, видимо, виднее.
Да как это не имеет? Ниже я привел пример.
Да, так в продакшн не пишут, но это пример из книжки для чайников. Если этого не понимает синьор, то сливай воду.
Кстати, может быть вам и в школе более реальные задачи надо задавать, а не абстрактные гоняющиеся друг за другом поезда, встречающиеся неизвестно где?
Пример в статье максимально короткий и лаконичный. В нём невозможно не заметить подвох, если знаешь о том как работают дефолты в питоне. Я повторюсь, что синьору задавать такие примеры не релевантно, такой хреновый синьор должен был раньше отсеяться по другим признакам. Однако задача для питона очень простая и вполне адекватная. Она направлена на знание специфики языка. Она есть в первых главах каждого учебника для изучающих язык с нуля.
Вот вполне рабочий и характерный для Питона пример. Есть в каждом учебнике этого языка.
Да, пример чисто академический и такое рекурсиями не решают, но сути того, что сеньор-питонист обязан понимать такие вещи это не меняет.
def factorial(x, _cache={1: 1}):
result = _cache.get(x, None)
if result is None:
result = _cache[x] = x * factorinal(x - 1)
return result
Это смотря кого вы ищете. Если компилятором проверяют наличие ошибок и опечаток — это норм. Если корректность синтаксиса, то это уже звоночек о проф-пригодности на позиции сеньора.
Есть такие штуки, как MVP, техдолг, agile и прочие.
В совокупности получается, что в простых случаях и для MVP вполне достаточно сделать максимально просто и быстро.
К примеру роль синглтоновой коллекции инстансов вполне может играть класс, если нет и не предвидится необходимости сделать два таких «синглтона».
Если же такая необходимость вдруг появится, то всегда можно дописать необходимую функциональность, а не предусматривать заранее то, что никогда не пригодится.
Да ладно вам. Не нужно наступать на некоторые грабли, чтобы догадаться о возможных последствиях увидев их у стеночки клевцами вверх. Если у тебя большой опыт, то не исключено, что о некоторых граблях ты догадался и без шишек, а ещё это был так давно, что уже и трудно сказать когда именно ты научился реагировать на мутабельные дефолты и прочие примеры «неожиданного» в питончике. Вы ещё назовите ситуацию с присвоением — WTF.
Да речь вообще не о слежении, а о вопросах на интервью, которые завязаны на каких-то неиспользуемых языковых конструкциях. Это бесполезно в оценке релевантных знаний кандидата. UB в C++- это был просто пример глупого вопроса (типа «а что будет если посчитать i++ + ++i»).
Для нормального сеньора этот вопрос конечно не релевантный, но для такого «сеньора», который в статье удивился тривиальной специфике поведения питона вопрос оказался «не в бровь а в глаз», позволил сэкономить время и не взять на ответственную позицию человека. который не знает языка.
То же можно сказать и про ваш пример с «i++ + ++i». Это неглупый вопрос, это вопрос, который отсеет человека, не знающего специфики синтаксиса и семантики языка. Потом такие ребята часами сидят с отладчиком пытаясь найти причину непонятного поведения асинхронного кода, где сами же не учли специфики i++. Если эта специфика не записалась тебе на подкорку, то никакие линтеры и IDE не помогут быть сеньором.
Если «сеньор» не заметил опасный мутабельный дефолт в аргументах на примере простого списка, то более сложной ситуации с кастомным классом он и подавно не увидит.
Линтеры же покамест не всесильны.
Конечно есть. Например когда инстансы должны регистрироваться внутри класса. Это полезно, скажем, когда мы наделали экземпляров, а потом хотим найти их все где-то в одном месте. Где? В классе неплохое место для этого. Другое дело, что называть атрибуты надо более понятно — это да.
Так вот, никакой подобный код человека, претендующего на обсуждаемую позицию удивлять должен априори, поскольку это тривиальные случаи.
Отдельный вопрос касается психологического давления. Человек может быть действительно крутым профессионалом, но иметь проблемы, связанные с уверенностью в себе. В отлаженном рабочем процессе это может не представлять проблемы, а в стрессовых ситуациях вполне может «завалить» соискателя на элементарщине.
Уметь разгрузить ситуацию, снизить напряжение и вывести собеседуемого в комфортный режим — это искусство интервьюера. Плохой быковатый «помощник» из программистов, которого может позвать HR, чтобы «позадавать технические вопросы» вполне может запороть отличного спеца на вакансию из-за даже неосознанного желания самоутвердиться.
Хотя бы потому, что ответы на более сложные и профильные вопросы покажут забыл или не забыл, зато экономия времени на «разминке» позволит контрагентам лучше узнать друг друга: интервьюер поймёт больше о соискателе, его интересах, планах; соискатель больше узнает о компании. Эдак можно было начать с арифметики в качестве разминки. Зачем?
«Senior Python Developer» был поражён
Ну да, странненько как-то. Разве что автор просто наполняет блог материалами для разного круга подписчиков, и в ход идут какие-то старые воспоминания или фантазии… не знаю.
Все верно. Поэтому я и написал, что «это следствие ряда механизмов внутренней оптимизации интерпретатора».
Ещё один механизм — это механизм определения функций и их аргументов.
Это касается любого «мутабельного» объекта. Да, в Питоне есть такое понятие. Есть объекты, которые нельзя менять (строки, кортежи, числа) и есть объекты. которые менять можно (списки, словари, множества). Можно самому реализовать мутабельный и иммутабельный тип и они будут полезны в тех или иных случаях.
Зачем это все так — относительно долгая история. Это следствие ряда механизмов внутренней оптимизации интерпретатора.
К примеру в C переменная похожа на ящичек, куда что-то можно положить, а потом положить туда что-то другое. В Питоне переменная — это ярлычок, который привязывается к объекту. Присвоением можно привязать к этому же объекту ещё один ярлычок (другое имя, другую переменную) или ярлычок (имя, переменную) перевязать с одного объекта на другой.
Мы не знаем заранее чего хотел добиться интервьюер задавая такой вопрос. Можно, конечно, предположить, что он глуп и сделал это от незнания до чего докопаться.
Однако с такой логикой легко и самому оказаться в дураках.
Давайте предположим, что интервьюер довольно умён, какую бы он цель вероятно преследовал в этом случае?
Дело в том, что ситуация с этим списком в дефолтах очень баянистая. В каждой первой книжке а-ля Python с нуля или для чайников это рассматривается. Наверно только джуниор (в этом языке) не знал бы такого (в общем-то весьма важного) «нюанса», связанного с передачей параметров в функции.
Может быть интервьюер хотел одним вопросом понять уровень знания языка. В данном случае, как выяснилось, вопрос попал в точку, то есть на границу знаний автора. Лично я, к примеру, расстроился бы, если бы меня спросили такое на собеседование в синьоры. Вот это действительно было бы пальцем в небо. А тут вопрос сработал на все 100%.
Автору оригинальной статьи эта история показалась, видимо, настолько поучительной, что он не стал изучать вопрос глубже, тогда он обнаружил бы всю баянистость его. Зато автор решил поведать всему миру о таком странном поведении языка.
А нельзя ли как-то поподробнее про это всё? А-то такое ощущение, что ещё чуть-чуть и ВЖУХ, начнётся магия, откроются новые мета-материалы, появится телепортация и на квантовых компьютерах, наконец-то, можно будет поиграть в компьютерные игры.
Но цепочки вызовов хотя бы отчасти позволяют обходить урезанные возможности лямбд. Ещё цепочечные функции удобны в векторных и матричных вычислениях. Там читаемость, ИМХО, напротив, повышается.
Почему-то он не приемлет синтетических примеров, ему подавай «из практики». Ну и что, что они на порядок сложнее и дольше в постановке. Школьные учебники с простыми синтетическими примерами его тоже, видимо, не устраивают.
Представляю себе как этот синьор скажет джуну в своей команде:
— Не пиши так.
— Но, мастер, почему..?
— Просто не пиши. Не хочу углубляться в подробности, но так делать нельзя! Я чувствую это.
— Х-хорошо, мастер. Я постараюсь запомнить.
Вы, похоже, только что меня убедили. Эта задача — довольно эффективный способ определения синьора-самозванца. Истинный синьор-питонист не потратил бы на эту задачу и минуты. Она уже решена в его голове.
А ещё кого-то может обескуражить такое
Да блин, какого черта? Я ж написал, что в проде так не делают.
А ещё уже несколько раз писал в этой баталии, что синьор должентакие вещи понимать даже в плохом коде. Что за синьор, который не может объяснить джуну как делать не следует и почему?!
Я не спорю с вами о том, что такой вопрос на собеседовании синьора неуместен.
Я пытаюсь донести до вас, что любой вопрос и любая задача в учебных целях приемлема, если она хорошо выполняет свою роль. Для контроля знаний джуниора эта задача тоже приемлема. И в учебниках во всех по питону она есть именно по этой причине. Хотя вам, видимо, виднее.
Да, так в продакшн не пишут, но это пример из книжки для чайников. Если этого не понимает синьор, то сливай воду.
Кстати, может быть вам и в школе более реальные задачи надо задавать, а не абстрактные гоняющиеся друг за другом поезда, встречающиеся неизвестно где?
Пример в статье максимально короткий и лаконичный. В нём невозможно не заметить подвох, если знаешь о том как работают дефолты в питоне. Я повторюсь, что синьору задавать такие примеры не релевантно, такой хреновый синьор должен был раньше отсеяться по другим признакам. Однако задача для питона очень простая и вполне адекватная. Она направлена на знание специфики языка. Она есть в первых главах каждого учебника для изучающих язык с нуля.
Да, пример чисто академический и такое рекурсиями не решают, но сути того, что сеньор-питонист обязан понимать такие вещи это не меняет.
В совокупности получается, что в простых случаях и для MVP вполне достаточно сделать максимально просто и быстро.
К примеру роль синглтоновой коллекции инстансов вполне может играть класс, если нет и не предвидится необходимости сделать два таких «синглтона».
Если же такая необходимость вдруг появится, то всегда можно дописать необходимую функциональность, а не предусматривать заранее то, что никогда не пригодится.
Для нормального сеньора этот вопрос конечно не релевантный, но для такого «сеньора», который в статье удивился тривиальной специфике поведения питона вопрос оказался «не в бровь а в глаз», позволил сэкономить время и не взять на ответственную позицию человека. который не знает языка.
То же можно сказать и про ваш пример с «i++ + ++i». Это неглупый вопрос, это вопрос, который отсеет человека, не знающего специфики синтаксиса и семантики языка. Потом такие ребята часами сидят с отладчиком пытаясь найти причину непонятного поведения асинхронного кода, где сами же не учли специфики i++. Если эта специфика не записалась тебе на подкорку, то никакие линтеры и IDE не помогут быть сеньором.
Линтеры же покамест не всесильны.
Так вот, никакой подобный код человека, претендующего на обсуждаемую позицию удивлять должен априори, поскольку это тривиальные случаи.
Отдельный вопрос касается психологического давления. Человек может быть действительно крутым профессионалом, но иметь проблемы, связанные с уверенностью в себе. В отлаженном рабочем процессе это может не представлять проблемы, а в стрессовых ситуациях вполне может «завалить» соискателя на элементарщине.
Уметь разгрузить ситуацию, снизить напряжение и вывести собеседуемого в комфортный режим — это искусство интервьюера. Плохой быковатый «помощник» из программистов, которого может позвать HR, чтобы «позадавать технические вопросы» вполне может запороть отличного спеца на вакансию из-за даже неосознанного желания самоутвердиться.
Хотя бы потому, что ответы на более сложные и профильные вопросы покажут забыл или не забыл, зато экономия времени на «разминке» позволит контрагентам лучше узнать друг друга: интервьюер поймёт больше о соискателе, его интересах, планах; соискатель больше узнает о компании. Эдак можно было начать с арифметики в качестве разминки. Зачем?
Ну да, странненько как-то. Разве что автор просто наполняет блог материалами для разного круга подписчиков, и в ход идут какие-то старые воспоминания или фантазии… не знаю.
Ещё один механизм — это механизм определения функций и их аргументов.
Зачем это все так — относительно долгая история. Это следствие ряда механизмов внутренней оптимизации интерпретатора.
К примеру в C переменная похожа на ящичек, куда что-то можно положить, а потом положить туда что-то другое. В Питоне переменная — это ярлычок, который привязывается к объекту. Присвоением можно привязать к этому же объекту ещё один ярлычок (другое имя, другую переменную) или ярлычок (имя, переменную) перевязать с одного объекта на другой.
Однако с такой логикой легко и самому оказаться в дураках.
Давайте предположим, что интервьюер довольно умён, какую бы он цель вероятно преследовал в этом случае?
Дело в том, что ситуация с этим списком в дефолтах очень баянистая. В каждой первой книжке а-ля Python с нуля или для чайников это рассматривается. Наверно только джуниор (в этом языке) не знал бы такого (в общем-то весьма важного) «нюанса», связанного с передачей параметров в функции.
Может быть интервьюер хотел одним вопросом понять уровень знания языка. В данном случае, как выяснилось, вопрос попал в точку, то есть на границу знаний автора. Лично я, к примеру, расстроился бы, если бы меня спросили такое на собеседование в синьоры. Вот это действительно было бы пальцем в небо. А тут вопрос сработал на все 100%.
Автору оригинальной статьи эта история показалась, видимо, настолько поучительной, что он не стал изучать вопрос глубже, тогда он обнаружил бы всю баянистость его. Зато автор решил поведать всему миру о таком странном поведении языка.