Простое лучше чем сложное

Дзен Python — философии программирования от Тима Петерса (PEP20)

P ython является одним из самых простых и при этом мощных языков программирования. Он широко востребован сегодня, такие компании как IBM, Google, Facebook и многие другие создают свои продукты именно на Python. Также стоит отметить, что «Питон» — это язык программирования с большим потенциалом на будущее.

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

Одним из важных вкладов в развитие Python стал свод правил Дзен Питон или как его еще называют PEP20 (python enhanced proposal — заявки на улучшение языка Питон) от Тима Петерсона.

История создания PEP20

В 1999 году Тим Петерс предложил свой свод правил по улучшению языка Питон. Дзен Python представлял собой 20 пунктов, последний из которых не был заполнен. Автор предложил написать последнее правило создателю «Питона» Гвидо Ван Россуму. Стоит отметить, что и по сей день последнее правило Дзен-философии от Тима Петерса пустое. Некоторые полагают, что таким образом автор пытался донести до нас, что правила правилами, но могут быть и исключительные ситуации, когда нужно писать код исходя из сложившихся условий, при этом игнорируя установленные нормы.

Сегодня этот свод правил такой же востребованный, как два десятка лет назад. Благодаря этому код, написанный с учетом PEP20, легко читаем для любого программиста. Это особенно актуально при реализации больших масштабных проектов, над созданием кода которых трудится целая группа программистов. Также читабельность кода важна при последующем сопровождении программного продукта – исправлении багов, выпуске обновлений.

Версии PEP

Кроме Тима Петерсона множество других заинтересованный в развитии Python людей подавали заявки на улучшение языка Питон. Каждое такое предложение получает свой номер. На сегодняшний день насчитывается порядка 8 000 таких заявок. Стоит понимать, что только часть из них были приняты. Остальные были либо оставлены на рассмотрение, либо вовсе отклонены.

Но те PEP, которые были приняты, в том числе и PEP под номером 20 от Тима Петерса, внесли свой вклад в развитие Питона.

PEP 20 в консоли

Найти Zen of Python можно на официальном сайте по языку программирования Python. Также ознакомиться с этой информацией можно в консольном приложении Python. Достаточно ввести всего одну команду import this и на экране высветиться свод из 19 правил на английском языке. Выглядит это следующим образом:

Zen of Python на русском языке

PEP20, а если быть точнее, то 19 правил по улучшению языка Питон от Тима Петерса, выглядят следующим образом на русском языке:

Советы по улучшению читабельности кода на Python

Благодаря философии Дзен на сегодняшний день код программ на Питоне один из самых читабельных и простых. Существует свод правил, придерживаясь которым, можно написать красивый код. Итак, нужно знать следующее:

В заключении хочется отметить, что философия Zen of Python от Тима Петерса стала важной ступенью в развитии языка. Питон на сегодняшний день один из самых простых языков программирования для изучения, при этом он открывает широкие возможности для реализации крупных масштабных проектов.

Источник

Пока, Python. Привет, Julia❗

По мере того, как Python замедляет свой впечатляющий темп, растёт новый сильный конкурент.

Не поймите меня превратно. Популярность Python по-прежнему обеспечивается сообществом ученых, дата-сайентистов и специалистов по искусственному интеллекту.

Но если вы когда-либо обедали с этими людьми, то также знаете, как любят они обсудить слабости Python. Начиная с медлительности и заканчивая необходимостью чрезмерного тестирования, вплоть до появления ошибок времени выполнения, несмотря на предшествующее скрупулёзное тестирование — это кого хочешь разозлит.

Поэтому всё больше программистов-питонщиков осваивают и другие языки — лучшими игроками на этом поле являются Julia, Go и Rust. Julia отлично подходит для математических и технических задач, Go — для модульных программ, а Rust — лучший выбор для системного программирования.

Поскольку эксперты по данным и ИИ занимаются множеством математических задач, чаще всего они выбирают Julia. И даже после самой суровой проверки у Julia обнаруживаются свои плюсы, которые Python не может победить.

Так как Python — один из лучших языков программирования, мы в EDISON часто используем его в сложных интересных проектах.

Полное тестирование новой версии сайта было осуществлено на Python и Django.

Дзен Python VS жадности Julia

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

Из этих соображений Гвидо ван Россум создал Python в конце 1980-х для улучшения ABC. ABC был слишком идеален для практического программирования. Хотя жёсткость и требовательность языка облегчала обучение, его было сложно использовать в реальной жизни.

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

Python по-прежнему сохранял преимущества ABC: такие как, к примеру, удобочитаемость, простота и удобство для начинающих. Но Python гораздо надёжнее и адаптирован к реальной жизни, чем когда-либо был ABC.

Этим же руководствуются создатели Julia: они хотят сохранить хорошее из других языков и отбросить плохое. Но в случае с Julia стои́т гораздо более амбициозная задача: вместо того, чтобы заменить какой-то один язык, она хочет превзойти их всех.

Вот что сами говорят создатели языка:

Мы ненасытны: мы хотим большего.

Нам нужен язык с открытым исходным кодом, со свободной лицензией. Мы хотим скорость Си с динамикой Ruby. Мы хотим, чтобы язык был гомоиконическим, с настоящими макросами, такой как Lisp, но с очевидными, знакомыми математическими сущностями, такой как Matlab. Мы хотим настолько же удобное для общего программирования, как Python, такое же простое для статистики, как R, такое же естественное для обработки строк, как Perl, такое же мощное для линейной алгебры, как Matlab, и способное объединять все эти возможности под одной оболочкой. Нечто простое в освоении, но при этом радующее самых серьёзных хакеров. Мы хотим, чтобы язык был интерактивным, и мы хотим, чтобы он был компилируемым.

Julia намерена избавиться от всех своих недостатков, которые у неё пока есть, не обменивая их на недостатки других языков. И хотя Julia является молодым языком, она уже достигла многих целей, поставленных создателями.

За что разработчики любят Julia

Многосторонность

Julia можно использовать для всего: от простых приложений машинного обучения до огромных симуляторов суперкомпьютеров. В принципе, Python может делать то же самое — но он был лишь адаптирован для этого.

Что касается Julia, то она изначально была создана в том числе и для этих задач. По списку снизу вверх.

Скорость

Разработчики Julia хотели получить такой же быстрый язык, как C — но то, что они создали, стало ещё быстрее. Несмотря на то, что в последние годы и Python очень заметно ускорился, его производительность пока далека от Julia.

В 2017 году Julia даже вступила в Petaflop Club — небольшой клуб языков, которые могут достигать скорости в один петафлоп в секунду при максимальной производительности. Помимо Julia, в клубе сейчас только C, C++ и Fortran.

Сообщество

У Python, с его 30+летним стажем, огромное профессиональное сообщество. Вряд ли существует вопрос, связанный с Python, на который вы не найдёте ответ в рамках беглого Google-поиска.

Сообщество Julia, напротив, довольно мало. Вам, возможно, придётся покопаться немного дольше, чтобы найти ответ, снова и снова связываясь с одними и теми же людьми. Налаживание контактов с сообществом само по себе окажется весьма ценным.

Преобразование кода

Можно даже и не знать ни одной команды Julia, чтобы программировать на этом языке. И не только использовать код на Python и Cи. А даже использовать саму Julia в Python!

Излишне говорить, что это позволяет чрезвычайно легко исправить слабые места вашего кода Python. И оставаться продуктивным, пока вы только знакомитесь с Julia.

Библиотеки

Одна из самых мощных сторон Python — миллионы строк в хорошо поддерживаемых библиотеках. У Julia не так много библиотек, и нередки жалобы, что они не поддерживаются на должном уровне (пока).

Но если учесть, что Julia — очень молодой язык с ограниченным количеством ресурсов, количество библиотек, которые уже есть, впечатляет. Помимо того, что количество библиотек растёт, язык также может взаимодействовать с библиотеками C и Fortran, например, для обработки графиков.

Динамическая и статическая типизация

Python на 100% динамически типизирован. Это означает, что программа решает во время выполнения, является ли переменная, к примеру, вещественным или целым числом.

Хотя это очень удобно для новичков, в этом же и кроются причины целого ряда возможных ошибок. Код Python необходимо тестировать для всех возможных сценариев — неблагодарная задача, отнимающая огромное количество времени.

Поскольку создатели Julia также стремятся к тому, чтобы язык был легко осваиваемым, тут тоже полностью поддерживается динамическая типизация. Однако в отличие от Python, вы можете вводить статические типы, если хотите — так, как они представлены, например, в C или в Fortran.
Это может сэкономить кучу времени: вместо придумываний оправданий тому, чтобы не тестировать код, можно указать тип — там, где это имеет смысл.

Данные: инвестируйте в небольшие вещи, имеющие большой потенциал

Всё это, конечно, замечательно, однако важно помнить, что Julia пока крошечная по сравнению с Python.

Показательно, к примеру, количество запросов в StackOverflow с тегом «python» в двадцать раз чаще, чем с «julia»! Это необязательно означает, что Julia непопулярна — скорее, программистам нужно некоторое время, чтобы её принять.

Вы ж ведь не горите желанием здесь и сейчас писать весь свой код на новом языке? Нет, конечно, новый язык скорее предпочтителен для будущих проектов. Это создаёт временну́ю задержку, с которой каждый язык программирования сталкивается между его релизом и его принятием.

Но начать сейчас — что легко, потому что Julia допускает огромное количество языковых преобразований — вы инвестируете в будущее. Поскольку в будущем многие освоят этот язык, у вас уже будут готовы ответы на вопросы, которые перед ними возникнут. Кроме того, ваш код будет более долговечным, так как всё больше кода Python заменяется на Julia.

Подытожим: знание Julia может стать конкурентным преимуществом

Сорок лет назад искусственный интеллект был не более, чем нишевым явлением. Индустрия и инвесторы не верили в ИИ, вследствие чего многие технологии были неуклюжими и сложными в использовании. Но те, кто осознал перспективы тогда, сегодня являются гигантами — теми, кто пользуется таким высоким спросом, что их доход сравним с зарплатами игроков НФЛ.

Точно также и Julia пока ещё нишевая. Но когда она вырастет, ранее принявшие её на вооружение окажутся впереди остальных.

Я не утверждаю, что гарантировано заработаете кучу денег через десять лет, если сейчас возьмётесь за Julia. Но это увеличит ваши шансы.

Подумайте вот о чём: у большинства программистов присутствует Python в их резюме. И в ближайшие несколько лет на рынке труда мы увидим ещё больше программистов на Python. Спрос компаний на специалистов по Python ещё растёт, но этот рост замедляется. Перспективы для программистов на Python ещё долго будут достаточно высоки, но они со временем будут ухудшаться. Сначала этот процесс будет идти очень медленно и незаметно, и в какой-то момент эта неизбежность станет очевидной.

С навыками Julia вы не только покажете, что у вас есть интересы помимо требований к вакансии. Вы также продемонстрируете, что стремитесь к самосовершенствованию и что у вас весьма широкое представление о том, что значит быть программистом. Другими словами, вы подходите для серьёзной работы.

Вы — как и другие программисты на Julia — будущие рок-звезды, и вы это понимаете (хотя бы подозреваете что-либо подобное в глубине души). Или, как заявили создатели Julia в 2012 году:

Признавая свою непомерную алчность, — мы всё также жаждем заполучить всё. Около двух с половиной лет назад мы решили создать язык нашей жадности. Он не завершён, но пришло время для версии 1.0 — созданный нами язык называется Julia. Он уже удовлетворяет 90% наших неблагодарных требований, и теперь нужны неблагодарные требования остальных, чтобы развиваться дальше. Итак, если вы также непомерно жадный и излишне требовательный программист, мы хотим, чтобы вы попробовали Julia.

Источник

Дзен Питона: Как рассказывают Мастера

Дзен Питона впервые увидел свет в 1999 году. Это один из многих аспектов, который добавляет удивительности Python. Это набор выражений, отражающих дух языка. Это было объявлено Тимом Питерсом, авторитетным инженером-программистом, мастером Pythonista и “самым плодовитым и цепким разработчиком ядра Python”, по словам не кого иного, как Гвидо [18]. Эта статья основана в основном на высказываниях основных разработчиков и очень авторитетных членов. Это отличный подарок всем тем, кто интересуется историей скрипта sysadmin, который застал мир (приятным) сюрпризом.

Путь, которым пришел Дзэн, был уникален. Это было отражение от неизвестного Патрика Фалена о чувстве Питона [1]:

.. чем больше я использую и узнаю о языке, тем больше я ценю хороший баланс и вес, который Гвидо дал ему. Тем не менее, кажется, нет ни одного документа, который суммировал бы эту “эстетику”, но, скорее, она имеет тенденцию появляться по частям, с течением времени, в основном в Мудрости председателя Тима.

Это был призыв вселить дух Питона в пришельцев с Земли Перл и за ее пределами. Он запросил от 10 до 20 строк, которые суммируют представление Python

Были бы и Гвидо, и Тим Питерс готовы сотрудничать над короткой статьей-назовите ее “Путь Python” за неимением лучшего названия-в которой излагаются 10-20 предписаний, которые они могли бы предложить тем, кто приходит в Python из других языков и сразу же хочет найти способ согнуть его в неудобные позиции – (реализовать замыкания и т. Д.).

Это была просьба не допустить, чтобы питонисты впали в ошибку, агитируя за изменение языка. Он выступал за то, чтобы проникнуться потоком языка и изменить свои пути и взгляды, а не наоборот. В оригинальном письме он цитировал Фредрика Лунда, который сказал: “Конечно, похоже, что” сообщество “думает, что изменение языка важнее, чем его использование…” [5]. Патрик уточняет:

То, что я имею в виду,-это своего рода очень краткий Strunk-&-White-like “Elements of Style” для Python, который предлагает фундаментальные идиоматические рекомендации для работы в духе языка. Дистилляция Python Zen-это то, о чем я говорю-что-то, что нужно сделать и созерцать, когда децибелы “fix Python now” становятся немного чересчур.

Школа дзэн дает советы и рекомендации. Вы понимаете это своими собственными упражнениями и в компании кого-то опытного в этом ремесле

она снимает акцент с простого знания сутр и доктрин и способствует прямому пониманию через духовную практику и взаимодействие с совершенным учителем или Мастером.]

Дзэн был просьбой помочь людям Python достичь состояния ума Python, чтобы ваш код хорошо резонировал со структурой, стоящей за ним, передавая в процессе связанную красоту, элегантность и утонченность. Эти руководящие принципы, если они будут хорошо пропитаны, сделают ваш кодекс почитаемым в кругу истинных монахов.

Но, как ни странно, Тим рассказывает [19]:

Если бы я хотел что-то изменить, я бы отбросил ссылку на “Дзен”. Это не было частью оригинала и было добавлено кем-то другим.

Другими словами, название не от автора [23]

сорок три страницы суммирования аргументов за чистоту, точность и краткость в использовании английского языка [4]

Эффект книги описан ниже, он был поражен:

он опускал так много ненужных слов, и опускал их так решительно, с таким рвением и явным наслаждением, что часто казалось, будто он сам себя обманул — человек, которому больше нечего сказать, но у которого еще есть время, радиопророк, опередивший часы. Уилл Странк вышел из этого затруднительного положения простым трюком: он произнес каждую фразу по три раза

Одним из эффектов применения Дзэн тогда также были бы более легкие файлы кода.

Мастер Тим услышал просьбу, одобрил требование и ответил соответственно [6]

Очевидно, это работа только для Гвидо-хотя я сомневаюсь, что он возьмет ее на себя (фу-у-у, я бы тоже хотел!). Вот набросок, с которого он начал бы, хотя :

20-е место осталось за Гвидо:

Вот вам: 20 питонских тезисов Fec^H^H^H на носу, считая тот, который я оставляю в Кито, чтобы заполнить.

Почтенный Тим делится тем, как именно появились эти строки [15]:

Это был одноразовый пост из списка питонов. Но, как и все великие триумфы литературы, она была написана во время рекламных пауз, во время просмотра профессионального рестлинга по телевизору и жевания бутерброда с ветчиной. Все верно!

И все же автор категоричен: она полна и более чем удовлетворяет требованию [6]:

Вышесказанное также раскрывает цель Дзэн: решать вопросы дизайна. И это не простое дело. Гвидо говорит [18]:

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

Дзэн дает только контуры, в отличие от Странка и Уайта, которые дают объяснения и примеры в дополнение. Отсюда и необходимость в комментариях. Они помогают не посвященным, не заменяя собой компанию светлых умов.

Во времена колеблющихся и управляемых стандартов ссылка в фактическом документе PEP8 на Странка и Уайта в употреблении английского языка вызвала горькую, уродливую и грязную нить [7]. Это заставило некоторых из лучших людей сообщества отказаться от следования python-list [8], случайного напоминания о том, что быть слишком открытым без ограничений вредно.

Дзэн стал важной частью языка программирования Python. Если вы не знаете дзэн, вы не найдете нужной струны для общения с общиной. Раймонд Хеттингер советует:

Прежде чем создавать новые трекеры, пожалуйста, найдите время, чтобы узнать об истории Python, его использовании и культурных нормах. В частности, прочтите Дзен Питона, подумайте, что подразумевается под утиным набором текста, что подразумевается под “согласным языком взрослых”, что подразумевается под чрезмерной спецификацией и т. Д. В этом отношении Python сильно отличается от Java. [13]

В этом есть и практический аспект. Он популярен, потому что работает [14]. Это золотой руководящий принцип практически во всем, что касается Python.

Наконец, являются ли правила точек Дзен? Какие они на самом деле. Многие люди принимают дзэн за правила. “Самый самоуверенный линтер когда-либо” в свое время фактически включил Дзэн в поддержку своих взглядов [9]. Именно такие ситуации побудили меня написать: Дзен Питона-Это Шутка, И вот Почему [10]. Это было достаточно хорошо для Майкла Кеннеди и Брайана Оккена, чтобы назвать его “обязательным чтением” на байтах Python [11].

По словам Ника Коглана, Дзен дает вам идею, а не все [12]:

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

Самопротиворечивость также случайно является одним из критикуемых аспектов Странка и Уайта [17]. Дзэн также выходит за рамки кодирования, такого как формирование мысленного паттерна признаков [12]:

То, над чем мы работаем как разработчики ядра и начинающие разработчики ядра, – это хорошая дизайнерская интуиция, которая согласуется с дзеном Python. Это не означает, что мы все будем в состоянии в совершенстве сформулировать эту интуицию в каждом конкретном случае, и даже когда мы сможем, эти объяснения сами по себе, как правило, будут подкреплены интуицией, а не строгими научными исследованиями.

Если бы я сам когда-нибудь добавил 20-ю, это было бы: “Используй свое суждение”, Но Ник проиллюстрировал это лучше.

Теперь пришло время увидеть, что на самом деле означает дзэн. Но прежде мы должны знать, что все, что означают слова и понятия в дзэн, не обязательно применимо в других местах [20].

Красивое лучше, чем уродливое.

Красивое и уродливое в этом контексте не имеет ничего общего с человеческой внешностью. Это в том же общем смысле, что и в других технических областях: есть красивая и уродливая физика, красивая и уродливая математика, красивый и уродливый компьютерный код [19]. Красота в дизайне очень похожа на красоту во флоре. Ибо оно относится к общему чувству последовательности, чистоты и выделенности. Она абстрактна и не имеет ничего общего с людьми [20]. Эту строчку можно заменить на “Элегантный лучше, чем неэлегантный”, чтобы лучше понять ее [21]. Линия “красота” – это один из многочисленных контрастов, и о ней следует судить в этом контексте, а не изолированно [22]. В глубине души дизайн Python возник из чувства красоты Гвидо [23]

Явное лучше, чем неявное.

Дзен Python указывает, что “явное лучше, чем неявное” по определенной причине: двусмысленность и неявное знание, которое нелегко передать коду, легко ошибиться и привести к ошибкам. Заставляя разработчиков явно разделять свои двоичные данные и текстовые данные, это приводит к улучшению кода, который имеет меньше шансов иметь определенный класс ошибок.

Было интересно посмотреть, как ppl интерпретирует “явное лучше, чем неявное”, чтобы сказать, что указание “объекта” хорошо. Для меня синтаксический отказ от базового класса является явным, а не подробным и более визуально идентифицируемым

Неявные каталоги пакетов идут вразрез с Дзен Python

Сначала уберите этого с дороги. Как я вижу, неявные каталоги пакетов нарушают по крайней мере 4 принципа проектирования в Zen:

Простое лучше, чем сложное.

В настоящее время, когда я преподаю наборы, я получаю удовольствие от почти нулевой кривой обучения и отсутствия особых случаев. Набор кода становится ярким примером “считываемости” и “простой лучше, чем сложный.” Что еще более важно, я думаю, что есть ценность в простоте API для списков, наборов и диктовок, наших основных инструментов. Четыре набора азбуки в настоящее время отражают эту простоту, и было бы печально, если бы это начало теряться, чтобы сохранить одну строку здесь или там.

Раймонд Хеттингер [39]

Сложное лучше, чем сложное.

oxfordlearnersdictionaries.com дает как сложное, так и сложное как синонимы со значением: “сделано из множества различных вещей или частей, которые связаны; трудно понять”

dictionary.cambridge.org дает сложный как: “имеющий много частей, связанных способами, которые трудно понять” и сложный как: “запутанный или трудный для понимания”

macmillandictionary.com определяет сложное как: “что-то сложное имеет много деталей или мелких частей, которые затрудняют его понимание или работу” и сложное как: “трудно сделать, иметь дело или понять, особенно из-за вовлечения множества различных процессов или аспектов” и 2. “состоит из множества различных, но связанных частей”

merriam-webster.com дает сложное как: целое, состоящее из сложных или взаимосвязанных частей и состоящее из двух или более частей, сложное как: состоящее из частей, запутанно объединенных и трудных для анализа, понимания или объяснения

Мы можем перевести эту строку как означающую:

Решение, состоящее из различных взаимосвязанных частей, лучше, чем решение, которое трудно проанализировать, понять или объяснить

Сложное решение лучше, чем более сложное

Решение, состоящее из различных взаимосвязанных частей, лучше, чем решение, состоящее из множества частей, но трудно поддающееся анализу, пониманию или объяснению

Плоский лучше, чем вложенный.

Вложенность конструкций, таких как условные выражения, функции, классы или модули, одна внутри другой, слишком часто вызывает неодобрение. Пример x.y.z.q.w.w приведен как автор lib, вложивший слишком много модулей один в другой, учитывая утомительный опыт использования

Разреженный лучше, чем плотный.

Когда я направил “разреженный лучше, чем плотный” в качестве одного из фундаментальных принципов дизайна Гвидо, я был так же озадачен, как и все остальные. Действительно, моей первой мыслью было: “Что, черт возьми, это должно означать?!”. Но, как профессиональный ченнелер, я был обязан передавать его по мере того, как он раскрывался, не добавляя и не убирая ни слова.

За прошедшие годы я понял, что оно имеет много значений, некоторые из которых я объяснил вчера. Я узнаю из других вдумчивых постов (таких как ваш), что мне еще предстоит пройти долгий путь в разработке его полной глубины. Или в осознании его полной поверхностности, в зависимости от того, как вы его рассматриваете.

Это определенно часть его. Открытость внешнего вида Python, повсеместное использование диктовок и тщательно подобранная горстка контрольных структур были первыми вещами, о которых я подумал.

Читабельность имеет значение.

Опять это слово “читабельность”. Иногда я жалею, что Дзен Питона не использовал его, потому что все, кажется, думают, что “читаемый” означает “код, который мне нравится”.

Девиз Python-ясность. Язык пытается быть таким же читаемым, как и английский. Гвидо говорит [18]:

Я хотел бы особо отметить одно правило читабельности: знаки препинания должны использоваться консервативно, в соответствии с их общим использованием в письменном английском или алгебре средней школы.

Особые случаи не настолько особенные, чтобы нарушать правила.

Хотя практичность превосходит чистоту.

если вы переходите от 8-битных строк к юникоду с помощью неявного преобразования, текущий дизайн может дать вам:

если вы перейдете от юникода к 8-битным строкам, вы никогда не получите ошибку.

однако результат не всегда является строкой-если строка unicode содержит какие-либо символы больше 127, результатом является двоичный буфер, содержащий закодированные данные. вы не можете использовать строковые методы на нем, вы не можете использовать регулярные выражения на нем. индексирование и нарезка не будут работать.

в моем предложении переход от 8-битных строк к юникоду всегда работает. символ-это символ, независимо от того, какой тип строки вы используете.

однако переход от юникода к 8-битной строке может привести к ошибке переполнения, скажем:

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

[8. Особые случаи не настолько особенные, чтобы нарушать правила.]

Во-первых, я думаю, что дело PyCharm достаточно убедительно само по себе. После того, как я отправил его, я понял, что есть связанный класс инструментов, которые меня интересуют: PyFlakes, PyLint и тому подобное. Я уверен, что статические анализаторы корректности хотели бы иметь возможность автоматически определять “это недопустимое количество параметров для этой функции” для встроенных модулей-особенно для сторонних встроенных модулей! Тот факт, что нам не нужно было бы использовать особый случай pydoc, говорит о том, что это превосходный подход. (“Особые случаи не настолько особенные, чтобы нарушать правила.”)

Ошибки никогда не должны проходить бесшумно.

Если только явно не замолчать.

Таким образом, в Python 2.3 мы отказались от моего доморощенного алгоритма 2.2 MRO в пользу академически проверенного алгоритма C3. Одним из результатов этого является то, что Python теперь будет отвергать любую иерархию наследования, которая имеет несогласованный порядок базовых классов. Например, в предыдущем примере существует конфликт порядка между классами X и Y. Для класса X существует правило, которое гласит, что класс A должен быть проверен перед классом B. Однако для класса Y правило гласит, что класс B должен быть проверен перед классом A. В изоляции это расхождение прекрасно, но если X и Y когда-либо объединяются вместе в одной иерархии наследования для другого класса (например, в определении класса Z), этот класс будет отклонен алгоритмом C3. Это, конечно, соответствует дзенскому правилу Python “ошибки никогда не должны проходить бесшумно”.

Это, конечно, обратно несовместимое изменение семантики ведения журнала: вместо того, чтобы говорить, что ведение журнала будет молчать, если явно не попросят произвести вывод, мы говорим, что ведение журнала всегда будет производить вывод для предупреждений и ошибок (или, возможно, просто ошибок), если явно не заставят замолчать. Это, конечно, соответствует Дзен Python; нынешнее поведение, которое не так выровнено, основано на идее, что ведение журнала не должно влиять на поведение программы, если этого не хочет разработчик программы (в отличие от разработчика библиотеки).

Это также означало бы изменение документации о NullHandler, чтобы сказать: “Если у вас есть сообщения, которые должны выходить, когда вы не можете вызвать исключение, то не добавляйте NullHandler в свои регистраторы верхнего уровня.”

Возможно, вы предпочтете получить исключение для “отсутствующих ключей”, которое поможет предупредить вас об ошибке в вашей программе, в тех случаях, когда вы знаете, что все ks в somekeys определенно должны быть ключами в somedict. Помните: “ошибки никогда не должны проходить бесшумно. Если только явно не замолчать”, цитируя Дзен Питона-Поваренную книгу Питона

Перед лицом двусмысленности откажитесь от искушения угадать.

Что ж, дзен Питона гласит: “Перед лицом двусмысленности откажитесь от соблазна угадать”. Таким образом, это политика, которой следует встроенный диктант – он не пытается угадать, когда делать копию или использовать ли семантику, основанную на идентичности, перед лицом изменчивости. Вместо этого он вызывает исключение во время ввода ключа, прося программиста уточнить свои намерения.

По вопросу : как и нескольким корреспондентам, мне не очень нравится двусмысленность ссылок атрибутов и ключей, хотя она кажется достаточно полезной на практике в веб-фреймворках, которые я использовал. Это, кажется, нарушает Дзен Питона: “Перед лицом двусмысленности откажитесь от искушения угадать.”

К сожалению, я довольно прохладно отношусь к предложению поддержать , поскольку b-это не ссылка на переменную, а литеральная строка “b”. Он также относительно громоздок для разбора. Я хотел бы предложить для этого случая, но это так произвольно…

Теперь вы, вероятно, можете себе представить, почему Python отказывается угадывать среди сотен возможных кодировок. Это решающий выбор дизайна, основанный на одном из принципов Дзен Питона: “Перед лицом двусмысленности не поддавайтесь искушению угадать”.

Должен быть один-и желательно только один-очевидный способ сделать это.

Но помните ТУУТДИ из Дзен Питона.

Дзен Питона говорит, что “должен быть один-и предпочтительно только один-очевидный способ сделать это”. Наличие литералов в языке, которые могли бы представлять либо текстовые данные, либо двоичные данные, было проблемой.

Когда Python развивается, неизбежно появляются новые способы. DeprecationWarning испускаются, чтобы предложить использовать новый способ, но многие разработчики игнорируют эти предупреждения, которые по умолчанию молчат.

Форматирование строк – это одна из тех вещей, которые бросают вызов дзену Python, что должен быть только один очевидный способ делать вещи.

Мариетта Виджая [36]

Следует отметить, что тире здесь не играет никакой роли, так как это способ акцентирования Тима. И надо отметить, что Бретт пропустил это в своем блоге. Возможно, он писал по памяти.

Хотя поначалу это может показаться неочевидным, если только вы не голландец.

В контексте “голландец” означает человека из Нидерландов или человека, проникнутого голландской культурой (прошу прощения за это злоупотребление словом). Я бы сказал по-французски, но каждый француз, которого я спрашивал: “как вы делаете неглубокую копию списка?”, не смог ответить: alist [:] так что я думаю, что это не очевидно для них. Однако это должно быть очевидно для голландцев, поскольку это очевидно для Гвидо ван Россума (создателя Python, который является голландцем), и упорный слух утверждает, что все, кто публикует сообщения в comp.lang.python, на самом деле тоже голландцы. Французы, которых я спрашивал о копировании списка, не были пользователями Python, что является еще большим доказательством (как будто ему нужно было больше).

Или, другими словами, “очевидное” – это отчасти научное, культурное суждение. На самом деле нет ничего универсально очевидного в любом компьютерном языке, несмотря на заблуждающихся сторонников. Тем не менее, большая часть Python очевидна для голландцев. Другим иногда приходится немного поработать над изучением одного очевидного способа в Python, точно так же, как им приходится немного поработать над тем, чтобы научиться ценить тюльпаны и олицетворения Вуди Дятла.

Сейчас лучше, чем никогда.

Хотя никогда не бывает часто лучше, чем сейчас.

Есть также случаи, когда мы решим: “Кажется вероятным, что это может быть хорошей идеей, поэтому давайте попробуем это и посмотрим, что произойдет на практике, а не продолжим спекулировать” – только когда-либо делать вещи, в которых вы уже на 100% уверены, что это хорошая идея, – это рецепт застоя и упадка (отсюда строка “Сейчас лучше, чем никогда” в Дзен).

Если реализацию трудно объяснить, это плохая идея.

Если реализация проста в объяснении, это может быть хорошей идеей.

Да, это то, что все предлагают, чтобы сохранить семантику языка неизменной. Но я утверждаю, что более простое решение-это сказать: к черту эту семантику, давайте изменим ее, чтобы сделать реализацию проще. Это из Дзен Питона: “Если реализация проста в объяснении, это может быть хорошей идеей.” Я думаю, что мало кто может всерьез предложить изменить семантику Python, вот почему я предлагаю это.

Принятие peeps: Немного больше мотивации для моего выбора: перечитывание PEP 549 напомнило мне о том, как его реализация удивительно тонка (призывая Армина Риго; для получения более подробной информации читайте https://www.python.org/dev/peps/pep-0549/#implementation). Напротив, реализация PEP 562 намного проще. Имея в виду Дзен Питона, это дает намек на то, что это лучшая идея, и, возможно, даже хорошая идея.

Пространства имен-это одна из самых замечательных идей-давайте сделаем их побольше!

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

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

Ваши предложения принимаются по адресу: arj [.] python [@] gmail [.] com

Источник