Одна из ошибок кстати промелькнула даже в самом видео) Я понимаю, что здесь код упрощённый, чтобы быстро показать пример, но всё же. Не оборачивайте весь блок кода в try/except. Есть общепринятая практика, что в try мы записываем только те строки, которые могут вызвать исключение. Всё остальное мы пишем за пределами блока try.
это скорее не ошибка новичка, а неуверенность в коде , однако это бесполезно, когда надо проверить строку только на определенные ошибки, например: OSError
Согласен , как считается - в блоке исключения код работает медленнее поэтому да , плюс читабельность кода повышается , ты точно понимаешь на какой строке возбуждено исключене и не надо читать весь блок.
@@kotomen_2019 у меня оно используется для выполнения действий над пользовательскими данными. Я не вкурсе что может написать пользователь и потому вся операция обработки завернута в try. Путем эксперементов я обнаружил гипотетические ошибки во многих местах в связи с неправильным вводом данных и сделал так чтоб при возникновении этих ошибок прекращалась вся программа, но не крашем а print("error")
Добавлю: По возможности используйте кортеж а не список. tuple работает на порядок быстрее чем list. Чем складывать переменные например a+b+c+d лучге используйте sum(a,b,c,d) это также будет намного быстрее работать, функции sum/min/max написаны на C и дают скорость вычислений а используя a+b+c+d мы вычисляем на питоне)
Речь идёт о чуть большем количестве элементов, если вам надо подсчитать сумму списка из 100 миллионов чисел, sum будет в два, если не больше, раза быстрее чем в тупую циклом считать это, проверено.
Кортеж имеет неизменяемый тип данных, т.е. при его изменении (конвертации в список и обратно) происходит его полное копирование в новый pyobject дважды. В то же время список просто добавляет новые значения в уже существующий pyobject. Так что каждый тип данных быстрее в своем назначении.
Ещё можно не бросаться сразу писать код, причем зачастую шаблонно, а подумать над архитектурой и найти более выгодное решение, т.е. использование правильной структуры данных или паттерна. Конечно же, эти вещи сначала изучить, но с практикой дело пойдет быстрее:)
Когда в первый раз садишься делать новый проект-у тебя нет под рукой готовых решений,их или надо искать или пробовать разрабатывать путем своих ошибок,возможно куча огибок будет,так как ты не знаешь о правильности своего решения,пока точно не узнаешь со временем.Для этого нужно написать целую пачку разных прокктов и набраться опыта.И даже после этого экспертом не станешь......
Есть пример, когда использование type() лучше, чем isinstance(). Например проверка переменной на то, является ли она целочисленным значением (int). Если булевую переменную (bool) X поместить в isinstance(X, int), то на выходе мы получим True, потому что isinstance() проверяет наследование классов по иерархии. Type() же проверяет строго ли относится какой-то тип к конкретному классу, без учёта наследования.
Говоря про isinstance, следует упомянуть что он используется для определения принадлежности объекта к классу или любому его надклассу, в то время как type позволяет строго определить именно тип. Проще говоря, isinstance (True, int) вернёт True т.к. bool является дочерним классом от int. Так что это не плохая практика какая то, нужно просто понимать что вы хотите в своем коде сделать. И если с базовыми объектами эти нюансы можно иметь в виду, т.к. об этом в целом есть информация в поле зрения комьюнити, то в собственной программе при использовании наследования и наличии десятков/сотен классов отнаследованных от множества других, это может сыграть злую шутку. Isinstance и type делают похожие вещи, но они не равны друг другу и в некоторых сценариях НЕ взаимозаменяемы
ну, например, часто замечал, что люди проверяют пустоту списка следующим образом: if some_list == [] или if len(some_list) == 0 лучше всего проверять так: if not some_list
Ещё ошибки новичков: Сложные условия, ветвления If elif, не однозадачные классы/функции, множественное наследование (более 3 родителей), декораторы статик метод (там где нужно бы вынести функцию из класса), применение eval. Что вспомнил сходу) Игнорирование дандеров и аннотаций)
например цикл for и следующее за ним условие в котором при определенном условии вызывается continue. не использование тернарного оператора. употребление булева в условии чтобы вернуть из функции True или False if a==True: return True else: return False
2:49 Я знаю что эти изменения сохраняются. Но иногда это полезно, чтоб они сохранялись, например в функциях с рекурсией. Или отслеживание изменений чего либо.
Ещё когда употребляют чрезмерную вложенность конструкций в ущерб читабельности. По мне, так нужна золотая середина. Потому что программирование это больше про чтение кода, а не про написание, а некоторые как понапишут одной строчкой такой длинный огород, что потом фиг его прочитаешь, да ещё без комментариев...
Не знаю только у меня или ещё кого то есть такая ситуация, когда при продумывании алгоритма решения задачи, первое что приходит на ум это сложные структуры. Хотя на самом деле не зная их можно было более просто и понятно написать код. Например, начинаешь думать, о это надо через рекурсию идти, пишешь, дебажишь, а через несколько дней озарение, а нафиг вообще я это сделал и через обычный цикл for все прошло. Вот такое за собой заметил- не нужно усложнять.
Странно. А у меня, как у новичка, обедненные знания по инструментам и я страдаю от простоты своего мышления. По части решения задач. Ну типа как на обитаемом острове, я имею только топор и верёвку. В то время как у остальных есть и клей и дрель и лопата с пистолетом. А я про пистолет и не слышал никогда, и про дрель. Сверлю вот.. топором (( ))
Создание списков с определенным шаблоном в несколько строк? Когда можно вычитать данные с файла и записать в список подряд с изменением, скажем, типа в инт с делением надвое, можно использовать [int(i)/2 for i in file.readlines()], а не присваивать сначала список из строк определенной переменной, а потом проходиться по всей переменной через цикл, потом, перед этим объявив еще одну переменную, добавлять в нее уже готовые элементы подряд.
Спасибо, только это не совсем новички, а те уже которые потихонечку шарят, но однозначно спасибо честно я из этого видео запускаю только 2 ошибки это тонирование и принт, спасибо вам огромное
На счет is и знака равенства я не согласен, это совсем разные вещи. is проверяет ID объекта, и если допустим есть int a и int b, которые оба равны 4444, то is выведет False, при том как знак равенства выведет True. По крайней мере, это работает в питоне версии 3.10*.
Как раз хотел написать, что не объясняя почему это так работает, найдутся люди, которые не поймут логики. Тут дело в том, что None - интернируемое имя, т.е. оптимизируется CPython и всегда ссылается на один Pyobject (не путайте с объектами python), по той же причине в вашем примере переменные a и b будут равны при сравнении через is в ряде случаев, например если объявлены впервые и не изменялись. Не верите? Проверьте)
Я тут немного впрягусь за if: pass Не так давно на codewars решал задачку где в какой то момент в зависимости от значений 2х переменных у меня было 4-5 вариантов действий, а в части вариантов одна из них могла быть равна 0 и тогда не надо делать ничего. В итоге решил самое первое условие задать if not (a and b): pass Что бы на нулевых значениях не делать 5 ненужных вычислений.
Нууу... 3. Конструкция try:finally часто предпочтительнее простого with, т.к. мы сможем а) залогировать ошибку, б) обработать ошибку, в) код становится куда более интуитивный. Особенно, если много ждунов, а ролик на них вроде бы и ориентирован. with - это скорее семантический сахар и он удобен в довольно простых ситуациях с минимальной вероятностью ошибки и/или минимальной бизнес-логикой. Но explicit better than implicit. Более того, если что-то подобное используется в долгоживущих приложениях, то with всё равно потребуется оборачивать с try:except, а это дополнительные отступы, а много отступов - минус зрение. 8. Подмена понятий. Какая-то мнимая производительность (в пайтоне то) с семантикой. Предложенный вариант всего лишь семантически куда более верный. Понимание кода в философии пайтона стоит во главе угла, поэтому очень много уделяется именно идиомам и лаконичности. Писать понятный код это далеко не тоже самое, что писать производительный код (не просто ортогональные понятия, а часто - взаимоисключащие), что может неверно навести на мысль новичков, что в пайтоне имеет смысл экономить бюджет CPU. Нет, не имеет, а преждевременная оптимизация - корень всех зол. 9. Снова какая-то подмена понятий. Мало того, что ни слова про __bool__, так ещё и почему-то считается, что пустая коллекция - это False. Это ближе к сахару и идиомам самого пайтон, чем чему-то общепринятому, так что стоило подробнее рассказать, откуда беруться ноги этой практики. Более того, часто практика if bool(x): является осознанной, в рамках explicit better than implicit. 10. Что-то очень странное. И вместо нормального logging (встроенного!) с объяснением, что такое журналы, хендлеры, фильтры и зачем они нужны (но да, кролячья нора) - loguru - простейший "дроп-ин" реплейсмент для простых проектов без многих, порой необходимых, вещей. И да, это внешняя зависимость, тогда как logging уже есть в самом пайтоне, а его простейшее использование не такое уж и ужасное, как его часто малюют.
По поводу второй привычки не совсем согласен. Иногда, в случае сложной логики лучше пожертвовать парой строчек кода ради лучшей читаемости. По крайней мере мне так бывает проще. А ещё (может в комментариях уже упоминалось) ВСЕГДА пишите комментарии. Хоть чуть чуть, хоть пару строчек. Иначе, через полгодика, вы сами не сможете понять что тут понаписано.
Я бы сказал так - писать так, что бы код был читаемым и понятным без использования комментариев. Комментарии для описания целей, идеи, идеологии. Хорошо написанный код комментирует себя сам
Поспорю про принты. На момент отладки проще воткнуть print(1) или другой символ который программой точно не выведется чем писать логи, ктомуж если умеешь писать то на момент отладки у тебя максимум 2-3 принта которые никак не проблема убрать
Забавно, что в этом списке из 10 нет одной из самых распространенных - итерирование не по коллекции, а по ренджу с извлечением значений по индексу (си-подобный цикл for)
И кстати в примере с условиями 2 - 0:55 используется неправильный exit, понятно, что вычурный пример, но все же exit принято использовать в интерактивных оболочках, но в скриптах для выхода используется sys.exit
Заметил за собой что если писать типа if not isinstance(5,int) это раздражает больше чем если If isinstance(5,int) По возможности избегайте not - в сложных if, он может озадачить, например так: If not rating !=5: Print('good')
Сам таким страдал 1. Огромные функции, с проверками, действиями и прочим, строк на >100 Нужно разделить на разные функции по смыслу, и одному действию. 2. не используются тайп хинтинги и докстринги.
Забывать сохранять код каждые n минут.Перебои с электричеством, бзики компилятора, синий экран, да что угодно - если в вашей среде разработки отсутствует функция автоматического сохранения кода, пожалуйста, жмите ctrl+s(или любую другую комбинацию, отвечающую за сохранение) как можно чаще, вы сбережёте уйму часов работы, труда и, что главное, нервов.
a = [1, 2, 3] b = [1, 2, 3] c = a print(a is b) # False, потому что a и b - разные объекты в памяти print(a is c) # True, потому что a и c - один и тот же объект в памяти print(a == b) # True, потому что значения списков a и b одинаковы
От себя скажу - я все еще не искоренил в себе вещь типа "type(n) == list". А, касательно "ошибок", я бы вот такую вещь выделил: def do_smth(n): if n == 1: return False else: return True Вот когда вижу такое - ретурн через елс, меня просто выворачивает. def do_smth(n): if n == 1: return False return True То, как стоило бы использовать, ИМХО.
Добрый день. Была 4я. Но не очень понимаю как перейти от нее к исправленному варианту. У меня подключение к sql'у, с отправкой данных. Не могу сообразить как без try'я мне except'нуть текст ошибки? PS я правильно понял, что после with... мне вообще не нужно делать sqlite_connection.close()? Использую стандартную конструкцию из учебника через try: { connect(), всякие там execute() и.т.п. } ... except: print(error) ... finally: close(), встроенную sqlite3.
Хеллоу, май дир френд. Я таки вот все понимаю, когда-то я вас попросил создать игру, где ты типа грибок и прыгаешь по супермарио, но вот та концепция, которая вот на фоне показана - это не совсем то, что я подразумевал. Левел дизайн, конечно, получился хорошо, примерно то, как 2д игра и должна выглядеть в 2022 году, но сама концепция и вот эти модельки все же не совсем то, чего я ожидал. Переделайте, пожалуйста, спасибо.
Видео очень полезным оказалось для меня, т.к. я только начал изучать Пайтон, и мне это всё как раз кстати. Но я не смог поставить лайк, и даже не буду его скачивать, потому что создатель умудрился обосрать видео, поставив в фон игру! Возможно это реклама, и ему это было нужно! Но чёрта с два! Я не мог сосредоточиться на коде, и всё что мне остаётся сделать - ставить на паузу, выписать 10 пунктов, и забыть про это видео навсегда.
А, да. Основная ошибка новичка в изучении пайтхониума - это изучение пайтхониума, а не правоставного Дарта, извините за кибербуллинг и всего вам хорошего!
Введу пару корректировок автору, другим тоже будет полезно знать :) • f строки не всегда быстрее, это можно проверить по модулю disutils. • Насчёт except я ну не совсем согласен, ибо тот же контекстный менеджер supress из contextlib + модуль keyboard. • Насчёт is есть замечания! Оператор == вызывает метод класса __eq__, а is проверяет по типам, если класс пользовательский, тобиш None is NoneType вернёт True, когда с == будет False.
@@zproger Речь касается обычного "logging", насколько я понимаю. Допустим, нельзя ли воспользоваться подключением logger.info('The log is yours') к файлу (через logger), а позже в настройках приложения, чтобы потом сделать вывод логов в файл или терминал (чаще данную практику вспоминаю с Django-приложениями). Просто интересно стало.
Я хоть и Джун, но все кроме привычки принтов вместо логов не имею. И по поводу логов. Логи нужны, как либа и нужно отслеживать непосредственно взаимодействия между модулями, если ты пишешь скрипт, то логи будут излишние и не читаемы, сами сеньоры со стажем 10 лет работы используют принты непосредственно в самом одном каком-то скрипте.
Тут все зависит от назначения. Никто не будет спорить, что в процессе непосредтсвенной разработки для быстрого дебага лучше всего подойдут принты, хотя более чем очевидно, на те модули, которые частенько независимо дебажаться, лучше сразу юнит тесты заводить. Но на мой субъективный взгляд логи необходимы в случае, если скрипт, т.е. модуль (либо пакет - набор модулей в папке с __init__.py) будет работать процессом, все логи будут попадать в системный журнал, и весьма полезно и удобно будет либо грепом, либо аргументами journalctl фильтровать и просматривать логи. Также ещё одним преимуществом использования логгеров являться возможно конфигурировать начальный уровень логирования. Если подытожить, я бы сказал, что принты могут быть полезны только для быстрого дебага или гразных скриптов proof of concept, которые не будут использованы в будущем напрямую (только идея). Лично я не понимаю откуда у людей такая любовь к loguru, почему многие пытаются избежать использования стандартной библиотеки logging, которая намного чище, гибче и удобнее (имхо), чем эта разноцветный зверь, который создает при импорте свой инстанс.
11 и самая главная ошибка не только питонистов и не только новичков - записывать серьезные видео с фоном из всяких игр, может не стоит уподобляться говорящим головам типа хауди и тд
@@zproger простой неотвлекающий фон, желательно без смысловой нагрузки, если уж хочется движения, пусть частицы какие медленно летают, посмотрите у django school стримы
@@zproger ну новички и не согласились. и псевдопрогеры которые думают что уже кодили чтото крупное. вылавливать баги без дебаггера на сотнях листах кода норм такие дурачки
И что здесь плохого? В описании указал автора, взял несколько ошибок, чтобы принести пользу русскоязычному сообществу. Или Вы думаете что автор этого видео все ошибки сам придумал?) Они в любом случае откуда-то копируются (с гугла, с статей, с книг, с других видео). Человек такое существо которому свойственно копировать и передавать информацию, никто не придумывает ничего нового, всё откуда-то транслируется. Все мои остальные видео это информация о Python, но учил я его по книгам и получается что я копирую информацию из книг)
@@zproger если ты и вправду указал источники то все нормально, просто я в первый просмотр думал что ошибки ты сам вспомнил из своего опыта, из-за чего сложилось впечатление обмана
Ладно, ты просил комментарий, поэтому уже после пункта три не могу удержаться. Ты себя описываешь? Новички не используют ручного форматирования, большинство о нем в принципе не знает и юзают f строки и только их, на счет if else, ну вообще какой-то бред, а на счет закрытия файла и конструкции with написано в каждой книге, даже в пайтон для детей, много книг говоришь прочитал? А автор этих книг Хайди Хо?) Иду дальше слушать этот бред из пальца... А все, досмотрел... Вся херня из пальца высосана... Ты описываешь ни новичка, а прям совсем идиота не умеющего видимо ни читать ни мыслить.
![ZProger [ IT ]](http://yt3.ggpht.com/ytc/AIdro_nEayoD4jBvKkG7VFnuTm_Rnd64g6RPSHL9K53LulYXDQ=s48-c-k-c0x00ffffff-no-rj)
Какая ошибка из этого видео была у вас?
Автор isnstance() и type(obj) - неравнозначные конструкции. И как раз второе более верно в большинстве случаев так как не учитывает базовые классы.
Принты для отладки
Почти все
спасибо за видео,
1,4,10 - постоянно
Только сегодня узнал, что не правильно указывал значения по умолчанию в функциях... никогда бы не подумал и не замечал проблем с этим...
Одна из ошибок кстати промелькнула даже в самом видео) Я понимаю, что здесь код упрощённый, чтобы быстро показать пример, но всё же. Не оборачивайте весь блок кода в try/except. Есть общепринятая практика, что в try мы записываем только те строки, которые могут вызвать исключение. Всё остальное мы пишем за пределами блока try.
это скорее не ошибка новичка, а неуверенность в коде , однако это бесполезно, когда надо проверить строку только на определенные ошибки, например: OSError
Согласен , как считается - в блоке исключения код работает медленнее поэтому да , плюс читабельность кода повышается , ты точно понимаешь на какой строке возбуждено исключене и не надо читать весь блок.
@@kotomen_2019 у меня оно используется для выполнения действий над пользовательскими данными. Я не вкурсе что может написать пользователь и потому вся операция обработки завернута в try. Путем эксперементов я обнаружил гипотетические ошибки во многих местах в связи с неправильным вводом данных и сделал так чтоб при возникновении этих ошибок прекращалась вся программа, но не крашем а print("error")
Это не ошибка
Добавлю:
По возможности используйте кортеж а не список. tuple работает на порядок быстрее чем list.
Чем складывать переменные например a+b+c+d лучге используйте sum(a,b,c,d) это также будет намного быстрее работать, функции sum/min/max написаны на C и дают скорость вычислений а используя a+b+c+d мы вычисляем на питоне)
т.е. выполнить сложение это дольше чем заполнить 4 регистра, вызвать функцию, сделать тоже самое сложение и вернуться из функции с результатом?
Речь идёт о чуть большем количестве элементов, если вам надо подсчитать сумму списка из 100 миллионов чисел, sum будет в два, если не больше, раза быстрее чем в тупую циклом считать это, проверено.
@@XpIOHdeJIb3000 Беги читать про паттерн "Интерпретатор"
Use iter and next for big volume data.
Кортеж имеет неизменяемый тип данных, т.е. при его изменении (конвертации в список и обратно) происходит его полное копирование в новый pyobject дважды. В то же время список просто добавляет новые значения в уже существующий pyobject. Так что каждый тип данных быстрее в своем назначении.
Ещё можно не бросаться сразу писать код, причем зачастую шаблонно, а подумать над архитектурой и найти более выгодное решение, т.е. использование правильной структуры данных или паттерна. Конечно же, эти вещи сначала изучить, но с практикой дело пойдет быстрее:)
Это да, потом часто такой код нужно переписывать, если нет изначально четкой архитектуры
Когда в первый раз садишься делать новый проект-у тебя нет под рукой готовых решений,их или надо искать или пробовать разрабатывать путем своих ошибок,возможно куча огибок будет,так как ты не знаешь о правильности своего решения,пока точно не узнаешь со временем.Для этого нужно написать целую пачку разных прокктов и набраться опыта.И даже после этого экспертом не станешь......
Есть пример, когда использование type() лучше, чем isinstance().
Например проверка переменной на то, является ли она целочисленным значением (int). Если булевую переменную (bool) X поместить в isinstance(X, int), то на выходе мы получим True, потому что isinstance() проверяет наследование классов по иерархии. Type() же проверяет строго ли относится какой-то тип к конкретному классу, без учёта наследования.
о да! не раз споткнулся об этот isistance)
Говоря про isinstance, следует упомянуть что он используется для определения принадлежности объекта к классу или любому его надклассу, в то время как type позволяет строго определить именно тип. Проще говоря, isinstance (True, int) вернёт True т.к. bool является дочерним классом от int. Так что это не плохая практика какая то, нужно просто понимать что вы хотите в своем коде сделать. И если с базовыми объектами эти нюансы можно иметь в виду, т.к. об этом в целом есть информация в поле зрения комьюнити, то в собственной программе при использовании наследования и наличии десятков/сотен классов отнаследованных от множества других, это может сыграть злую шутку. Isinstance и type делают похожие вещи, но они не равны друг другу и в некоторых сценариях НЕ взаимозаменяемы
Даёшь гайд по Логуру!)
:0
ну, например, часто замечал, что люди проверяют пустоту списка следующим образом: if some_list == [] или if len(some_list) == 0
лучше всего проверять так: if not some_list
Хороший совет, спасибо
Или же if len(list_).
@@KadenDev зачем лен?
Можно просто: if list_: pass
Главная ошибка новичка - клюнуть на работу в дружном коллективе над интересным проектом.
аххха)) ну зато опыт будет неплохой
можно поподробнее? возможно, я прямо сейчас на этом этапе)
а где еще набираться опыта?
Ещё ошибки новичков:
Сложные условия, ветвления If elif, не однозадачные классы/функции, множественное наследование (более 3 родителей), декораторы статик метод (там где нужно бы вынести функцию из класса), применение eval. Что вспомнил сходу)
Игнорирование дандеров и аннотаций)
Моя частая ошибка: Стараться писать более универсальные функции, где этого делать не обязательно.
(во вред времени и сложности)
Ну частично это и хорошая привычка, главное не перестараться :)
например цикл for и следующее за ним условие в котором при определенном условии вызывается continue. не использование тернарного оператора. употребление булева в условии чтобы вернуть из функции True или False if a==True: return True else: return False
Спасибо, кайфовый видос)
Благодарю
Полезное видео. На удивление, каждая проблема, практически без изменений, применима и к c#
2:49 Я знаю что эти изменения сохраняются.
Но иногда это полезно, чтоб они сохранялись, например в функциях с рекурсией. Или отслеживание изменений чего либо.
За логгинг спасибо, не задумывался на самом деле об этом)
Круто =)
Ещё когда употребляют чрезмерную вложенность конструкций в ущерб читабельности. По мне, так нужна золотая середина. Потому что программирование это больше про чтение кода, а не про написание, а некоторые как понапишут одной строчкой такой длинный огород, что потом фиг его прочитаешь, да ещё без комментариев...
Не знаю только у меня или ещё кого то есть такая ситуация, когда при продумывании алгоритма решения задачи, первое что приходит на ум это сложные структуры. Хотя на самом деле не зная их можно было более просто и понятно написать код. Например, начинаешь думать, о это надо через рекурсию идти, пишешь, дебажишь, а через несколько дней озарение, а нафиг вообще я это сделал и через обычный цикл for все прошло. Вот такое за собой заметил- не нужно усложнять.
Обычно у многих такое, со временем всегда приходят идеи как можно сделать код проще :)
Странно. А у меня, как у новичка, обедненные знания по инструментам и я страдаю от простоты своего мышления. По части решения задач.
Ну типа как на обитаемом острове, я имею только топор и верёвку. В то время как у остальных есть и клей и дрель и лопата с пистолетом.
А я про пистолет и не слышал никогда, и про дрель. Сверлю вот.. топором ((
))
Полезное видео, спасибо, обнаружил у себя ошибки 5 и 8, иногда 9:)
Рад что помогло
Спасибо за видео, подчерпнул для себя некоторые моменты, которые упускаю в своём коде)
Это хорошо :)
*Почерпнул.
установи pylint расширение, он многие из этих ошибок показывает
Создание списков с определенным шаблоном в несколько строк?
Когда можно вычитать данные с файла и записать в список подряд с изменением, скажем, типа в инт с делением надвое, можно использовать [int(i)/2 for i in file.readlines()], а не присваивать сначала список из строк определенной переменной, а потом проходиться по всей переменной через цикл, потом, перед этим объявив еще одну переменную, добавлять в нее уже готовые элементы подряд.
Спасибо, только это не совсем новички, а те уже которые потихонечку шарят, но однозначно спасибо честно я из этого видео запускаю только 2 ошибки это тонирование и принт, спасибо вам огромное
Пожалуйста, рад что видео принесло пользу
На счет is и знака равенства я не согласен, это совсем разные вещи. is проверяет ID объекта, и если допустим есть int a и int b, которые оба равны 4444, то is выведет False, при том как знак равенства выведет True. По крайней мере, это работает в питоне версии 3.10*.
Тут именно про Nonetype речь шла.
Как раз хотел написать, что не объясняя почему это так работает, найдутся люди, которые не поймут логики. Тут дело в том, что None - интернируемое имя, т.е. оптимизируется CPython и всегда ссылается на один Pyobject (не путайте с объектами python), по той же причине в вашем примере переменные a и b будут равны при сравнении через is в ряде случаев, например если объявлены впервые и не изменялись. Не верите? Проверьте)
По поводу ведения логов. А чем не устраивает стандартная logging?
Больше по душе loguru, не нужно в конфигурациях копаться
Начало положено 😁 закончить нужно паттернами и шаблонами проектирования 🙏
😭 пытаюсь их понять и запомнить
И до этого дойдем :)
Я тут немного впрягусь за if: pass
Не так давно на codewars решал задачку где в какой то момент в зависимости от значений 2х переменных у меня было 4-5 вариантов действий, а в части вариантов одна из них могла быть равна 0 и тогда не надо делать ничего.
В итоге решил самое первое условие задать
if not (a and b):
pass
Что бы на нулевых значениях не делать 5 ненужных вычислений.
Привет. Если еще помнишь, можешь дать ссылку на задачу?
Часто у себя исправляю вложенные условия. Тоесть условия внутри условий, часто их можно в одно объеденить
Нууу...
3. Конструкция try:finally часто предпочтительнее простого with, т.к. мы сможем а) залогировать ошибку, б) обработать ошибку, в) код становится куда более интуитивный. Особенно, если много ждунов, а ролик на них вроде бы и ориентирован. with - это скорее семантический сахар и он удобен в довольно простых ситуациях с минимальной вероятностью ошибки и/или минимальной бизнес-логикой. Но explicit better than implicit. Более того, если что-то подобное используется в долгоживущих приложениях, то with всё равно потребуется оборачивать с try:except, а это дополнительные отступы, а много отступов - минус зрение.
8. Подмена понятий. Какая-то мнимая производительность (в пайтоне то) с семантикой. Предложенный вариант всего лишь семантически куда более верный. Понимание кода в философии пайтона стоит во главе угла, поэтому очень много уделяется именно идиомам и лаконичности. Писать понятный код это далеко не тоже самое, что писать производительный код (не просто ортогональные понятия, а часто - взаимоисключащие), что может неверно навести на мысль новичков, что в пайтоне имеет смысл экономить бюджет CPU. Нет, не имеет, а преждевременная оптимизация - корень всех зол.
9. Снова какая-то подмена понятий. Мало того, что ни слова про __bool__, так ещё и почему-то считается, что пустая коллекция - это False. Это ближе к сахару и идиомам самого пайтон, чем чему-то общепринятому, так что стоило подробнее рассказать, откуда беруться ноги этой практики. Более того, часто практика if bool(x): является осознанной, в рамках explicit better than implicit.
10. Что-то очень странное. И вместо нормального logging (встроенного!) с объяснением, что такое журналы, хендлеры, фильтры и зачем они нужны (но да, кролячья нора) - loguru - простейший "дроп-ин" реплейсмент для простых проектов без многих, порой необходимых, вещей. И да, это внешняя зависимость, тогда как logging уже есть в самом пайтоне, а его простейшее использование не такое уж и ужасное, как его часто малюют.
По поводу второй привычки не совсем согласен. Иногда, в случае сложной логики лучше пожертвовать парой строчек кода ради лучшей читаемости. По крайней мере мне так бывает проще.
А ещё (может в комментариях уже упоминалось) ВСЕГДА пишите комментарии. Хоть чуть чуть, хоть пару строчек. Иначе, через полгодика, вы сами не сможете понять что тут понаписано.
Совсем забыл сказать про комментарии, это самое основное :0
Я бы сказал так - писать так, что бы код был читаемым и понятным без использования комментариев. Комментарии для описания целей, идеи, идеологии. Хорошо написанный код комментирует себя сам
Супер!! 9 из 10!
Спасибо!
Спасибо за советы! Полезно!
П.с. Что за игра на фоне?))
Где-то в комментах отвечал, уже забыл даже название игры :)
Поспорю про принты. На момент отладки проще воткнуть print(1) или другой символ который программой точно не выведется чем писать логи, ктомуж если умеешь писать то на момент отладки у тебя максимум 2-3 принта которые никак не проблема убрать
я втыкаю print() #удалить, а потом ищу все строки удалить и удаляю
Спасибо тебе продолжай в том же духе
Благодарю :)
Спасибо, полезно. Очень нравятся твои видео и особенно подача)
Рад слышать, спасибо :)
Забавно, что в этом списке из 10 нет одной из самых распространенных - итерирование не по коллекции, а по ренджу с извлечением значений по индексу (си-подобный цикл for)
И кстати в примере с условиями 2 - 0:55 используется неправильный exit, понятно, что вычурный пример, но все же exit принято использовать в интерактивных оболочках, но в скриптах для выхода используется sys.exit
Охохо, после этого видео я вспомнил столько ошибок, что ещё на 10 таких роликов хватит ;D
Да, пример с exit был с максимальным стёбом) Однажды встретил у одного разработчика такой код, и теперь не могу это забыть :)
а если нужно в одном цикле изменить значения одного массива относительно другого?
@@Hocotun если нужно менять значения списка - используй enumerate
Спасибо заотличное видео.
Рад что понравилось :)
Заметил за собой что если писать типа
if not isinstance(5,int)
это раздражает больше чем если
If isinstance(5,int)
По возможности избегайте not - в сложных if, он может озадачить, например так:
If not rating !=5:
Print('good')
f строки не все версии python поддерживают. особенно на raspberry pi это частая проблема. поэтому лучше format. по скорости не уступает.
Можно и format, тут уже от задачи надо отталкиваться
Сам таким страдал
1. Огромные функции, с проверками, действиями и прочим, строк на >100
Нужно разделить на разные функции по смыслу, и одному действию.
2. не используются тайп хинтинги и докстринги.
Ты выдал базу
А чем плох стандартный модуль logging?
Забывать сохранять код каждые n минут.Перебои с электричеством, бзики компилятора, синий экран, да что угодно - если в вашей среде разработки отсутствует функция автоматического сохранения кода, пожалуйста, жмите ctrl+s(или любую другую комбинацию, отвечающую за сохранение) как можно чаще, вы сбережёте уйму часов работы, труда и, что главное, нервов.
поставь в VSCode опцию SaveOnEdit
a = [1, 2, 3]
b = [1, 2, 3]
c = a
print(a is b) # False, потому что a и b - разные объекты в памяти
print(a is c) # True, потому что a и c - один и тот же объект в памяти
print(a == b) # True, потому что значения списков a и b одинаковы
1:48 в каком смысле "более безопасно"? Разве там под капотом не формируется то же самое try-finally?
Вы не понимаете, это другое
От себя скажу - я все еще не искоренил в себе вещь типа "type(n) == list".
А, касательно "ошибок", я бы вот такую вещь выделил:
def do_smth(n):
if n == 1:
return False
else:
return True
Вот когда вижу такое - ретурн через елс, меня просто выворачивает.
def do_smth(n):
if n == 1:
return False
return True
То, как стоило бы использовать, ИМХО.
Можно ещё проще:
Просто проверять:
n != 1.
И тогда и функции не надо писать отдельно, и от блоков if... else можно отказаться
@@-MaCkRage-, я надеюсь, что ты понимаешь, что пример функции я привел первый попавшийся, да?
@@7IdE Но он всё верно написал же
def do_smth(n):
return n != 1
do_smth(1) # False
do_smth(2) # True
К сожалению источником большинства ошибок являются учебники :-)
Тоже верно
А что за игра идёт фоном?
Можно ли из notion перенести заметки в obsidian?
Я так то уже Middle Python разработчик но были ошибки
Да, бывает =)
Подскажите какой IDE вы пользуетесь и какую тему вы используете
VsCode + Dracula
@@zproger спасибо большое
@@zproger что лучше использовать для начинающего на питоне VScode или PyCharm
1:06
if not status:
exit
По поводу is вместо ==, питон будет выдавать следующее SyntaxWarning: "is" with a literal. Did you mean "=="?
Не всех это останавливает
1:25 open("BlaBla","w").write("что-то") и все
Добрый день. Была 4я. Но не очень понимаю как перейти от нее к исправленному варианту.
У меня подключение к sql'у, с отправкой данных. Не могу сообразить как без try'я мне except'нуть текст ошибки?
PS я правильно понял, что после with... мне вообще не нужно делать sqlite_connection.close()? Использую стандартную конструкцию из учебника через try: { connect(), всякие там execute() и.т.п. } ... except: print(error) ... finally: close(), встроенную sqlite3.
Хеллоу, май дир френд. Я таки вот все понимаю, когда-то я вас попросил создать игру, где ты типа грибок и прыгаешь по супермарио, но вот та концепция, которая вот на фоне показана - это не совсем то, что я подразумевал. Левел дизайн, конечно, получился хорошо, примерно то, как 2д игра и должна выглядеть в 2022 году, но сама концепция и вот эти модельки все же не совсем то, чего я ожидал. Переделайте, пожалуйста, спасибо.
Ладно :(
Я джва года ждал эту игру
А нельзя заменить if status == 0 на if not status?
Нет
0 это int, а not это булевая величина
@@zproger А почему?
Учу язик Python уже 3 день, відео топ.Но пока нечего не понимаю)
Благодарю
Не знаю было или нет, это игнорирование list comprehension, почему-то многие это игнорируют и не хотят использовать.
"Библиотека логур" (logger)... Понимаю
Глаза раскрой
некоторые из этих проблем показывает pylint
1:11 exit(0) if not status else ...
Что за игра кста на фоне?
Что за игра на фоне в начале?
Сам являюсь новичком, но подобных ошибок не допускал
Круто что делаете изначально правильно :)
А где ты брал курсы? Или у кого учился чтобы не допускать это изначально?
Видео очень полезным оказалось для меня, т.к. я только начал изучать Пайтон, и мне это всё как раз кстати. Но я не смог поставить лайк, и даже не буду его скачивать, потому что создатель умудрился обосрать видео, поставив в фон игру! Возможно это реклама, и ему это было нужно! Но чёрта с два! Я не мог сосредоточиться на коде, и всё что мне остаётся сделать - ставить на паузу, выписать 10 пунктов, и забыть про это видео навсегда.
Четко
А, да. Основная ошибка новичка в изучении пайтхониума - это изучение пайтхониума, а не правоставного Дарта, извините за кибербуллинг и всего вам хорошего!
:0
Признак плохого видео на ютуб - не делать тайм коды
Видео слишком короткое для тайм кодов, я их ставлю на видео, которые больше 10м
Я всегда думал что == и is это разные вещи
Опасно новичкам использовать оператор is без понимания его работы. Могут напихать везде где не нужно. 😆
Это точно =)
Самая бесящая ошибка новичков: в условии сравнивать булеву переменную со значением истины (или лжи)
Введу пару корректировок автору, другим тоже будет полезно знать :)
• f строки не всегда быстрее, это можно проверить по модулю disutils.
• Насчёт except я ну не совсем согласен, ибо тот же контекстный менеджер supress из contextlib + модуль keyboard.
• Насчёт is есть замечания! Оператор == вызывает метод класса __eq__, а is проверяет по типам, если класс пользовательский, тобиш None is NoneType вернёт True, когда с == будет False.
А зачем использовать сторонние библиотеки для логирования, если есть прекрасная встроенная? Особенно новичку.
Вы про print?))
@@zproger Речь касается обычного "logging", насколько я понимаю.
Допустим, нельзя ли воспользоваться подключением logger.info('The log is yours') к файлу (через logger), а позже в настройках приложения, чтобы потом сделать вывод логов в файл или терминал (чаще данную практику вспоминаю с Django-приложениями).
Просто интересно стало.
Одиннадцатая ошибка откладывать код на долго
Двенадцатая ошибка не писать для большого кода комментариев
А почему для большого кода не надо писать комментарии?)
Обычно для маленьких проектов можно и не писать, а для больших
крайне необходимо.
@@zproger я имел в виду что нужно(крайне не обходимо!) писать комментарии для большого кода. А некоторые не пишут комментарии
Я хоть и Джун, но все кроме привычки принтов вместо логов не имею.
И по поводу логов. Логи нужны, как либа и нужно отслеживать непосредственно взаимодействия между модулями, если ты пишешь скрипт, то логи будут излишние и не читаемы, сами сеньоры со стажем 10 лет работы используют принты непосредственно в самом одном каком-то скрипте.
Тут все зависит от назначения. Никто не будет спорить, что в процессе непосредтсвенной разработки для быстрого дебага лучше всего подойдут принты, хотя более чем очевидно, на те модули, которые частенько независимо дебажаться, лучше сразу юнит тесты заводить. Но на мой субъективный взгляд логи необходимы в случае, если скрипт, т.е. модуль (либо пакет - набор модулей в папке с __init__.py) будет работать процессом, все логи будут попадать в системный журнал, и весьма полезно и удобно будет либо грепом, либо аргументами journalctl фильтровать и просматривать логи. Также ещё одним преимуществом использования логгеров являться возможно конфигурировать начальный уровень логирования. Если подытожить, я бы сказал, что принты могут быть полезны только для быстрого дебага или гразных скриптов proof of concept, которые не будут использованы в будущем напрямую (только идея).
Лично я не понимаю откуда у людей такая любовь к loguru, почему многие пытаются избежать использования стандартной библиотеки logging, которая намного чище, гибче и удобнее (имхо), чем эта разноцветный зверь, который создает при импорте свой инстанс.
9 совет скорее вредный, чем полезный. Код должен быть самодокоментируемый, по возможности, а не максимально короткий
Ну ты загнал - новички))), как по мне главная ошибка новичков, это то что большинство из них забросит программирование после "Hello World"
Ну их даже новичками не назвать, это мимо проходящие люди
Ну я только ошибку #1 допускаю
11 и самая главная ошибка не только питонистов и не только новичков - записывать серьезные видео с фоном из всяких игр, может не стоит уподобляться говорящим головам типа хауди и тд
Заметил по себе что видео с различными "хакерами" на фоне уже всем надоели, надо что-то новенькое
@@zproger простой неотвлекающий фон, желательно без смысловой нагрузки, если уж хочется движения, пусть частицы какие медленно летают, посмотрите у django school стримы
я прям профи )))
Че за игра на фоне
Отвечали в комментах, я уже и не помню что это за игра :D
if status: # тоже самое что if status != 0:
Ещё могу сказать как новичок. Что ничего сказанного в этом видео я незнаю))) по ходу видео уже для новичков, которые не новички
Уровень новичков вырос, теперь новичок это тот, кто может написать фейсбук с нуля за 1 день
@@zproger по ходу. Щас как раз прохожу курс на степике для начинающих. Люблю задачки. Хотелось бы ещё понимать где их применить и когда
Самая главная ошибка не соблюдение РЕР8 и тайпинга
Это да
Ошибки ли. Тут вопрос. Явных то ошибок нет
Это скорее правила хорошего тона
новички откладывают изучение дебаггера. и очень очень зря
Говорил в другом видео об этом, 40% не согласились)
Многим значит дебаггер не нужен, но время придет =)
@@zproger ну новички и не согласились. и псевдопрогеры которые думают что уже кодили чтото крупное. вылавливать баги без дебаггера на сотнях листах кода норм такие дурачки
2:25 и они потом еще над php шутят
th-cam.com/video/qUeud6DvOWI/w-d-xo.html
эх, я был лучшего о тебе мнения
И что здесь плохого? В описании указал автора,
взял несколько ошибок, чтобы принести пользу русскоязычному
сообществу. Или Вы думаете что автор этого видео все ошибки сам придумал?)
Они в любом случае откуда-то копируются (с гугла, с статей, с книг, с других видео).
Человек такое существо которому свойственно копировать и передавать информацию,
никто не придумывает ничего нового, всё откуда-то транслируется.
Все мои остальные видео это информация о Python, но учил я его по книгам и получается
что я копирую информацию из книг)
@@zproger если ты и вправду указал источники то все нормально, просто я в первый просмотр думал что ошибки ты сам вспомнил из своего опыта, из-за чего сложилось впечатление обмана
Ошибки из опыта обычно тоже вспоминаю, но мне понравилось именно это видео и подумал что будет полезно передать их в наше сообщество
Желаю 0 дизлайков)
Спасибо :D
Их отключили)))
Ладно, ты просил комментарий, поэтому уже после пункта три не могу удержаться. Ты себя описываешь? Новички не используют ручного форматирования, большинство о нем в принципе не знает и юзают f строки и только их, на счет if else, ну вообще какой-то бред, а на счет закрытия файла и конструкции with написано в каждой книге, даже в пайтон для детей, много книг говоришь прочитал? А автор этих книг Хайди Хо?) Иду дальше слушать этот бред из пальца... А все, досмотрел... Вся херня из пальца высосана... Ты описываешь ни новичка, а прям совсем идиота не умеющего видимо ни читать ни мыслить.
Спасибо за советы! Полезно!
П.с. Что за игра на фоне?))
Где-то в комментах отвечал, уже забыл даже название игры :)
TAILS OF IRON
@@as-master8458 да ведь это натуральная калька с salt and sanctuary
А шо за игра на фоне?