Шикарная задачка. Не знаю как проверяет знание программирования, но поведения человека от которого хотят странного проверяет великолепно) А парень молодец, видно что упорный.
Это НЕ СОБЕСЕДОВАНИЕ, это экзамен. Не нужно путать собеседование И ЭКЗАМЕН. Впрочем для ИТ собеседование и экзамен это одно и тоже. В других сферах деятельности такой жести нет.
блин ну может он и не знает многого но под натаскать если будет крутой чел с которым приятно будет работать и иметь дело что не маловажно. + видно что он старательный джун - огонек в глазах есть. На мой взгляд способный парень желаю ему удачи!
В чем смысл задачи, я не понял. Если есть что то кроме интов, флоатов конвертировать result в строку и уже прибавлять к ней str(i). Либо отсеять инты, и не инты и на выходе проверять результат и склеивать их.
Хорошее задание, и правильно поставленно - и понимание и опыт разработки реальной сразу виден. А то этот несчастный литкод скоро начнут наизустить учить как Библию, а понимания это все не прибавляет
def sum_items(*args): data_type = str(type(args[0])) result = args[0] for item in args[1:]: if str(type(item)) == data_type: result += item return result
Ну, для человека с ярлыком "СМИ" у него просто нулевые софты, как по мне: самопрезентация вообще на нуле, по проектам вообще ничего не рассказал, даже свою роль в проекте не выразил. Ибо после его рассказа о себе, как о разработчике и о своих проектах - у меня вообще не сформировалась никакая картинка о нем: вроде бы что-то говорил, но чем он занимался? Зачем? Почему? Ну, тут я могу и ошибаться - софты явно не мое. По хардам: 1. Когда Андрей сказал "если передадим строчку - скорее всего не сработает". Он подтвердил: "Да, не сработает." А откуда такая уверенность в том, что не сработает? Ведь строки прекрасно складываются - так почему нет? Весьма похоже на подтверждение просто "чтобы не упасть в грязь лицом". 2. Уже просто классика жанра: ставить тайп-хинты чисто ради того, чтобы показать, что ты где-то когда-то это слышал / видел, при этом не может расставить банальные хинты... 3. Проверка items == None, когда получает на входе запакованный кортеж - это прям печаль. И что еще печальнее - это дальнейшее исправлнение на "is None". Опять же, вместо того, чтобы подумать, начинает вспоминать станадартные вопросы / ответы с собесов. 4. "Питонячий код, который из декоратора обратится к переменным в функции" - вот тут сразу же вопрос про знание и понимание областей видимости. 5. Он же вообще даже не пытается уточнить, что от него требуется по задаче. Тут за 2-3 вопроса можно было бы заставить заказчика внести ясность в задачу. А он даже 1 не задал. 6. В декораторах совсем плавает: вынести логику в декоратор, задекорировать функцию и при этом оставить всю старую логику в этой же функции - это мощно. 7. Нет понимания своего же собственного кода. 8. len(items) - 1 - тут стоило бы сразу задать вопрос на тему того, чем его не устроил последний элемент. В целом, крайне неоднозначный собес: вроде бы что-то знает, что-то может, но это все такая каша - что прям страшно смотреть. Есть ряд моментов, которые бы я назвал прям критичными (выше написал), да и в целом с подкапотней не особо дружит. Хотя первая реализация через рекурсию была весьма неплохая: достаточно резво он применил рекурсию. И сделал это достаточно корректно. Пофиксить багу с range() и работало бы в соответствии с ТЗ. Хотя и ТЗ это не было уточнено. Я бы сказал: нужно структурировать все, что есть в голове, поизучать подкапотню и повторить собес. Я бы даже посмотрел на итог. P.S. Мне кажется, что фраза "если бы ты претендовал на мидла - нет, для джуна - ок" неоправдано поднимает самооценку. Слишком много каши, чтобы принимать такой код, ИМХО. P.P.S. "ПЕП8 ты сознательно не нарушаешь и получается работать в этом стиле" - он написал штуку вида args[i+1:] - без пробелов!!111!! :D
Как же душно... Такую ты простыню накатал просто чтобы человека размазать, и вот не лень было? "вроде бы что-то знает, что-то может, но это все такая каша - что прям страшно смотреть." - это и есть джун. Все с такого начинают.
@@Pvt.Hudson-j1c, нет, это не джун, это стажер и меньше. И любые высказывания вида "да все там были", "да ничего - прорвешься", "да все норм - есть и хуже" - они лишь вводят в заблуждение, не давая человеку понять, что он делает что-то не так. Простыня, которую я накатал выше, предназначена лишь для того, чтобы человек сделал выводы по всему тому, что я написал: и если он эти выводы сделает, то он станет вполне себе джуном. А если бы я хотел его "размазать", то я бы даже близко не пытался не пытался пояснять и аргументировать, а просто бы написал "в утиль" - и это куда больше бы подходило под термин "размазать". Ну и самое главное: вон там выше есть коммент, в котором говорится, что, мол, такой перфоманс поднимает самооценку всем джунам - и вот таким комментом и таким кол-вом лайков под ним явно можно очень серьезно опустить самооценку человеку. Но вы оба, почему-то, решили отписаться человеку, который пытается в развернутую критику. Сказочные создания.
@@7IdE под тем комментом нет смысла даже что то писать. Слишком жирно. У тебя хотя бы не троллинга ради было написан комментарий, поэтому и захотелось подискутировать. Ты слишком груб с человеком, который только делает первые шаги. Если мы не будем выращивать джунов, рынок будет в еще большей заднице. Новым миддлам будет неоткуда браться. Всем будет только хуже по итогу. Да и просто вспомни себя в начале, сомневаюсь что ты сразу начал писать максимально эффективный чистый код.
Отличная задачка с декоратором, а главное в отличии от прямого решения через рекурсию можно решить обычным циклом в декораторе. И почему никто не использует reduce в таких штуках, вродеж удобно.
Решение наркомании (если я правильно понял условие): def sum_items(*args): if not args: return _len = len(args) res = args[0] while _len: try: for item in args[1:_len]: res += item break except TypeError: res = args[0] _len -= 1 return res
Это выходит как exception-oriented programming. Не надо так делать. Это скорее антипаттерн. Проверьте type(last) и type(current) и если равны - то складывайте.
Если дать pass, то функция ничего не вернет. Что сломает не только саму функцию, но и того, кто ее вызывал. Сделал except: continue и не понял, зачем приплетали декораторы. Просто пропускаем сломанный элемент и доплюсовываем оставшиеся Можно и except: break (выходим из цикла и забываем, что после сломанного элемента было что-то еще), но по мне так это хуже вариант.
def sum_things(*things: float | int | str | list): result = things[0] if len(things) > 0 else None for idx, thing in enumerate(things[1:]): try: result = result + thing except: print(f"index {idx+1} is broken!") continue return result print(sum_things(1,2,"12312",123))
@@MrReape Нет, pass отработает точно так же, как и continue. Хотя continue лучше для читаемости. def sum_things(*args): if not args: return result = args[0] for x in args[1:]: try: result += x except: pass return result
Я начал изучать пайтон в декабре прошлого года, в среднем год, устроился на работу в октябре 2023. Так же самоучка без курсов и тоже нет вышки. Так что ты явно что-то делаешь не так
@@black_grizzly основные фреймы - django, fastapi, парсингу уделил время (реквест, селениум), телеграм ботам (aiogram), неможко покрутил-повертел next.js и react чтобы понимать как происходит взаимодействие бэка с фронтом, но в них не углублялся (в ванильный JS тоже не углублялся)
услышал начальные требования, поставил на паузу, написал решение минут за 10, попивая чаёк: # ----------------------------------------------------------------------------------------------------------------------------------------- def sum_arguments(*args): result = 0 print(f"Args count: {len(args)}") for item in args: arg_type = type(item).__name__ print(f"{item=}, {arg_type=}") match arg_type: case 'int': result += item case 'str': tmp = str.strip(item) for i in tmp.split(): try: result += int(i) except ValueError as e: pass case 'list' | 'tuple': result += sum_arguments(*item) case _: pass return result ### run it data = [1, 2, 3, '4', '5', "6", [7, 8, 9], "a 100 4", 'b', (0,1), '()', " -1 ", [], "1"] res = sum_arguments(data) print(f"{res=}") # ----------------------------------------------------------------------------------------------------------------------------------------- потом начал глядеть видео дальше, и слегка был сконфужен: - нечетко поставлены общие требования задачи - не указаны инженерные требования к входящим данным, их размер, наличие, граничные значения, валидность - не определены тайминги, а так же не обсуждалась сложность решения O(?) Вобщем, что-то как то быстренько закодил. Интересно, приемлимо ли получилось?
from functools import reduce def sum_items(*args): if args and hasattr(args[0], '__add__') and all(type(item) is type(args[0]) for item in args): return reduce(lambda x, y: x + y, args) return "Все аргументы должны быть одного типа и поддерживать операцию сложения" if args else None
Досмотрел -боль страдания А можно б было def sum_iter(*args): return reduce(lambda sum, num: sum + num if type(num) in (int, float) else sum, args if args is not None else [], 0)
@@AndyPronin а этого не было в задание, в момент когда стало полагаться что входная последовательность не однородная)) но вообще понятно что в реальной надо через дженерик делать . Я просто нахожусь под дурным влиянием книжки маера ))
Странное, зачем давать рандомные задачи которые имеют такую странную логику? Естественно кто шарит должен был сам уточнять что задача имеет недостаточно информации: 1)нужно ли суммировать один из типов, если да то какой? 2)или суммировать все элементы по типам, хранить их и выводить.. но выводить что? Сумму определенного типа или каждого типа данных. 3)или суммировать тот тип которого больше в списке.. 4)или суммировать первый попавшийся тип данных, а остальные просто пропускать. Это все в корне меняет способ решения. Но думаю можно было изначально логику вопроса построить получше, либо дать человеческую подсказку. Видно конечно что парень слабовато пока знает декораторы, мало практики наверное. Но задача конечно.. проверяет скорее на навык вежливого уточнения что за дичь просят разработчика сделать))
"Странное, зачем давать рандомные задачи которые имеют такую странную логику? Естественно кто шарит должен был сам уточнять что задача имеет недостаточно информации: " Это жизнь. В реальност изадача будет поставленно хреново
Несмотря на то, что я не согласен с корректностью такой постановки, но...от собеседуемого не прозвучало вообще никаких вопросов с целью уточнения того, что от него требуется. Банально за 2-3 уточняющих вопросов и парочку примеров с вопрос "что должно выводиться в таком случае" можно будет понять, что хочет заказчик. А в итоге заказчик впаривает какую-то дичь, а разработчик даже не пытается "увидеть решение задачи глазами заказчика". Так что, в данном случае, камень в огород собеседуемого.
Видео не досмотрел еще. Работаю с php питон не знаю. Но всё происходящее мне понятно. Тут еще задача не ясна. Что мы складываем, а что удаляем или же складываем и то и другое. Проверяем аргумент является ли числом, если истина складываем и наоборот. Ну а если и то и другое одновременно нужно сложить ну это уже ерундистика полнейшая.
в python типы должны проверяться до того как начнется их обработка и исключение! не должно быть исключения, если тип не тот. это суть таких яп. если у вас передался не тот тип и прилетело исключение. это говнокод.. поэтому типы прописывают не везде, как к примеру TypeScript а только где они получаются и модифицируются. сама функция которая получает условно строку, должна работать хорошо в любой ситуации. если строка не прилетела а прилетела цифра, то это проблемы не функции которой она пришла а того где оно приходит. поэтому правильно проверка делается до выполнения, в месте получения данных. надеюсь понятно, ибо чет сам чуть понял что написал.😂 в типизированных яп, оно по другому. а в слабо типизированных проверки проходят в самом начале, именно где пришло, а не в середине кода или конце.
Это все кстати, и много, что еще, я говорю людям считающий Пихон простым, и намного более плохое - подходящим для начала обучения программированию "нулевых" людей, особенно ООП.
Я вообще проблем в задаче не вижу. Пусть закидают камнями, php это не язык программирования итд... Но плёвое дело для него. И полностью согласен, в чём проблема проверить аргумент на инт и отсеять строки и наоборот. Ну а если нужно одно и второе разом складывать - то это бредятина и в жизни такое не встретится в принципе.
renge(len(items) - 1) - это лютый говнокод в python! это прям очень грубая ошибка. никогда так не делайте!!! это покажет то что вы вообще не знаете python а пишите на каком-то js синтаксисом python.. прикол в том что так много кто пишет.. и это реально жесть.. вы замедляете код минимум в двое! достаточно renge(items) и он нормально отработает. а так вы постоянно повторяете лишнее вычисление.😆
ну если Items =последовательность , то не получится rAnge(items), только если items = int, поэтому если нужно обращаться через индексы к items, то только так rAnge(len(items) - 1), ну или через enumerate()
Я искренне не понимаю таких людей. И "лютый говнокод", и "грубая ошибка", и "не знаете Питон" - я прям закликбейтился и подумал, что дальше будет что-то интересное. А дальше идет range(items) - которая будет падать на всех типах, кроме интов - и замедление кода в 2 раза, и повторное вычисление на каждой итерации... Ты хоть когда-нибудь пытался запускать питоновский код с range(items)? На основании чего ты взял, что вычисления происходят на каждой итерации, а не 1 раз? (это при условии, что вычисление len() вообще происходит, а не хранится изначально в атрибуте) Откуда ты взял "замедление х2 минимум"? И это я еще промолчу про то, что range пишется через "a". Почитай Лутца, что ле.
range-объект загружает в себя последовательность на основе трёх аргументов: старт, конец, шаг (обязательно целочисленных). Делает он это только один раз и при вызове выдаёт значения последовательности по принципу генератора. Дорогой "знаток" python, прочитайте хотя бы теорию
Вы определитесь безусловный переход это хорошо или плохо, читаемость кода против условной производительности, да меня учили без них кодить, но времена изменились, компиляторы поумнее нашего во многом и докапываться до этого глупо! Ну и в целом хз собеседование, вы проверяете знание синтаксиса или что, я решаю на питоне задачи больше года на литкоде, довольно неплохо я считаю, про то как передать произвольное количество переменных не знал, гуглится это меньше чем за минуту, если бы попросил у вас 1-2 минуты гугла, вы бы отказали, ахаха?)
Видео подняло самооценку всем джунам
надеюсь, еще и подкачало скилл)
главное чтобы тебе самооценку поднял этот коммент :)
Шикарная задачка. Не знаю как проверяет знание программирования, но поведения человека от которого хотят странного проверяет великолепно)
А парень молодец, видно что упорный.
from functools import reduce
def arg_sum(*args):
if args:
return reduce(
lambda x, y: x + y,
(arg for arg in args if type(arg) == type(args[0]))
)
Неплохое решение если первый элемент не будет исключительным
Ох, где-то на середине я уже потерял нить изначального задания:) Декораторы, рекурсия… Спасибо что до графов не дошли)))
Это НЕ СОБЕСЕДОВАНИЕ, это экзамен. Не нужно путать собеседование И ЭКЗАМЕН. Впрочем для ИТ собеседование и экзамен это одно и тоже. В других сферах деятельности такой жести нет.
это ты росто на собеседованиях в консалтинге не был , судя по всему. В компаниях большой тройки.
блин ну может он и не знает многого но под натаскать если будет крутой чел с которым приятно будет работать и иметь дело что не маловажно. + видно что он старательный джун - огонек в глазах есть. На мой взгляд способный парень желаю ему удачи!
Думаю, оффер не заставит долго ждать
Декоратор ради декоратора? Continue и всё.
В чем смысл задачи, я не понял. Если есть что то кроме интов, флоатов конвертировать result в строку и уже прибавлять к ней str(i). Либо отсеять инты, и не инты и на выходе проверять результат и склеивать их.
в чем проблема 2-ух ретернов в разных ветках условия функции?
условие можно упростить
можно было просто вернуть return result or None , не проверяя is None
имелось в виду, что нужно было if not items: return None .
Хорошее задание, и правильно поставленно - и понимание и опыт разработки реальной сразу виден. А то этот несчастный литкод скоро начнут наизустить учить как Библию, а понимания это все не прибавляет
Да. Стараюсь не брать леткод
def sum_items(*args):
data_type = str(type(args[0]))
result = args[0]
for item in args[1:]:
if str(type(item)) == data_type:
result += item
return result
Ну, для человека с ярлыком "СМИ" у него просто нулевые софты, как по мне: самопрезентация вообще на нуле, по проектам вообще ничего не рассказал, даже свою роль в проекте не выразил.
Ибо после его рассказа о себе, как о разработчике и о своих проектах - у меня вообще не сформировалась никакая картинка о нем: вроде бы что-то говорил, но чем он занимался? Зачем? Почему?
Ну, тут я могу и ошибаться - софты явно не мое.
По хардам:
1. Когда Андрей сказал "если передадим строчку - скорее всего не сработает". Он подтвердил: "Да, не сработает." А откуда такая уверенность в том, что не сработает? Ведь строки прекрасно складываются - так почему нет? Весьма похоже на подтверждение просто "чтобы не упасть в грязь лицом".
2. Уже просто классика жанра: ставить тайп-хинты чисто ради того, чтобы показать, что ты где-то когда-то это слышал / видел, при этом не может расставить банальные хинты...
3. Проверка items == None, когда получает на входе запакованный кортеж - это прям печаль. И что еще печальнее - это дальнейшее исправлнение на "is None". Опять же, вместо того, чтобы подумать, начинает вспоминать станадартные вопросы / ответы с собесов.
4. "Питонячий код, который из декоратора обратится к переменным в функции" - вот тут сразу же вопрос про знание и понимание областей видимости.
5. Он же вообще даже не пытается уточнить, что от него требуется по задаче. Тут за 2-3 вопроса можно было бы заставить заказчика внести ясность в задачу. А он даже 1 не задал.
6. В декораторах совсем плавает: вынести логику в декоратор, задекорировать функцию и при этом оставить всю старую логику в этой же функции - это мощно.
7. Нет понимания своего же собственного кода.
8. len(items) - 1 - тут стоило бы сразу задать вопрос на тему того, чем его не устроил последний элемент.
В целом, крайне неоднозначный собес: вроде бы что-то знает, что-то может, но это все такая каша - что прям страшно смотреть.
Есть ряд моментов, которые бы я назвал прям критичными (выше написал), да и в целом с подкапотней не особо дружит.
Хотя первая реализация через рекурсию была весьма неплохая: достаточно резво он применил рекурсию. И сделал это достаточно корректно. Пофиксить багу с range() и работало бы в соответствии с ТЗ. Хотя и ТЗ это не было уточнено.
Я бы сказал: нужно структурировать все, что есть в голове, поизучать подкапотню и повторить собес. Я бы даже посмотрел на итог.
P.S. Мне кажется, что фраза "если бы ты претендовал на мидла - нет, для джуна - ок" неоправдано поднимает самооценку. Слишком много каши, чтобы принимать такой код, ИМХО.
P.P.S. "ПЕП8 ты сознательно не нарушаешь и получается работать в этом стиле" - он написал штуку вида args[i+1:] - без пробелов!!111!! :D
Только зачем там рекурсия, если можно обойтись обычным циклом - не совсем понятно.
Ну ты и токсик, просто ужас
Как же душно... Такую ты простыню накатал просто чтобы человека размазать, и вот не лень было? "вроде бы что-то знает, что-то может, но это все такая каша - что прям страшно смотреть." - это и есть джун. Все с такого начинают.
@@Pvt.Hudson-j1c, нет, это не джун, это стажер и меньше.
И любые высказывания вида "да все там были", "да ничего - прорвешься", "да все норм - есть и хуже" - они лишь вводят в заблуждение, не давая человеку понять, что он делает что-то не так.
Простыня, которую я накатал выше, предназначена лишь для того, чтобы человек сделал выводы по всему тому, что я написал: и если он эти выводы сделает, то он станет вполне себе джуном.
А если бы я хотел его "размазать", то я бы даже близко не пытался не пытался пояснять и аргументировать, а просто бы написал "в утиль" - и это куда больше бы подходило под термин "размазать".
Ну и самое главное: вон там выше есть коммент, в котором говорится, что, мол, такой перфоманс поднимает самооценку всем джунам - и вот таким комментом и таким кол-вом лайков под ним явно можно очень серьезно опустить самооценку человеку.
Но вы оба, почему-то, решили отписаться человеку, который пытается в развернутую критику.
Сказочные создания.
@@7IdE под тем комментом нет смысла даже что то писать. Слишком жирно. У тебя хотя бы не троллинга ради было написан комментарий, поэтому и захотелось подискутировать. Ты слишком груб с человеком, который только делает первые шаги. Если мы не будем выращивать джунов, рынок будет в еще большей заднице. Новым миддлам будет неоткуда браться. Всем будет только хуже по итогу. Да и просто вспомни себя в начале, сомневаюсь что ты сразу начал писать максимально эффективный чистый код.
Отличная задачка с декоратором, а главное в отличии от прямого решения через рекурсию можно решить обычным циклом в декораторе. И почему никто не использует reduce в таких штуках, вродеж удобно.
Решение наркомании (если я правильно понял условие):
def sum_items(*args):
if not args:
return
_len = len(args)
res = args[0]
while _len:
try:
for item in args[1:_len]:
res += item
break
except TypeError:
res = args[0]
_len -= 1
return res
Это выходит как exception-oriented programming. Не надо так делать. Это скорее антипаттерн.
Проверьте type(last) и type(current) и если равны - то складывайте.
А если бы в районе 24:00 испытуемый просто написал except: pass вместо рекурсии, отслеживания индексов и т.д. это было бы решением ?
Если дать pass, то функция ничего не вернет. Что сломает не только саму функцию, но и того, кто ее вызывал.
Сделал except: continue и не понял, зачем приплетали декораторы. Просто пропускаем сломанный элемент и доплюсовываем оставшиеся
Можно и except: break (выходим из цикла и забываем, что после сломанного элемента было что-то еще), но по мне так это хуже вариант.
def sum_things(*things: float | int | str | list):
result = things[0] if len(things) > 0 else None
for idx, thing in enumerate(things[1:]):
try:
result = result + thing
except:
print(f"index {idx+1} is broken!")
continue
return result
print(sum_things(1,2,"12312",123))
@@MrReape Нет, pass отработает точно так же, как и continue. Хотя continue лучше для читаемости.
def sum_things(*args):
if not args:
return
result = args[0]
for x in args[1:]:
try:
result += x
except:
pass
return result
@@roman88469 А зачем там континтью. Цикл закончен, мы идем логично дальше. То есть лучше поставить pass
Можно к вам на собес?) Хочу показать мастер-класс:D + Действительно junior и ищу работу
А на этом канале кого нибудь взяли на работу? Скиньте ссылку на интервью.
th-cam.com/video/8Eca6XylJJI/w-d-xo.html
из последнего - вот Гриша. Сейчас обживается активно. К себе его взял. Где то и бекендеры были. И QA
Да, этот собес отличался от просмотренных.
Здравствуйте. Что нужно чтобы устроиться на работу Python разработчику-самоучке? У пока нет высшего образования, а Python я изучаю уже лет 5.
Активно искать работу. И запастись терпением. Ваш кэп. Например, вот: th-cam.com/users/livenUhamqilnwg?si=BneBlARIAj_SN9y7
Я начал изучать пайтон в декабре прошлого года, в среднем год, устроился на работу в октябре 2023. Так же самоучка без курсов и тоже нет вышки.
Так что ты явно что-то делаешь не так
@@Chel1k7 что учили то еще помимо языка ?
@@black_grizzly основные фреймы - django, fastapi, парсингу уделил время (реквест, селениум), телеграм ботам (aiogram), неможко покрутил-повертел next.js и react чтобы понимать как происходит взаимодействие бэка с фронтом, но в них не углублялся (в ванильный JS тоже не углублялся)
@@Chel1k7 ну да, наверное потому что я начал искать работу только сейчас?
услышал начальные требования, поставил на паузу, написал решение минут за 10, попивая чаёк:
# -----------------------------------------------------------------------------------------------------------------------------------------
def sum_arguments(*args):
result = 0
print(f"Args count: {len(args)}")
for item in args:
arg_type = type(item).__name__
print(f"{item=}, {arg_type=}")
match arg_type:
case 'int':
result += item
case 'str':
tmp = str.strip(item)
for i in tmp.split():
try:
result += int(i)
except ValueError as e:
pass
case 'list' | 'tuple':
result += sum_arguments(*item)
case _:
pass
return result
### run it
data = [1, 2, 3, '4', '5', "6", [7, 8, 9], "a 100 4", 'b', (0,1), '()', " -1 ", [], "1"]
res = sum_arguments(data)
print(f"{res=}")
# -----------------------------------------------------------------------------------------------------------------------------------------
потом начал глядеть видео дальше, и слегка был сконфужен:
- нечетко поставлены общие требования задачи
- не указаны инженерные требования к входящим данным, их размер, наличие, граничные значения, валидность
- не определены тайминги, а так же не обсуждалась сложность решения O(?)
Вобщем, что-то как то быстренько закодил. Интересно, приемлимо ли получилось?
Головодрочь с этими "универсальными" функциями в динамических языках. 🙂 Тайпхинты и mypy в помощь, поможет сделать нормально. Я c# девелопер 😃
я думаю что все таки, быть репортером ему наверное куда лучше,даже не знаю какой он репортер…Пусть развиваться
давай на тебя посмотрим, может?)
В записи посмотрю , к сожалению работа иногда мешает просмотру ☺️
Если работа мешает просмотру, брось ее нахуй - работу свою -)
Чет нулевое собеседование. Ни о чем. Красивый рассказ про проекты и всякое, но уровень.
чет не о чем коммент.
from functools import reduce
def sum_items(*args):
if args and hasattr(args[0], '__add__') and all(type(item) is type(args[0]) for item in args):
return reduce(lambda x, y: x + y, args)
return "Все аргументы должны быть одного типа и поддерживать операцию сложения" if args else None
Расскажите пожалуйста, как к вам можно попасть на собеседование
Выпускникам практикума через программу трудоустройства. Подписчикам - через розыгрыш в телеграм моем
Досмотрел -боль страдания
А можно б было
def sum_iter(*args):
return reduce(lambda sum, num: sum + num if type(num) in (int, float) else sum, args if args is not None else [], 0)
А строчки сложит? ;)
@@AndyPronin а этого не было в задание, в момент когда стало полагаться что входная последовательность не однородная)) но вообще понятно что в реальной надо через дженерик делать . Я просто нахожусь под дурным влиянием книжки маера ))
Не знал что меддисон увлекается программированием
Странное, зачем давать рандомные задачи которые имеют такую странную логику?
Естественно кто шарит должен был сам уточнять что задача имеет недостаточно информации:
1)нужно ли суммировать один из типов, если да то какой?
2)или суммировать все элементы по типам, хранить их и выводить.. но выводить что? Сумму определенного типа или каждого типа данных.
3)или суммировать тот тип которого больше в списке..
4)или суммировать первый попавшийся тип данных, а остальные просто пропускать.
Это все в корне меняет способ решения.
Но думаю можно было изначально логику вопроса построить получше, либо дать человеческую подсказку.
Видно конечно что парень слабовато пока знает декораторы, мало практики наверное. Но задача конечно.. проверяет скорее на навык вежливого уточнения что за дичь просят разработчика сделать))
Добавлю что очень классный скил у парня - говорить и рассуждать вслух, если бы еще вопросы задавать попутно собеседующему то будет супер.
"Странное, зачем давать рандомные задачи которые имеют такую странную логику?
Естественно кто шарит должен был сам уточнять что задача имеет недостаточно информации: "
Это жизнь. В реальност изадача будет поставленно хреново
Несмотря на то, что я не согласен с корректностью такой постановки, но...от собеседуемого не прозвучало вообще никаких вопросов с целью уточнения того, что от него требуется.
Банально за 2-3 уточняющих вопросов и парочку примеров с вопрос "что должно выводиться в таком случае" можно будет понять, что хочет заказчик.
А в итоге заказчик впаривает какую-то дичь, а разработчик даже не пытается "увидеть решение задачи глазами заказчика".
Так что, в данном случае, камень в огород собеседуемого.
Видео не досмотрел еще. Работаю с php питон не знаю. Но всё происходящее мне понятно.
Тут еще задача не ясна. Что мы складываем, а что удаляем или же складываем и то и другое.
Проверяем аргумент является ли числом, если истина складываем и наоборот. Ну а если и то и другое одновременно нужно сложить ну это уже ерундистика полнейшая.
Надо больше мидлов!
Здрасьте
Салют
привет
Забор покрасьте! (Сорян, услышал это выражение у ребёнка в детском саду и захотелось применить)
в python типы должны проверяться до того как начнется их обработка и исключение! не должно быть исключения, если тип не тот. это суть таких яп. если у вас передался не тот тип и прилетело исключение. это говнокод.. поэтому типы прописывают не везде, как к примеру TypeScript а только где они получаются и модифицируются. сама функция которая получает условно строку, должна работать хорошо в любой ситуации. если строка не прилетела а прилетела цифра, то это проблемы не функции которой она пришла а того где оно приходит. поэтому правильно проверка делается до выполнения, в месте получения данных. надеюсь понятно, ибо чет сам чуть понял что написал.😂 в типизированных яп, оно по другому. а в слабо типизированных проверки проходят в самом начале, именно где пришло, а не в середине кода или конце.
Это все кстати, и много, что еще, я говорю людям считающий Пихон простым, и намного более плохое - подходящим для начала обучения программированию "нулевых" людей, особенно ООП.
Я вообще проблем в задаче не вижу. Пусть закидают камнями, php это не язык программирования итд... Но плёвое дело для него. И полностью согласен, в чём проблема проверить аргумент на инт и отсеять строки и наоборот. Ну а если нужно одно и второе разом складывать - то это бредятина и в жизни такое не встретится в принципе.
С каких пор питон стал слабо типизированным языком?
Господи как же доооолго.. и разговоры не по теме.. пробует то, что не знает.. Зачееем!? АААрРАРРРРаа
renge(len(items) - 1) - это лютый говнокод в python! это прям очень грубая ошибка. никогда так не делайте!!! это покажет то что вы вообще не знаете python а пишите на каком-то js синтаксисом python.. прикол в том что так много кто пишет.. и это реально жесть.. вы замедляете код минимум в двое! достаточно renge(items) и он нормально отработает. а так вы постоянно повторяете лишнее вычисление.😆
ну если Items =последовательность , то не получится rAnge(items), только если items = int, поэтому если нужно обращаться через индексы к items, то только так rAnge(len(items) - 1), ну или через enumerate()
"А вы точно -продюссер- паграммизд ... "
Уверены прям в этом страшном " _а так вы постоянно повторяете лишнее вычисление_" ?
Я искренне не понимаю таких людей.
И "лютый говнокод", и "грубая ошибка", и "не знаете Питон" - я прям закликбейтился и подумал, что дальше будет что-то интересное.
А дальше идет range(items) - которая будет падать на всех типах, кроме интов - и замедление кода в 2 раза, и повторное вычисление на каждой итерации...
Ты хоть когда-нибудь пытался запускать питоновский код с range(items)?
На основании чего ты взял, что вычисления происходят на каждой итерации, а не 1 раз? (это при условии, что вычисление len() вообще происходит, а не хранится изначально в атрибуте)
Откуда ты взял "замедление х2 минимум"?
И это я еще промолчу про то, что range пишется через "a".
Почитай Лутца, что ле.
Абобус, вычисления будет производится циклично только если ты укажешь их в условии цикла while
range-объект загружает в себя последовательность на основе трёх аргументов: старт, конец, шаг (обязательно целочисленных). Делает он это только один раз и при вызове выдаёт значения последовательности по принципу генератора.
Дорогой "знаток" python, прочитайте хотя бы теорию
Вы определитесь безусловный переход это хорошо или плохо, читаемость кода против условной производительности, да меня учили без них кодить, но времена изменились, компиляторы поумнее нашего во многом и докапываться до этого глупо! Ну и в целом хз собеседование, вы проверяете знание синтаксиса или что, я решаю на питоне задачи больше года на литкоде, довольно неплохо я считаю, про то как передать произвольное количество переменных не знал, гуглится это меньше чем за минуту, если бы попросил у вас 1-2 минуты гугла, вы бы отказали, ахаха?)