ТОП 5 Ошибок в написании функций Python

⭐ Курс ООП и Приват канал: www.zproger-sc...
⭐ Телеграм канал: t.me/+zS0X6UO2...
В данном видео рассмотрим самые популярные ошибки при написании функций в Python. Если вы часто допускаете эти ошибки, то это может повлиять на структуру вашего кода, на легкость его поддержки и также может забрать у вас много времени при попытке что-то исправить.
Исправление этих ошибок в вашем Python коде, поможет в разы улучшить ваши проекты и легкость их поддержки.
📁 Github: github.com/Zpr...
📁 Все плейлисты с уроками: bit.ly/39GaY89
📁 Связаться со мной: [e-mail]
📁 Все плейлисты с уроками: bit.ly/39GaY89
📁 Поддержать криптовалютой: github.com/Zpr...

[@MEZHGANO]

Все по делу, спасибо. Если вдруг кто не в курсе, то комментарий к функции лучше писать в тройных кавычках в теле функции, тогда он появится в подсказке при наведении курсора на функцию

[@zproger]

Спасибо за дополнение к видео, это хороший совет

[@fearruxx]

несколько курсов на степике прошел по питону, видел как люди писали в функциях аннотацию, но не понимал для чего конкретно это нужно, теперь разобрался; начал смотреть твой канал и ты мне очень помогаешь в понимании этого языка, спасибо тебе, твой канал один из лучших по питону!

[@dmitrykoklyagin2916]

1. Думаем над именами функций и классов. Код пишется один раз, а читается постоянно. 2. Type annotations для функций и внимательно отслеживаем несоответствия по типам данных на уровне проекта. Очень много херни позволяет отловить с минимальной задержкой. 3. Докстринги, в которых описываемых всё, что функция принципиально делает. Комментарии - только там, где надо пояснить какое-то неочевидное решение, из-за, например, изврата бизнес-логики. 4. from xxx import * --- должен вообще не пройти код ревью коллег и не попасть в мастер. 5. В числе ревьюеров должен быть маньяк идеи чистого кода, нам повезло, у нас их два.

[@zproger]

Маньяки чистого кода это хорошо

[@dann1kid]

Со всеми пунктами согласен

[@riventarakoss1546]

Не понимаю, почему ролик выходит то для новичков, то для тех, кто уже смешарик. Это БАЗА

[@zproger]

Бывает =)

[@bspumo3830]

Лайк за смешариков 👍🏿

[@savtis2606]

Базированный гигачад

[@killuar0294]

Сколько часов в шарараме?

[@frontend_developer_anti_vata]

​@@killuar02948 лет умножить на 8760 часов = 70080

[@SolistTV]

6:28 лишним плюсом реализации методов класса вместо функций будет полиморфизм, который станет, доступным для методов. Об уникальности методов нужно будет думать только в рамках класса, а не всей системы. К тому же, созданный класс задаст контекст использования методов, будет проще контролировать инпут/аутпут.

[@MaxusR]

Насчёт неочевидных имён функций согласен на все 200%, а вот насчёт требования к уникальности названий категорически против. Кто сделал import *, тот сам дурак. А если в двух разных модулях функции выполняют логически одно и то же, но по-разному, то почему-бы и не назвать их идентично.

[@zener_blitz]

Так речь идёт не про разные модули, в разных модулях эти функции не будут пересекаться.

[@aliakseybaradulkin2443]

Я бы добавил еще про ОПП Мы должны использовать классы осознанно, не просто для того что б имена функций были более краткими и понятными, а с какой то целью например хранение состояния (это было сказано, но как дополнительный бонус) или возможности полиморфизма и прочие плюсы классов просто использовать функции что б сократить имена классов и тд - это не правильно

[@SashaGun_GD]

import * нужен только в tkinter

[@CultureofSpeech]

Браво маэстро, а когда будет продолжение этой темы разговора расскажете ⁉️

[@irwe3514]

Очень интересно и информативно, жду следущих видео)

[@zproger]

Благодарю :)

[@SYPERSTAR1986]

Спасибо большое дружище, очень крутой и познавательный видос!!!

[@zproger]

Спасибо =)

[@romanbush5164]

Молодец объяснил чистый код и принципы солид), а про scores это жесть, поэтому лучше писать в ооп стиле

[@ИванНикитин-ч7б]

3:46 Развёрнутые комментарии лучше всего делать внутри функции для объяснения смысла алгоритма и всяких не очевидных "подводных" особенностей. А короткие комментарии должны быть превращены в название функции, в которую войдёт комментируемый кусок кода.

[@vasiliynet3425]

В примере про скорс, с добавлением числа в массиву, меняется аргумент, чего в чистых функциях быть не должно, поэтому и возникло затруднение при вызовах. Должен был создаваться новый массив и возвращать результат. В JS это понимание очень часто играет.

[@MagMigo]

Могу про лямбду добавить: есть вот люди, которые постоянно везде суют лямбду, т.е. x = lambda y: y ** 2 print(x(5)) Сделайте вид, что тут что-то сложное. И вот, часто замечал, что многие любят делать огромные строки, где тупа одна лямбда как какая-то функция Это нарушение PEP8 про длину строки и ещё одно нарушение, что лямбда используется неправильно (даже в пепе есть (!!)) Правильно лямбда используется в таких моментах: print(sorted(["c", "b", "a"], key=lambda x: x[0].lower())) # prints: ['a', 'b', 'c'] Это просто пример, но думаю суть ясна. Вооооооооооооооооот, да

[@nickolayfetlistov4416]

За видео спасибо, уже так сказать опытная котлета но на одном из первых собесов с ссылочками на листочки поплыл) Полезно однако)

[@zproger]

Рад что помогло =))

[@ЕвгенийИрдеев]

Спасибо!Информативно и полезно!

[@zproger]

Благодарю

[@random_kirill]

Смотрел это видео и одновременно делал оператор "в" в своем языке :P

[@КириллЕвплов-з4г]

Спасибо за информативный и понятный контент)

[@zproger]

Рад что понравилось

[@eugenebybin6403]

Спасибо за видео, структурированно и понятно

[@zproger]

Рад что понравилось

[@otetz77]

Импорт через звездочку просто надо себе запретить. Оооочень много проблем снимает. А в удобстве почти не теряешь с современными редакторами.

[@zproger]

Согласен

[@YourCloseCoop]

3 совета очевидны (овер или недокоммент, нет аннотаций, плохое название функции). Как предложение, можно добавить объяснение поч плохо сохранять лямбды в переменные, использовать простые функции в абстракциях (для новичков может быть непонятно), почему перегрузка функций typing.overload с одним и тем же параметром с разным названием вне .pyi файла вообще нежелательно (Моё мнение).

[@Novice2213]

append_score(score, scores=[]) - имба вообще, не знал о таком, спасибо!

[@Анимешница-я1у]

Можешь напомнить плз, какой дистрибут линукса ты юзаешь???

[@zproger]

ZorinOS

[@demg7738]

Правильные советы, только возвращаемый тип в первом примере лучше сделать list[int].

[@nikolaymatveychuk6145]

Первая рекомендация про именование хорошая, хотя не нова (тут следует сослаться на того же Макконнелла с его книгой "Совершенный код"). Остальное - nah... Насчёт методов, которые предлагается в класс обернуть - там сразу value и values лишние, потому что не добавляют ничего к пониманию сути функций (понятное дело что речь про значения, а не неопределённости или незначимости). Да и вообще лучше указывать что на что делится, потому метод должен зваться так, чтобы код получился вроде с = a.divideBy(b), иначе будет не понятно то ли a на b делится, то ли наоборот. Да и попытка создать класс на пустом месте - плохая идея, иначе следовало бы отказаться от выражений вида a*b, a + b, a % b и так далее и всё следовало бы их писать как a.mod(b), a.multiplyBy(b), a.divideBy(b) и т.д.. Раз мы все так не делаем, то следует предположить, что идея плохая и классы придуманы для другого (а такое "нововведение" лишь без причины усложнит код). Насчёт передачи по ссылке параметра по-умолчанию - я бы это охарактеризовал как баг питона. Согласен, работая с питоном об этом следует знать и в этом плане респект автору (лично я на питоне не пишу, потому для меня это было открытием). Но это значит, что в питоне не скалярные параметры с заданным значением по-умолчанию использовать нельзя, потому что это по определению функция грязная, которая обязательно породит непредсказуемое поведение. Потому часть про "если вы знаете как, то можете это использовать" из разряда вредных советов.

[@ПавелВикторов-п4ю]

Да, интересно тут)) Если можно голосовать за тему для выпуска, то голосую за борьбу с круговыми импортами)

[@zproger]

Хорошая идея, спасибо

[@dowlso]

3:12 Вы хоть сами поняли, что написали, может быть вы имели from lib import * : в таком случае все функции и классы запишутся в основной модуль А если import lib : то к функциям и классам придётся обращаться через имя библитеки и уникальность уже не обязательна

[@zproger]

действительно, даже и не заметил как написал это

[@Троль-н7в]

Ну ошибся человек, с кем не бывает

[@PRONCHENKO]

Привет, а каким дистрибутивом ты пользуешься?

[@MagMigo]

Вроде как это манжаро какая-то

[@zproger]

ZorinOS

[@PRONCHENKO]

@@zproger Спасибо

[@aleksversus]

def - создаёт объект класса function, которому назначаются поля. Если мы не переопределяем эти поля при вызове функции, естественно мы работаем со значениями, которые уже определены для полей. За счёт этого, как я понимаю, работают всякие функции-генераторы. Да, это поведение не вполне очевидно, если мыслить в рамках процедурного программирования, к сожалению.

[@ИннаЛиксакова-о4н]

Видео очень хорошее, но можно было бы сюда сразу теории докинуть, так как в видео упоминается, и про Single responsibility principle , и про DRY, и про KISS

[@АлексейБогомолов-ж2ф]

На питоне пишу неделю. До этого практически ничего не кодил . Какой прием успел вывести: Сперва высматриваю в задаче задачки поменьше. То есть, пишу мини библиотеку методов под одну задачу. Нафига: а чтоб не запутаться. Это как собирать дом готовыми модулями. Конечно не все действия так заранее прописываю, только более или менее типовые.

[@thegate8985]

Привет! Спасибо за ролик! Очень не хватает разбиение ролика на таймкоды :(

[@shinkun4614]

Хороший видосик)

[@zproger]

=)

[@dath]

Это же чистый код в вольном пересказе, хосподе, это же такая база

[@zproger]

ещё бы =)

[@blanjel6921]

Найс, выучил Python, теперь иди учи английский, потому что циклы циклами, а названия за тебя никто не придумает :D Спасибо за полезный материал! Но не проще ли просто писать коммент к функции и не париться с придумываем названий, особенно когда у тебя в одной проге 100500 этих функций и уже фантазия закончилась :D

[@greshnik_d]

4 года сижу на питоне, аргсы и кваргсы использовал только в обучении. Что я делаю не так?

[@garrywood9195]

В формах в джанго не попадались? Например добавить данные из базы в форму?

[@4aidze]

не наследуешь методы у сложных классов с полиморфизмом)

[@GladSpiR]

7:04 а что тут не так? вполне может быть оберткой для трубы, а далее уже по логике но название и действия должны как-то матчится 2:06 это же язык динамической типизации зачем резать на входе-то? Массивы же разные могут быть, тут или имя менять или логику внутри функции.

[@АлексейСтручев-т1ж]

Скажите, пожалуйста. Почему функция называется get_array, если возвращает не array, а list?

[@MagMigo]

Список в питон практически тоже самое, что и массив Да, всё же разное, но имеет место быть

[@nakidai]

@@MagMigo Это не практически тоже самое, у массивов есть свой тип, и все его элементы одного типа. А в списках типа нет, и элементы могут быть любые.

[@zproger]

Ну это ведь пример) а вообще списки и массивы отличаются между собой, и об этом есть след.видео: kzbin.info/www/bejne/lYeXeGd3btuYnqs

[@QwDragon]

Args мне кажется довольно полезной штукой. По крайней мере в js используется не так уж редко.

[@andrewbobrow3815]

Я наверно спрошу какую-то глупость... Я понял, что функция append_score где-то там внутри хранит значение аргумента по умолчанию - список по умолчанию scores - и при каждом вызове функции без указания аргумента по умолчанию этот "список по умолчанию" дополняется. Вопрос - как добраться до этого "списка по умолчанию" извне этой функции? Или инкапсуляция этого не позволит? То есть - вызвали функцию без аругмента по умолчанию, она внутри себя создала переменную типа указатель (с простым числом это не прокатывает), этот указатель указывает на одну и ту же область памяти, и при каждом вызове функции без аргумента по умолчанию содержимое этой области памяти ("список по умолчанию") последовательно модифицируется. И этот "список по умолчанию" хранится до конца работы пограммы, но до него никак не добрешься? Я примерно предполагаю ответ - доступ к этому "списку по умолчанию" должен быть предусмотрен логикой программы, в данном примере такого доступа нет - ну и доступа нет. Но все равно страннно. В этом есть какой-то полезный смысл, или это побочный эффект архитектуры Питона?

[@apxapa8749]

Есть конечно доступ через магические методы, спроси чат жпт

[@stargrapefruit]

Что за приложение для кода?

[@КириллЧе-я5ы]

Хорошая практика имхо - не писать комменты на каждой строке функции, а документировать ее той же док строкой…

[@DERJNDZE]

Вместо, а даже лучше вместе с комментариями хорошо использовать докстринги. Если не хочется лезть в модуль и вычитывать там функционал функции, просто пишешь хельп(), и он у тебя на ладони. Тоесть в докстринги пишем комментарии по использованию, в обычные коменты - по реализации

[@zproger]

Да, вот только кликнуть по функции быстрее, чем вызывать help, но docstring крутая штука

[@andreypronko1859]

Всё правильно. Если даже тебе нет дела до тех, кто согнал тебя с работы, и теперь поддерживает твой код, позаботься о себе драгоценном. Понять собственный код, который ты писал год назад, особенно в крупном проекте, на пару сотен питон-файлов, очень не просто. Надо осмысленно называть модули, функции, классы, и даже соорудить простейший сервер с документацией и поиском по ней.

[@endlessvd]

А чё делать на C++? Там нет всех этих удобных штучек, все сердито

[@zproger]

Писать с нуля =)

[@dx8026]

1. Документируем только функции или методы класса 2. Пишем чистый код Вот и всё))

[@nartoomeon9378]

Из последнего коротко: меньше кода, больше функционала.

[@JustLikeChannel]

какой у вас дистрибутив?

[@zproger]

ZorinOS

[@NearBirdsamp]

Раз 10 за 3-4 года использовать *args и **kwargs - смешно Самый банальный и частоиспользуемый пример - wrapper'ы

[@ybw____]

возможно имеет смысл рассказать как избегать цыкличных импортов?

[@zproger]

Да, расскажу в ближайшем видео

[@andywinonhalloween]

bad practice делать импорт через *

[@zproger]

Согласен

[@nouaksomtac6782]

*args и **kwargs исползуетса доволна часто в декораторах и прий написаний библиотекий

[@SergeyKozhukhov]

Ну, первый совет - это очень круто, но чревато циклическим импортом. Я ставлю описание типа в doc string.

[@MagMigo]

Чтоб решалась проблема с цикличным импортом и существует константа typing.TYPE_CHECKING

[@klausfernius5115]

Крутое и полезное видео, но про память все равно не понял

[@darjusvasiukevic2120]

Я человек простой, тыкаю пальцем в букварь - называю функцию

[@zproger]

😮

[@dann1kid]

про датаклассы расскажи. Слотс, фриз там вот это вот всё

[@non5309]

Что-то все в кучу и солид принципы и нейминг и аннотация и изменяемые типы.

[@zproger]

Это да, но думаю лишним не будет

[@QwDragon]

Аннотации мне тоже показались неожиданными в этом видео, а остальное - всё по теме.

[@aleksei_stereo]

А где в видео разбор проблемы с картинки?

[@УголокКодера]

Насчет args, kwargs не совсем согласен, часто использую, особенно когда нужно наследовать какой-либо класс и добавить в него свой функционал, не изменяя уже существующий, но пример из видео, да, согласен - ужас)

[@zproger]

Имелось в виду не использовать тогда, когда без него можно спокойно обойтись =)

[@УголокКодера]

@@zproger ну это да, просто вы начали говорить, что за все время раз 5 использовали, мне это показалось странным

[@amadeus1300]

спс за видосян

[@zproger]

Рад стараться =)

[@dmitry-lz1ny]

А что делает **? Одинарная * это распаковка, а двойная для чего?

[@zproger]

* - распаковка списков ** - распаковка словарей

[@span4ev]

import lib import * хм... Может всё таки from lib import *?

[@zproger]

да, там ошибка которую я неосознанно совершил

[@smilekun2825]

Пожалуйста не юзайте списочные выражение с лямбдой на лямбде заправленной условиями и распаковкой. Это буквально криг души и каждый раз хочется орать когда видишь такой код

[@АндрейГоляновский-х4й]

мдеее. Товарищи, пишите на шарпе. лучше шарпа ничего нет и никогда не будет!

[@zproger]

у каждого свой идеальный язык =)

[@lichcraft_official]

А будет контент по rust?

[@zproger]

Хотелось бы, но опыта в нем ещё маловато

[@lichcraft_official]

@@zproger Как и у меня. Каждый день узнаю что-то новое для себя.

[@YourCloseCoop]

Нафига, а главное зачем? Этот язык уже давно дед инсайт

[@MagMigo]

@@YourCloseCoop че несёшь, раст развивающийся и хороший язык

[@АнтонК-м8о]

При чём тут пайтон? Данные рекомендации относятся к большинству языков программирования

[@zproger]

Согласен, но примеры именно на Python, поэтому назвал видео таким образом.

[@АнтонК-м8о]

​@@zproger Да, это понятно. Просто точно такие же темы обсуждаются в других языках программирования и точно так же не указывается что это общие правила программирования. Но понравилось чьё-то высказывание: "Самое главное и самое сложное в программировании- правильно назвать функцию".

[@iljakot_tran4131]

Пусть тебе из множества N возможных лайков, return N[-1]

[@ПавелВикторов-п4ю]

Зачет)

[@artembagachkov933]

Вау, 30к, супер!

[@zproger]

=)

[@zluka7951]

дядя Боб для маленьких

[@zproger]

:)

[@mair1735]

почему-то мне вспомнился YANDERE simulator

[@zproger]

Странно :D

[@shrimp4567]

Почти все про очевидные вещи, да и не все они фатальны

[@dnr_8365]

Странно, ролику больше года и ни одногт лайка?

[@vladelcapitan]

В плане типов данных, принимаемых аргументов проблема всех не строго типизированных языков. На Цпп такого не встретить

[@T0unFl3it]

Здравствуйте, одна маленькая поправочка: Вы здесь имеете в виду языки со _статической типизацией_, где типы переменных и выражений объявляются программистом или выводятся компилятором. Определение же "строгой/слабой" типизации зависит от сообщества, в котором употребляется. Иногда термин "строгая типизация" используется как синоним статической типизации (как в Вашем комментарии), но есть также и такое (на мой взгляд, лучшее) определение: язык является "строго типизированным", если он не позволяет нарушить собственные абстракции (такие, как типы данных) (по крайней мере, в "безопасных" контекстах). В таком понимании язык Python является строго типизированным языком с динамической типизацией, а C++ является слабо типизированным языком со статической типизацией (т.е., понятия "строгости" и "времени" типизации ортогональны). Просто мои пять копеек, думаю, кому-то будет полезно знать о таких альтернативных определениях ;-)

[@dann1kid]

Разбей видос на главы, а то некоторые фичи я уже знаю, а где ты описываешь другие я хз

[@David_USA]

Пожалуйста, ТАЙМ-КОДЫ!

[@RoKivals]

Во второй ошибке (про уникальность имён функций и конфликт с другими либами) откровенно говоря бред. По вашей логике, человек при подключении библиотек должен прочитать абсолютно все ее функции и их имена, чтобы не повториться, вместо того чтобы просто нормально импортировать. Да и вообще можно было приличия ради добавить, как решить проблему ссылочного типа в аргументе

[@zener_blitz]

IDE подскажет если ты перезапишешь функцию из модуля это раз. Как правило в модулях просто функций нет, есть только методы внутри класса это два. Скорее речь шла о ваших собственных модулях. Не используйте wildcard import это три)

[@ИванГолышев-с6д]

Спасибо, огромное за такие ролики, жалко, что ты не можешь сравниться с активностью с миллиониками которые снимают говно контент

[@zproger]

Ну я выпускаю видео каждые 7 дней, за ~3 года ни разу не отошел от этих сроков =)

[@alfobarasovich55]

@@zproger смотрю тебя как аниме сериал еженедельно ждя новые серии :D

[@zproger]

:D

[@ИванГолышев-с6д]

@@zproger имелось ввиду активностью на канале: просмотры, лайки и т.п.

[@zproger]

А, ну если снимать гавно то тоже будет активность большая) Но мне не интересно такое снимать

[@printon4087]

Можете порекомендовать ресурс для изучения Python, может книжку какую-то? Оплачивать обучение на данный момент не очень хочу, как минимум потому что мне 15 лет. Смотрел уже 3 бесплатных курса на ютубе, но хочу продвигаться дальше.

[@2707B]

Sololearn, Проект Эйлера (первые 35 упражнений, дальше больше математика. С какого-то момента сложность резко возрастает, так-что несколько дней на упражнение станет нормой) и если совсем ноль в программировании "Грокаем алгоритмы". Когда добрался до них показались примитивными, но может просто забыл как учился ездить на велосипеде. Дальше гугл, свой проект и возможно Лутц. Лутц это не учебник, а скорее справочник. Читать только чтобы убедиться что ничего не пропустил, и то через год-полтора. Советую так же уже сейчас учить слепую печать. Полотенце на клавиатуру, указательные на пупырки и 30 минут в день месяц-полтора. После такой базы скорость печати вернется на прежний уровень и практику можно будет набивать на бытовом печатании. Сам проходил в 14, когда даже не думал о программировании. Зачем? В темноте не было видно клавиатуры :D Ах да, нулевой язык программирования - английский. Любой интернетный текст в зубы (Литературный носители переусложняют) и переводим гугл-переводчиком слово за словом примечая частые. Первые 50 часов ничего в голове задерживаться не будет, и это нормально. И не стоит гнаться за "100%" английским. Его не бывает. Игровой, ютуберный, программисткий, математический английские - выбери кусочки и все. По своему опыту так же скажу, что чтение можно выучить в вакууме. Произношение, слух и разговор можно отложить лет до 20. Так же для мотивации идеально подойдут уроки. В 9 классе за вами как раз перестанут следить, если не уже. Ну и бонус за простыню. Написано так ясно, что переводчик переводит как с русского на русский: betterexplained.com/articles/a-visual-intuitive-guide-to-imaginary-numbers/

[@ai-katrin]

Тут бы зашел тикто надо вот так

[@TePeM]

А ещё, когда опорожняетесь- снимайте штанишки. Для кого этот мануал? Я без негатива к автору, просто интересно- есть люди, которые изучают синтаксис/продвинутый уровень и для них это не очевидно?

[@4aidze]

угу, знаю таки, кодят как орки, знают кучу языков и фреймворков

[@4aidze]

и не один не используют нормально

[@Dark161161]

Грамотно

[@zproger]

Благодарю

[@ХристяДаревич]

корисно

[@zproger]

Спасибо!

[@red__floyd]

ПОЧЕМУУУУ ФУНЦИЯ?????

[@MagMigo]

Что

[@nakidai]

Потому, что не процедура

[@stepandemin5836]

Ничего полезного. Очередной говнокод от виндузяшника

[@zproger]

ну не смотрите тогда, никто не заставляет