ОГОНЬ!!! Вот, не задача. Когда только решил попробовать на зуб програмирование, ютуб - гугл кормили сплошными ботами и блогами. Ты обезянишь 2-3 бота-блога, гордый собой набиваешся на собеседование и сыпешся как песок. И, когда, настрадавшись, таки стал джуном, алгоритмы начинают подкидовать годноту. Пересмотрел все ролики на канале, что-то освежил, что-то вызвало реакцию "Да ладно! А так можно было?!". В общем, огромный респект автору!!! Так держать!!! Редкой жирности контент для ру сегмента. Не ходите к Гоше-Дударю, ходите сюда) Мне, конечно было бы интересно про всякие структурные-дизайн паттерны со всякими депенденси инджекшонами, если вдруг) Но и так - круто!!!
Давно и плотно работаю с Python. Пока учился, успел набить кучу шишок. Жалко, что в начале пути не набрел на этот канал. Сейчас не смотря на то, что из роликов на канале не черпаю для себя чегото нового, смотрю их с большим удовольствием. Спасибо за труд. Для новичков однозначно маст хэв👍💪
Хорошое видео спасибо. Этот подход называется pure functions. Не всегда возможно, но надо стремится разбивать все на маленькие короткие функции. Спасибо 👍
Блин, вот реально годные видосы. Учу по книге и там весь код подан как бы это сказать " по правилам разговорного языка". А то что в видосах это как слэнг. Т.е. можно написать короче, понятнее и проще. Автор, огромное спасибо. Было бы приятно видеть ролики по синтаксису и т.д., но с точки зрения реального кода, жизненного, с разными вариациями, с теми фишечками которых нет в книгах. Ещё раз спасибо. Ну и не мешало бы повысить качество звука.
Внезапно обнаружила что большинство моих функций не хорошие. Преподаватель сказал что лучше писать короткие, но почему никто не объяснил. А с началом ООП вообще беда настала. Спасибо, стало понятнее
Все правильно, но хочется чуток добавить: 1. В коде осталась хард-корная 9-ка в randint. Понятно, что это просто все цифры, но вдруг заказчик захочет, чтобы цифры 9 вообще не было в его пинах. 2. Хардкорная '5' в replace - совсем не айс, 3. Хард-корные 8 и 5 в первой строке основной функции тоже не айс. Все эти параметры стоило бы объявить константами. Находясь наверху кода, константы позволяют себя менять совсем легко и понятно. 4. Функция replace_fives - весьма странное решение. А заказчик не может захотеть менять не 5, а как раз таки 6-ки. Тогда, переписывать саму функцию на replace_sixs и ждать когда у заказчика стрельнет в голове и ему чем-то не угодит цифра 3, на пример. 5. Все эти 5, 6 и 8 стоит поместить в отдельный json-файл и читать его при запуске. Тогда в программе не останется вообще никакой конкретики и это будет хороший проект, который все, что может меняться получает из вне. Ну или отдельный python-файл и импортировать его. Тут уж кому, что больше нравится. Спасибо, что напомнили о правилах хорошего тона в python-программировании.
Лайк подписка и колокол. Очень жаль что такие материалы и такой канал не миллионник! Ваши видео бесценны. Жаль что всякий мусор в топе. (надеюсь временно)
Спасибо, видео оказалось очень полезным для меня лично. Смог досконально разобрать с процессами, который происходят в функции replace_fives_inplace (из видео). До этого не знал об этом и даже не предполагал, что так происходит. Да и если бы на курсах с самого начала учили правильно составлять композицию, то было бы лучше, а так, по большому счету, приходится заново переучиваться и терять время.
Спасибо, все, как всегда, круто, информативно, по делу. Скажу честно: поймал себя на мысли,что стараюсь соответствовать, хоть и не первый ЯП в активе(давно живу, потому- учился по книгам)).
спасибо 👍 вопрос по практике - если получаются функции более длинные чем в пару строчек, нужно ли пустыми строками отделять логические части, например: # удаляем граничные нули warehouse_copy = remove_zero_borders(warehouse_copy) # выводим матрицу с указанием пути print(tabulate(warehouse_copy, stralign="center", tablefmt="grid"))
я обычно внутри функции не отделяю, но может быть и логично, особенно если такой стиль допустим в команде. НО обрати внимание - если у тебя внутри функции какие то логические части отдельные и они сравнительно большие - не стоит ли их тоже разделить и вынести в отдельные функции? В твоем примере вполне можно написать рядом без отделения пустой строкой, но с комментом после кода.
@@PythonRussian ну, про то, что если возникла надобность разделять строками, то возможно тогда и в виде функций сделать - таже мысль посетила))) мне больше из практики интересно) а комментарии после пишутся? мне почему-то казалось что до
@@x-user-agent лучше в стиле function(s) # comment, то есть в той же строке что и код. Напоминаю что пишем только комменты, которые не явные по коду, которые что-то пояснят в происходящем.
После замыкания на канале у автора, увидев как он объясняет - захотелось узнать ещё чего-нибудь интересного от него и эти правила функций просто нечто! Я очень искал на этом канале с таким объяснением тему Рекурсивной функции, но не нашёл...( Интересно почему здесь нет про Рекурсию с этими её условиями? т.е. когда ты пишешь рекурсию, то уже зараннее читаешь в голове алгоритм её написания, но как?? Все эти примеры с нахождением факторила или чисел фибоначчи юзлесс шлак, это плохие примеры, либо авторы не используют значительный упор на объяснение условия, у этого автора бы это получилось!..Матрицы, словари, замыкания и т.д. и рядом не стояли в плане понимания Рекурсии(
я вообще не планировал рекурсию рассматривать, но так как это уже наверное 10 просьба от разных подписчиков, то в планы себе записал на весну -будет видео без факториалов и фибоначчи.
@@PythonRussian а можно у вас узнать почему не планировали? Словно это говорит о том, знать что такое рекурсия нужно, но она не так обязательна как всё остальное? Мне могло показаться, что Рекурсия лишь хороша для обхода огромного количества вложенностей какой-либо структуры данных и всё..
@@PythonRussian Она скорее всего непонятна таким тупым как я :( Т.е. стэки, информация в виде результата в этих стэках ясна я думаю всем, раскладываемся-складываемся, но условия выхода из Рекурсии это пожалуй основное, то что всем непонятно в Рекурсии.. ( Пишу это для того, чтобы вы взяли во внимание это для вашего бесценного видео ^^)
Имеет ли место использование "умных функций"( когда функция нужна только внутри другой функции и не требуется глобально) в длинных интерпрайс файлах, где нет модульности и выполняется всякое разное от авторизации пользователя до отправки отправки ему почты? Вроде тот подход полезен, когда функция нужна только внутри другой функции и не требуется глобально. Локальные функции помогают упростить код, делая его более модульным и улучшая его читаемость в бесконечной спагеттине или я ошибаюсь?
не знаю что такое интерпрайз файлы без модульности. Внутреннюю функцию лучше использовать только при декораторах, в остальном лучше выносить ее, чтобы можно было протестировать и возможно потом переиспользовать. О бесконечных спагеттинах ничего не знаю
А как же проверка внутри функции типов аргументов? Я вообще из-за этого и начал смотреть выпуск, но так и не услышал об этом. Так ли важно кидать райзы, когда что-то не так?.. И почему?
если в каждой функции проверять аргументы то код сильно разрастется, питон потому и удобен своей динамикой, что мы допускаем другие типы (дактайпинг) в том числе для тестирования. Есть модуль mypy, который позволит проверять типы если они написаны в аннотациях функций. В остальном проверку типов лучше оставить для крайних случаев, подумав нельзя ли полиморфизмом обойтись. Если же что не так, то пусть падает исключение fail fast, которую мы увидим и отреагируем. По той же причине не надо бояться бросать исключения, это даже в дзене питона говорят, ибо если промолчать на исключение и вернуть Нан или просто продолжить работу то можно потом очень долго искать проблему на дебаге. Естественно всегда есть особые случаи.
Подскажите, 1) а почему в функции replace_fives вы решили сделать ее более универсальной и вынести value (на что заменять) в параметры, но не сделали саму функцию еще более "общей" и не добавили параметр и что искать и замещать? Типа replace_N_to_M. Завтра изменится параметр 5 и придется переписывать всю функцию и менять все ее упоминания? Может стоило ее оставить replace_five_to_six и только со списком? Какие критерии? 2) Почему вы решили вынести функционал записи в файл в отдельную функцию? Ведь в ней вроде нечего тестировать - там только стандартная функциональность языка. Стремление выделить и оформить это в отдельное "действие" понятно, но теряется смысл в тестировании подобных функций. А без смысла теста - это как то странно смотрится, вы ведь выделили это в критерий создания функции. Чем тут руководствуются? Это как будто создавать функцию для print(X), вам не кажется?
подсказываю- функция записи в файл вынесена не для тестирования, а потому что делает ровно 1 вещь и может быть переиспользована в разных местах программы
@@PythonRussian но разве в данном случае это дробление не излишнее? ведь внутри этой функции лишь одно действие вывода строки в файл. так можно и до def my_print(str): print(str) дойти, нет? Я вас не стараюсь как то "подковырнуть", если подумали. В любом случае, спасибо за видео.
серьезно такие люди существуют о которых вы рассказываете в видео? просто я ни в одном источнике информации ничего подобного не видел, курсы гик и другие не смотрел.
@@PythonRussian да действительно, открыл первую попавшуюся тему, все как под копирку. Try except с pass, if i==True,я у Немчинского видел, он говорит так индусы пишут.
лучший канал по питону в мире. жалко челы думают, что долгий ролик - значит много воды. Про ваши ролики такого не скажешь вообще
Еще раз подчеркну - не стоит формально относиться к означенным правилам, всегда есть исключения! Игорь, спасибо за поддержку канала
Начинаю изучать питон. Видео очень познавательное, подписался на ваш канал! Спасибо за подробную информацию.
Лучший канал!!! Лучшая подача материала!!! Спасибо громадное за труд!!!
лучший комментарий!!! =)
ОГОНЬ!!!
Вот, не задача. Когда только решил попробовать на зуб програмирование, ютуб - гугл кормили сплошными ботами и блогами. Ты обезянишь 2-3 бота-блога, гордый собой набиваешся на собеседование и сыпешся как песок. И, когда, настрадавшись, таки стал джуном, алгоритмы начинают подкидовать годноту.
Пересмотрел все ролики на канале, что-то освежил, что-то вызвало реакцию "Да ладно! А так можно было?!".
В общем, огромный респект автору!!! Так держать!!!
Редкой жирности контент для ру сегмента. Не ходите к Гоше-Дударю, ходите сюда)
Мне, конечно было бы интересно про всякие структурные-дизайн паттерны со всякими депенденси инджекшонами, если вдруг)
Но и так - круто!!!
спасибо за отзыв. Про паттерны тоже будет, но в свое время, так как тема ООП на канале еще не затронута, мы к ней идем.
Давно и плотно работаю с Python. Пока учился, успел набить кучу шишок. Жалко, что в начале пути не набрел на этот канал. Сейчас не смотря на то, что из роликов на канале не черпаю для себя чегото нового, смотрю их с большим удовольствием. Спасибо за труд. Для новичков однозначно маст хэв👍💪
Хорошое видео спасибо. Этот подход называется pure functions. Не всегда возможно, но надо стремится разбивать все на маленькие короткие функции.
Спасибо 👍
Блин, вот реально годные видосы. Учу по книге и там весь код подан как бы это сказать " по правилам разговорного языка". А то что в видосах это как слэнг. Т.е. можно написать короче, понятнее и проще. Автор, огромное спасибо. Было бы приятно видеть ролики по синтаксису и т.д., но с точки зрения реального кода, жизненного, с разными вариациями, с теми фишечками которых нет в книгах. Ещё раз спасибо. Ну и не мешало бы повысить качество звука.
В книгах есть почти все тонкости, просто книг много.
Супер подача инфы, а самое главное хорошо запоминается.
Спасибо! Как всегда очень полезно и понятно. Сколько авгиев конюшен кода будет вычищено благодаря таким видео
Спасибо за материал. Как всегда все максимально понятно.
Внезапно обнаружила что большинство моих функций не хорошие. Преподаватель сказал что лучше писать короткие, но почему никто не объяснил. А с началом ООП вообще беда настала. Спасибо, стало понятнее
на 18:15 вы говорите о дебагере - добавьте в подсказки к видео, а то там только unitest сейчас. и спасибо за видео
Спасибо. Посмотрел на свои функции и понял что делаю что-то не так :)
Все правильно, но хочется чуток добавить:
1. В коде осталась хард-корная 9-ка в randint. Понятно, что это просто все цифры, но вдруг заказчик захочет, чтобы цифры 9 вообще не было в его пинах.
2. Хардкорная '5' в replace - совсем не айс,
3. Хард-корные 8 и 5 в первой строке основной функции тоже не айс.
Все эти параметры стоило бы объявить константами. Находясь наверху кода, константы позволяют себя менять совсем легко и понятно.
4. Функция replace_fives - весьма странное решение. А заказчик не может захотеть менять не 5, а как раз таки 6-ки. Тогда, переписывать саму функцию на replace_sixs и ждать когда у заказчика стрельнет в голове и ему чем-то не угодит цифра 3, на пример.
5. Все эти 5, 6 и 8 стоит поместить в отдельный json-файл и читать его при запуске. Тогда в программе не останется вообще никакой конкретики и это будет хороший проект, который все, что может меняться получает из вне. Ну или отдельный python-файл и импортировать его. Тут уж кому, что больше нравится.
Спасибо, что напомнили о правилах хорошего тона в python-программировании.
Спасибо за видео! Хорошая подача материала.
Лайк подписка и колокол. Очень жаль что такие материалы и такой канал не миллионник! Ваши видео бесценны. Жаль что всякий мусор в топе. (надеюсь временно)
если зрители будут чаще оставлять комменты и лайки то выйдем и в топ.
Сегодня наткнулся на это видео, понравилась подача материала, подписался. Желаю каналу и автору развиваться.
Спасибо, видео оказалось очень полезным для меня лично. Смог досконально разобрать с процессами, который происходят в функции replace_fives_inplace (из видео). До этого не знал об этом и даже не предполагал, что так происходит. Да и если бы на курсах с самого начала учили правильно составлять композицию, то было бы лучше, а так, по большому счету, приходится заново переучиваться и терять время.
Отлично. Все понятно. Спасибо.
Спасибо, все, как всегда, круто, информативно, по делу. Скажу честно: поймал себя на мысли,что стараюсь соответствовать, хоть и не первый ЯП в активе(давно живу, потому- учился по книгам)).
по книгам -это правильный путь =)
Самая понятная подача информации
Спасибо за видео!!! Очень помогло!
Отличный видос, спасибо большое)))
Очень классное видео. Спасибо
Очень классная подача, спасибо
спасибо 👍 вопрос по практике - если получаются функции более длинные чем в пару строчек, нужно ли пустыми строками отделять логические части, например:
# удаляем граничные нули
warehouse_copy = remove_zero_borders(warehouse_copy)
# выводим матрицу с указанием пути
print(tabulate(warehouse_copy, stralign="center", tablefmt="grid"))
я обычно внутри функции не отделяю, но может быть и логично, особенно если такой стиль допустим в команде. НО обрати внимание - если у тебя внутри функции какие то логические части отдельные и они сравнительно большие - не стоит ли их тоже разделить и вынести в отдельные функции? В твоем примере вполне можно написать рядом без отделения пустой строкой, но с комментом после кода.
@@PythonRussian ну, про то, что если возникла надобность разделять строками, то возможно тогда и в виде функций сделать - таже мысль посетила))) мне больше из практики интересно) а комментарии после пишутся? мне почему-то казалось что до
@@x-user-agent лучше в стиле function(s) # comment, то есть в той же строке что и код. Напоминаю что пишем только комменты, которые не явные по коду, которые что-то пояснят в происходящем.
@@PythonRussian ааа, ясно, спасибо
Спасибо за урок, я только не понимаю как работают одострочне for
если ты про листкомпс, то по ним у меня есть видео на канале
После замыкания на канале у автора, увидев как он объясняет - захотелось узнать ещё чего-нибудь интересного от него и эти правила функций просто нечто! Я очень искал на этом канале с таким объяснением тему Рекурсивной функции, но не нашёл...( Интересно почему здесь нет про Рекурсию с этими её условиями? т.е. когда ты пишешь рекурсию, то уже зараннее читаешь в голове алгоритм её написания, но как?? Все эти примеры с нахождением факторила или чисел фибоначчи юзлесс шлак, это плохие примеры, либо авторы не используют значительный упор на объяснение условия, у этого автора бы это получилось!..Матрицы, словари, замыкания и т.д. и рядом не стояли в плане понимания Рекурсии(
я вообще не планировал рекурсию рассматривать, но так как это уже наверное 10 просьба от разных подписчиков, то в планы себе записал на весну -будет видео без факториалов и фибоначчи.
@@PythonRussian а можно у вас узнать почему не планировали? Словно это говорит о том, знать что такое рекурсия нужно, но она не так обязательна как всё остальное? Мне могло показаться, что Рекурсия лишь хороша для обхода огромного количества вложенностей какой-либо структуры данных и всё..
@@tryhard114 я просто думал что она всем понятна, как и итерации в циклах, но так как просят уже много раз видимо надо попробовать рассказать
@@PythonRussian Она скорее всего непонятна таким тупым как я :( Т.е. стэки, информация в виде результата в этих стэках ясна я думаю всем, раскладываемся-складываемся, но условия выхода из Рекурсии это пожалуй основное, то что всем непонятно в Рекурсии.. ( Пишу это для того, чтобы вы взяли во внимание это для вашего бесценного видео ^^)
Имеет ли место использование "умных функций"( когда функция нужна только внутри другой функции и не требуется глобально) в длинных интерпрайс файлах, где нет модульности и выполняется всякое разное от авторизации пользователя до отправки отправки ему почты? Вроде тот подход полезен, когда функция нужна только внутри другой функции и не требуется глобально. Локальные функции помогают упростить код, делая его более модульным и улучшая его читаемость в бесконечной спагеттине или я ошибаюсь?
не знаю что такое интерпрайз файлы без модульности. Внутреннюю функцию лучше использовать только при декораторах, в остальном лучше выносить ее, чтобы можно было протестировать и возможно потом переиспользовать. О бесконечных спагеттинах ничего не знаю
А как же проверка внутри функции типов аргументов? Я вообще из-за этого и начал смотреть выпуск, но так и не услышал об этом. Так ли важно кидать райзы, когда что-то не так?.. И почему?
если в каждой функции проверять аргументы то код сильно разрастется, питон потому и удобен своей динамикой, что мы допускаем другие типы (дактайпинг) в том числе для тестирования. Есть модуль mypy, который позволит проверять типы если они написаны в аннотациях функций. В остальном проверку типов лучше оставить для крайних случаев, подумав нельзя ли полиморфизмом обойтись. Если же что не так, то пусть падает исключение fail fast, которую мы увидим и отреагируем. По той же причине не надо бояться бросать исключения, это даже в дзене питона говорят, ибо если промолчать на исключение и вернуть Нан или просто продолжить работу то можно потом очень долго искать проблему на дебаге. Естественно всегда есть особые случаи.
можно ли передать функцию в качестве параметра при вызове другой функции
да, можно, это не часто нужно, но иногда сильно помогает
Подскажите,
1) а почему в функции replace_fives вы решили сделать ее более универсальной и вынести value (на что заменять) в параметры, но не сделали саму функцию еще более "общей" и не добавили параметр и что искать и замещать? Типа replace_N_to_M. Завтра изменится параметр 5 и придется переписывать всю функцию и менять все ее упоминания? Может стоило ее оставить replace_five_to_six и только со списком? Какие критерии?
2) Почему вы решили вынести функционал записи в файл в отдельную функцию? Ведь в ней вроде нечего тестировать - там только стандартная функциональность языка. Стремление выделить и оформить это в отдельное "действие" понятно, но теряется смысл в тестировании подобных функций. А без смысла теста - это как то странно смотрится, вы ведь выделили это в критерий создания функции. Чем тут руководствуются? Это как будто создавать функцию для print(X), вам не кажется?
подсказываю- функция записи в файл вынесена не для тестирования, а потому что делает ровно 1 вещь и может быть переиспользована в разных местах программы
@@PythonRussian но разве в данном случае это дробление не излишнее? ведь внутри этой функции лишь одно действие вывода строки в файл. так можно и до def my_print(str): print(str) дойти, нет? Я вас не стараюсь как то "подковырнуть", если подумали. В любом случае, спасибо за видео.
я не жалуюсь,) я просто попросил )
ты попросил, а я учел =)
серьезно такие люди существуют о которых вы рассказываете в видео? просто я ни в одном источнике информации ничего подобного не видел, курсы гик и другие не смотрел.
тогда вас ждет еще много открытий, можно начать с форума по питону туда приходят самые разные люди с самых разных курсов.
@@PythonRussian да действительно, открыл первую попавшуюся тему, все как под копирку. Try except с pass, if i==True,я у Немчинского видел, он говорит так индусы пишут.