На Хабре уже описывали историю создания Python. Но мы решили не просто пересказать события ещё раз, а увидеть их глазами Гвидо ван Россума: что он сам думал обо всём происходящем? Поэтому нашли и перевели ранние высказывания, которые помогают лучше понять, почему Python стал именно таким и что определило его популярность.
Начало
Все началось с того, что в декабре 1989 года голландец Гвидо (Guido van Rossum) — будущий создатель одного из самых популярных языков программирования — искал хобби-проект, которому можно было бы посвятить рождественские каникулы… Сам Гвидо вспоминает это время так:
Впереди были двухнедельные рождественские каникулы, и мне было нечего делать. Мне нужен был проект, который я мог бы реализовать на своем Mac, не заходя на компьютеры CWI.
("I had a two-week Christmas holiday with nothing to do, and needed a project that I could do on my Mac without having to log into CWI's computers.")
К этому моменту за плечами у него был Университет Амстердама (University of Amsterdam), степень магистра по математике и компьютерным наукам и среди прочего, работа в National Research Institute for Mathematics and Computer Science в Нидерландах (по-голландски заведение также называют Centrum Wiskunde & Informatica, CWI).
До 1987 года Гвидо состоял в команде, которая разрабатывала новый язык ABC. Любопытно, что ABC был одним из первых шагов к тому, что мы сейчас называем консьюмеризацией технологий, но язык так и не получил признания. Зато Python впоследствии продолжил его идеи. Об этом Гвидо отзывался так:
ABC задумывался как язык программирования, которому можно было бы научить интеллектуальных пользователей компьютеров, которые не были программистами или разработчиками ПО. В конце 1970-х основные создатели ABC обучали такую аудиторию традиционным языкам программирования. Среди их учеников были разные ученые — от физиков до социологов и лингвистов — которым требовалась помощь в использовании их очень больших компьютеров.
Хотя эти студенты сами по себе были умными людьми, они удивлялись определенным ограничениям и правилам, традиционно устанавливаемым языками программирования. Создатели ABC попытались разработать другой язык, опираясь на отзывы этих пользователей.("ABC was intended to be a programming language that could be taught to intelligent computer users who were not computer programmers or software developers in any sense. During the late 1970s, ABC's main designers taught traditional programming languages to such an audience. Their students included various scientists—from physicists to social scientists to linguists—who needed help using their very large computers.
Although intelligent people in their own right, these students were surprised at certain limitations, restrictions, and arbitrary rules that programming languages had traditionally set out. Based on this user feedback, ABC's designers tried to develop a different language.")
Идею нельзя назвать уникальной. В то время подобную позицию пытался занимать Basic. Но с ним были проблемы:
Версии Basic, доступные в то время, были ужасны. Почти любая интересная программа на Basic была полна низкоуровневых хаков, где нужно было ткнуть в 714-й байт памяти, чтобы изменить цвет фона экрана на жёлтый.
("The Basic versions available at the time were horrible. Almost any interesting Basic program was full of low-level hacks, where one had to poke memory byte 714 to change the screen background color to yellow.")
В 1986 Гвидо покинул команду ABC и перешел в проект по созданию распределенной ОС Amoeba.
Со временем там возникла потребность в разработке простого языка сценариев наподобие ABC, при этом уже существовавший на тот момент Perl портировать на Amoeba было нельзя. Возможно, этому ограничению мы и должны сказать «спасибо» за появление Python.
О том, как выглядела задача изначально:
Каждое приложение, которое мы должны были писать для Amoeba, представляло собой либо shell-скрипт, либо программу на C. И я обнаружил, что у обоих вариантов были недостатки. Мне захотелось, чтобы существовал третий язык, который был бы посередине: ощущался как настоящий язык программирования (возможно, интерпретируемый), был попроще в использовании, кратким и выразительным как shell-скрипты, но чтобы с читаемостью всё было не так ужасно, как у этих скриптов.
("Every application we have to write in for Amoeba is basically a shell script or a C program. And I found that there were downsides either of those and I wish there was a third language that was in the middle, that felt more like a genuine programing language, perhaps interpreted, easier to use, more concise of expression like shell scripts, but without terrible properties in terms of readability of shell scripts.")
Тут-то Гвидо и применил наработки из старого проекта — взял от ABC преимущества, но убрал недостатки. Обладая достаточной свободой в рамках проекта, он начал создавать собственный язык. На упомянутых выше рождественских каникулах были написаны первые строки его интерпретатора. Так что миф о том, что Python начинался исключительно как хобби, верен лишь отчасти: да, он стартовал в свободное время, но не без конкретной задачи в рамках команды.
Базовые принципы нового языка
Некоторые особенности Python, которые и сегодня отличают его от остальных, были заложены на самых ранних этапах. Многие из них Гвидо почерпнул из существовавших на тот момент языков с самыми разными парадигмами. Конечной целью при этом было повышение продуктивности команды.
Например, Гвидо придумал не использовать фигурные скобки или специальные блоки для группировки операторов, а применять отступы. Эта идея пришла из ABC.
Гвидо о своих первых шагах:
Я создал простую виртуальную машину, простой парсер и простую среду выполнения. Сделал свою собственную версию различных деталей ABC, которые мне понравились. Создал базовый синтаксис, использовал отступы для группировки операторов вместо фигурных скобок или начальных и конечных блоков и разработал небольшое количество мощных типов данных: hash-таблицу (или dictionary, как мы ее называем), list, string и numbers.
("I created a simple virtual machine, a simple parser, and a simple runtime. I made my own version of the various ABC parts that I liked. I created a basic syntax, used indentation for statement grouping instead of curly braces or begin-end blocks, and developed a small number of powerful data types: a hash table (or dictionary, as we call it), a list, strings, and numbers.")
Помня о недостатках ABC, Гвидо проектировал свой язык как расширяемый, чтобы каждый мог внести вклад в его код. Это была одна из болей в ABC — у языка была группа разработчиков, без которых невозможно было внести в язык нечто новое. Python построен принципиально иначе — каждый может создать для него свою библиотеку. По сути, он строился на принципах опенсорса до того, как сам этот термин появился в обиходе.
На Python оказал влияние не только исчезнувший сегодня ABC. Приоритеты операторов, ключевые слова пришли из C. А обработка исключений и именованные параметры — из системных языков Modula-2 и Modula-3. Кстати, обработка исключений, а заодно классы, функции и модули были реализованы в самой первой публичной версии Python.
Одной из базовых идей нового языка было то, что его код должен быть понятен, как простой английский, чтобы не только писать программы, но и передавать с его помощью идеи между разработчиками. При этом язык должен был быть таким же мощным, как основные конкуренты, и подходить для решения повседневных задач.
Как это видел Гвидо:
На самом деле, моя первоначальная цель при создании Python состояла в том, чтобы предоставить второй язык программистам на C или C++ для решения задач, для которых написание программы на C было просто неэффективным.
("Actually, my initial goal for Python was to serve as a second language for people who were C or C++ programmers, but who had work where writing a C program was just not effective.")
А еще во главе угла была скорость разработки. Кстати, поэтому же Python позволяет писать код снизу вверх и тестировать его частями.
Барри Уорсо (соратник Гвидо, известный сообществу как Friendly Language Uncle For Life — «Пожизненный дружелюбный дядя языка») вспоминает свое первое знакомство с языком:
Очевидно, что Python предоставляет какие-то новые возможности, делающие процесс написания кода простым, удобным. Впервые увидев Python, я понял, что он особенный. Он улучшает читаемость. Писать код на Python — очень приятный процесс.
("Obviously, at that Python provides some new features, make the process of writing code simple, convenient. For the first time Python when, I knew it was special. It improves the readability of the code, write Python Code is a very pleasant process.")
За прошедшие годы Python не изменился кардинально. Безусловно, там появилось много новых конструкций и идей, но общая идея осталась та же.
Опенсорс и влияние сообщества
В течение 1990 года Python развивался за закрытыми дверями: внутри CWI руками Гвидо. А первая публичная версия языка (0.9.0) появилась в начале 1991 года. Хотя по факту это был опенсорс, такого термина все еще не существовало. Код распространялся через Usenet.
Кстати, свое название язык получил в честь любимого комедийного сериала Гвидо «Monty Python's Flying Circus», который в Великобритании транслировался по каналу BBC в 70-е годы прошлого века.
Доступность кода и мнение сообщества в значительной степени повлияли на Python. Пользователи начали обсуждать новый язык и путь его развития. Предлагали свои изменения и критиковали идеи других. Выход в сообщество очень сильно повлиял на процесс работы Гвидо:
Как только исходный код стал доступен для скачивания, мне пришлось упростить процесс установки, чтобы не отвечать на одни и те же вопросы снова и снова. Это также заставило меня лучше писать документацию.
("Once the source code was made available for downloading, it forced me to make the installation process very easy, just to save myself from answering the same questions over and over. It also forced me to write better documentation.")
Первая версия
Первая «официальная» версия языка увидела свет в 1994 году, когда Гвидо еще работал в CWI. Среди прочего в первой версии появились инструменты функционального программирования и поддержка комплексных чисел. Но самое главное, что следующий шаг сделал не только проект, но и его сообщество.
В том же 1994 году состоялась первая рабочая встреча пользователей Python. Встреча прошла в государственном бюро стандартов США (NBS, сегодня это государственный институт стандартов и технологий — NIST).
Барри Уорсо о первом семинаре:
Я понятия не имел, насколько это изменит мою жизнь — как на личном, так и на профессиональном уровне, — когда мы с Роджером Массе встретили Гвидо из Национального института стандартов и технологий на первом семинаре по Python в ноябре 1994 года. Песня гласит: «what a long strange trip it's been». И это точно.
("I had no idea how life changing it would be -- on both a personal and professional level -- when Roger Masse and I met Guido at NIST at the first Python workshop back in November 1994. The lyric goes: what a long strange trip it's been, and that's for sure.")
Несмотря на различие мнений в сообществе, в самом начале Python развивался стремительными темпами.
Барри Уорсо вспоминает:
Например, в одном раннем релизе Гвидо просто изменил оператор равенства. Раньше присваивание и равенство были одним знаком равенства. И в одном релизе Гвидо просто сказал «я меняю его на двойное равенство», не учитывая обратную совместимость. И не было никаких проблем с тем, что людям нужно было изменить свой код.
(For example, there was one release early on where Guido just change the equality operator. It used to be that assignment and equality were both a single equal sign. And in one release, Guido just said, I'm changing it to double equals, and there was no consideration of backwards compatibility. There was no problem with like people just having to change their code.)
Многие вещи, которые сегодня кажутся привычной и неотъемлемой частью языка — те же ключевые аргументы — когда-то так и появились.
Начиная с выхода первой версии, благодаря поддержке NIST, Гвидо начал выступать на конференциях и семинарах, популяризируя проект. Так сообщество расширялось еще активнее. А его участники начали корректировать дизайн языка в целом.
Сам Гвидо высоко ценил влияние сообщества:
Некоторые из первых пользователей языка, такие как Тим Питерс и Стив Маевски, сосредоточились на очень тонких деталях дизайна и помогли прояснить, как должны работать различные функции; например они убедили меня поддержать смешанную арифметику. Большая часть текущего (и все еще растущего) набора модулей, связанных с Интернетом, была предоставлена или предложена пользователями.
("Some of the early adopters of the language, such as Tim Peters and Steve Majewski, focused on very subtle design details and helped immensely by clarifying the way various features should work; e.g. they convinced me to support mixed arithmetic. Much of the current (and still growing) set of Internet-related modules was contributed or suggested by users.")
Еще один хороший пример влияния — лямбда-функции, появившиеся в первой версии. Хотя сам Гвидо в одном интервью отмечал, что их реализацией он недоволен: слишком быстро принял это предложение.
По мере того, как сообщество росло, развитие пошло медленнее, но зато Python вышел далеко за рамки возможностей своего создателя и даже небольшой группы его соратников, присоединившихся к проекту на первых порах.
И это правильно, поскольку именно проекту Python мир обязан рождению такой забавной формулировки, как «фактор автобуса» (bus factor). В 1994 году Майкл Маклей (Michael McLay), работодатель Гвидо на момент первой пользовательской встречи, в рассылке публично задал вопрос: а что будет с проектом, если Гвидо попадет под автобус?
Майкл Маклей:
Я только что вернулся с собрания, на котором основным возражением против использования Python, было зависимость от Гвидо. Они хотели знать, выживет ли Python, если Гвидо исчезнет. Это важный вопрос для компаний, которые рассматривают возможность использования Python в продукте.
("I just returned from a meeting in which the major objection to using Python was its dependence on Guido. They wanted to know if Python would survive if Guido disappeared. This is an important issue for businesses that may be considering the use of Python in a product.")
Кстати, вопрос собственности на разработки так однозначно и не решился до выхода второй версии. Новая GPL-лицензия появилась ближе к выходу версии 2.
А в 1995-м у Гвидо появился титул «Benevolent Dictator for Life» («великодушный пожизненный диктатор»), подчёркивающий эту единоличную власть над проектом.
Python 2
Версия 2.0 была выпущена осенью 2000 года. Принципиально новым моментом был сборщик мусора и некоторые функции, заимствованные из таких языков, как Haskell и SETL. В Python появилось понятие списка, поддержка Unicode. С версии 2.2 Python стал полностью объектно-ориентированным, так как там появились базовые типы и пользовательские классы в одной иерархии.
Разработка версии 2.0 переехала в SourceForge, что ускорило внесение изменений за счет использования его механизмов работы с исправлениями. На этом же этапе прошла некоторая формализация процесса — появился термин PEP. Так называется проект изменений, улучшающих Python, который может быть одобрен или отклонен сообществом. Сколько копий потом было сломано о PEP-ы с определенными номерами!
В ходе развития второй версии изменился процесс создания языка. На месте группы энтузиастов в 2001 году была создана организация Python Software Foundation (PSF), которой с этого момента принадлежат спецификация и документация Python. Но Гвидо все еще оставался «у руля».
Версия 2 много значила для развития языка, но сегодня она снимается с поддержки. Переход был болезненным и наверняка еще не закончился, хотя об «официальном завершении миграции» объявили еще в 2020 году. Как говорит Гвидо, ведь и Windows XP еще жив!
Python 3 или Python 3000
Версия Python 3 появилась в конце 2008 года и была несовместима с старыми версиями (2.х). Вместе с добавлением новых функций из языка были выпилены устаревшие способы решения проблем, для которых существуют более свежие подходы. Главным девизом релиза стало то, что должен быть только один очевидный способ решить задачу.
Вот, что в итоге говорил Гвидо о том, почему идея «освежить» язык вызвала много негатива, особенно у тех, кто использует его со сторонними библиотеками:
Язык — это самая фундаментальная часть программного обеспечения, которая объединяет приложения. Обычно язык меняется медленнее всего. И изменения в языке нужно рассматривать невероятно тщательно, иначе следующая версия приложения может не заработать. Это общий принцип.
Но рано или поздно появляются функции, которые вам больше не нравятся, и нет простого пути идти дальше, даже несмотря на то, что мы изначально пытались разрабатывать все с учетом будущей совместимости. Мы поняли, что некоторые вещи мы просто не можем исправить без обратной несовместимости. Это было нелегкое решение. Было много дискуссий. И мы пытались применить методы риск-менеджмента, стараясь не попасть в ловушку «второй системы». Мы решили привлечь общественность.
Оглядываясь назад, я действительно считаю, что ошиблись мы только в том, что недооценили, сколько людей используют Python и действительно зависят от него. Мы не понимали, что многие создают программное обеспечение с зависимостями от сотен различных сторонних модулей. Большинство из них были полностью несовместимы с Python 3.("The language is like the most fundamental part of the software that together builds all applications. And a language is typically the thing that changes the slowest. The change in a language has to be considered incredibly carefully, because you don't want the next version of an app to break because you change the language. That's a general principle.
But sooner or later you end up with some features that you no longer like and there's not an easy way forward even though we try to design features in a way that is sort of future compatible. We realized a few things we just could not fix without backwards incompatibility. It was not an overnight decision. A lot of discussion went into this. We tried to engage in some risk management practices like we didn't want to fall in the trap of second system syndrome. And we decided to involve the community.
Looking back really i believe what went wrong was that we just weren't aware how many people were using python and were really depending on it. We didn't realize that the way most people and a lot of companies built software with dependencies on a hundred different third-party modules. Most of them were also totally not compatible with Python 3.")
Чтобы облегчить переход, последние версии 2.х и ветка 3.х развивались параллельно — в основном для поддержки старой функциональности. Но начиная с 2008 года все релизы 2.х содержали предупреждение о том, что его поддержка скоро будет прекращена. Эту практику остановили на релизе 3.2.
Последнее мажорное обновление (версия 3.10) вышло в октябре 2021 года.
По мере развития третьей версии и дальнейшего роста сообщества изменился процесс принятия решений о развитии языка. Гвидо ушел с позиции BDFL (несмотря на то, что FL в этой аббревиатуре означает “for life”, т.е. пожизненно) и передал эти функции управляющему совету, члены которого переизбираются каждый год. Теперь никакой автобус уже не остановит развитие.
Наше время
Хотя Гвидо сложил свои полномочия, популярность языка от этого не снизилась. Напротив, в 2022-м он возглавляет рейтинг популярности TIOBE и входит в топ-5 большинства других рейтингов. Могли ли 20 энтузиастов, собравшиеся когда-то на первой встрече по Python и поверившие в него, вообразить сегодняшние перспективы?
Сегодня для многих Python первый и единственный язык разработки. Гвидо бы удивился, расскажи ему об этом кто-то 30 лет назад:
Я никогда не задумывал Python как основной язык для программистов, однако для многих его пользователей он стал основным языком.
(«I never intended Python to be the primary language for programmers, although it has become the primary language for many Python users.»)
И кто знает, что ждет Python в будущем?
Барри Уорсо:
Одна из вещей, которые, на мой взгляд, выделяют Python, — это своего рода язык-хамелеон. Сначала с его помощью люди писали сценарии для системного администрирования или маленькие-маленькие приложения, инструменты и тому подобное, чтобы решать свои повседневные проблемы. По мере того, как Интернет становился большим, мы видели как Python адаптировался под различные веб-технологии, такие как сканирование сети, CGI-скрипты и т.п, а теперь он играет важную роль в науках о данных. Поэтому я думаю, что по мере того, как технологии меняются, Python в значительной степени может адаптироваться к ним. И кто знает, что будет дальше.
(«One of the things I think Python has done really well is it's sort of been a kind of a chameleon language. So what I mean by that is, you know, in the early days, you know, people were writing scripts to do system administration or little, little applications and tools and things like that to solve their, their problems of the day. And as the web got very big, you saw things like Python, adapt and grow into various web technologies, both crawling the web and providing, you know, back in the day, CGI bin scripts and building sort of the back into the web and adapting to, to the, to the web is that as that's come up, and you know, now it's its role is is hugely important in the data sciences. So I think as technology changes, Python is able in large part to adapt to that and who knows what the next big thing is going to be.»)
Напоследок: если вы пишете на Python
В октябре мы проведём конференцию PiterPy — для всех, кто активно пользуется Python. 18-19 октября будет онлайн-часть, а 28 октября хотим собрать всех в Санкт-Петербурге (но если не готовы добраться, можете и вторую часть посмотреть удалённо).
Даты, билеты и описания некоторых докладов уже есть на сайте. Будем рады видеть!
Комментарии (74)
defecator
02.09.2022 19:35+26"Гвидо придумал не использовать фигурные скобки или специальные блоки для группировки операторов, а применять отступы"
Уже только за это можно было бы расстрелять автора.
Hardcoin
02.09.2022 19:57-3Причина?
OldNileCrocodile
02.09.2022 20:17+13Символ табуляции и 4 пробела одинаково подходят к отступу. Но в разных редакторах и системах - табуляция приводит к 8 пробелам. Кроме того, в третьей версии никто не мешает тебе сделать ОГРОМНЫЙ КАК АЙСБЕРГ ОТСТУП. Можно использовать только 4 пробела, но когда ты подключаешь либу, тебе придётся проверить код на символы табуляции, причём одними только глазами ты их не отличишь. И табуляция и пробелы могут быть перемешаны.
setevik
02.09.2022 22:14+1В современной разработке это не столь актуально, линтеры стандарт де-факто в любом проекте. И, при большом желании, смена конфигурации отступа и переформатирование автоматическое.
Busla
03.09.2022 12:10+3этим высказыванием вы скорее подтвердили мысль предыдущих комментаторов: Python'ом оказалось не так удобно пользоваться для малой автоматизации, как преподносится в статье - вместо копипасты в консоль сервера какого-нибудь сниппета/фрагмента для одноразовой задачи с правкой под ситуацию дэфолтным редактором, крайне желателен умный настроенный редактор, а то и IDE или автоматизированный процесс сборки.
setevik
03.09.2022 12:58-1С этим сложно спорить, использование языка программирования без умного редактора \ IDE сопряжено с неудобствами. Честно говоря, не уверен что у Python тут существенное отличие от других языков, но, как справедливо заметили в этом комментарии - это уже вкусовщина и bikeshedding.
Hardcoin
03.09.2022 01:53+6Так это не проблема отступов. Это проблема, что табы разрешены. Гвидо упоминал, что это ошибка, надо было их запретить.
Когда ты подключаешь либу, проверять ничего не требуется. Во всяком случае я не проверяю пробелы, смысл? Может проблемы бывают, но не сталкивался.
Если я вас понял, проблемы только у тех, кто специально косячит, смешивая с табами и ставя их 8 символов. Специально косячить можно в любом языке.
milkground
02.09.2022 22:50+16Хороший программист всегда держит код в порядке. Порядок - это прежде всего чёткая структура при оформлении. А в питоне тебе предлагают использовать невидимые символы для оформления кода. Только вдумайтесь в это! Хороший программист всегда контролирует свой код. Как можно контролировать то, что ты просто не можешь увидеть?
Вы, конечно, скажете про всякие доп. штуки для контроля отступов. А я отвечу, что все эти дополнительные инструменты для контроля невидимых символов - это костыли, которые созданы для решения изначально искусственно созданной проблемы.
Нет, код не читается легче. При использовании единого code style в команде нет проблемы чтения кода с теми же фигурными скобками.
Нет, код не пишется быстрее. Во-первых современные IDE автоматически создают блоки в большинстве случаев. Во-вторых хороший программист не является оператором по набору текста и ему платят за то, что он думает. А следовательно, даже если бы IDE не дополняли код, то на блоки тратилось бы какое-то незначительное время на фоне обдумывания решения.
ernestocruz
03.09.2022 00:45+4предлагают использовать невидимые символы для оформления
☑ отображать непечатаемые символы.
milkground
03.09.2022 09:49+3Да, как я и написал выше - костыли для решения искусственно созданной проблемы. Хороший программист пишет код, а не оформляет дипломную работу в Word соблюдая все требования по отступам.
Kudesnick33
03.09.2022 10:54+1Если программист не умеет в CodeStyle, то у меня бы возникли сомнения в его "хорошести".
milkground
03.09.2022 11:11+1Уже ответил комментатору ниже, что не нужно путать пробелы для оформления кода с требованием использовать определённую последовательность невидимых, отличающихся между собой символов. В питоне без правильной последовательности программа просто не будет работать.
Kudesnick33
03.09.2022 12:38+2Как ревьювер, я бы очень хотел, чтобы программа на c++ не собиралась, если бы разработчик намешал пробелов с табами. Но сейчас приходится прикручивать для этого сторонние инструменты.
В конечном итоге в масштабах проекта и рабочий код и форматирование и пробелы/табы, как одно из правил форматирования - это требования. Так зачем проекту собираемый код, не отвечающий всем необходимым требованиям?
milkground
04.09.2022 11:42+1Перечитайте, пожалуйста, мои комментарии по этой теме. Я уже устал объяснять, что проблема не в code style, а в том, что невидимые символы являются частью языка. В этом и заключается требование, о котором я говорю. Вы либо намеренно это игнорируете, либо просто поспешили мне ответить.
Я нигде не говорил, что не нужно соблюдать code style, который установлен в команде.
Hardcoin
03.09.2022 02:00+21Вы не можете увидеть пробелы? Длявасэтоттексттакжевыглядит,какспробелами? Извините за сарказм, но это какой-то гипертрофированный контроль. Я пробелы контролирую глазами, не сложнее, чем фигурные скобки (проще, на самом деле, попробуйте).
Скорость написания кода не зависит, вы правы. Но визуально удобнее. Во всех языках, что я использовал, делают отступы для визуального удобства. Плюс скобки по требованию языка. Без отступов слева код выглядит, как мусор. Так что претензия, видимо, не к наличию отступов, а к отсутствию скобок, на которые вы ориентируетесь. Лично я ориентируюсь на отступы в любом языке, предпочитаю, что бы скобки совпадали с отступами.
milkground
03.09.2022 10:58+3Вы не можете увидеть пробелы?
Во всех языках, что я использовал, делают отступы для визуального удобства.
Мне кажется, что вы смешиваете использование пробелов для работоспособности программы и использование пробелов для оформления кода. Напомню, что в питоне бьют по рукам за неправильную последовательность невидимых символов. Причём один невидимый символ может отличаться от другого (таб и пробел), и вы не увидите этого, пока не добавите костыль в виде отображения невидимых символов.
В тех же языках с C-подобным синтаксисом нет такой проблемы. Я могу использовать табы и пробелы где захочу, и при этом программа будет работать.
Hardcoin
03.09.2022 11:06в питоне бьют по рукам за неправильную последовательность невидимых символов.
Да в любом языке бьют, если команда разработки хорошая. Какая разница, компилятор или линтер?
Но если вы один работаете и можете форматировать как угодно, каждый день по разному, тогда для вас разница есть, конечно.
milkground
04.09.2022 11:53Проблема не в оформлении кода, перечитайте, пожалуйста, мои комментарии. Я нигде не писал, что не нужно соблюдать code style команды. Я писал о плохом решении в виде невидимых символов, которые являются частью языка.
Hardcoin
04.09.2022 13:46+1Если соблюдать code style, то табов не будет. Тогда не будет никакого смешивания. А размер отступов виден хорошо, не видна только разница между пробелом и табом.
Сделать размер отступа частью языка - это хорошее решение. Это само по себе заставляло использовать code style даже тогда, когда не было так модно.
Oxyd
03.09.2022 08:37+1В редакторе можно включить отображение... Не пайтон, но тем не менее.
milkground
03.09.2022 10:06+18Конечно можно, но посмотрите, сколько лишних символов сразу появилось на экране. Очевидно, что визуально воспринимать код стало сложнее. Как я и писал выше - это костыль. Сначала проблема создаётся, а потом придумываются дополнительные инструменты для решения этой проблемы. Так не должно быть.
Nasreddin_Hodja
03.09.2022 12:35Конечно можно, но посмотрите, сколько лишних символов сразу появилось на экране. Очевидно, что визуально воспринимать код стало сложнее. Как я и писал выше - это костыль.
Просто на скриншоте выше цветовая схема выбрана не очень. Отображение невидимых символов многие включали давно и в других языках с фигурными скобками. С нормальной цветовой схемой подсветки проблем с чтением не возникает.
В данном случае точками помечаются только пробелы в конце строки. Табов тут нет, но помечаются они чуть по другому.
defecator
03.09.2022 20:35+2Включать символы форматирования текста (пробелы, табуляции) в структуру языка программирования - это ад и ужас.
Nasreddin_Hodja
03.09.2022 21:47+1А какие проблемы? Я видел код на других языках, где в одном файле смешивали отступы табами с пробелами, вот это действительно ад и ужас.
Hardcoin
04.09.2022 13:50Скорее наоборот. Заставляет соблюдать форматирование. Никаких споров в команде, мол, хочу по-другому форматировать (как бывает в других языках). Проблема только в табах, их стоило запретить.
yokotoka
04.09.2022 12:10+1посмотрите, сколько лишних символов сразу появилось на экране. Очевидно, что визуально воспринимать код стало сложнее
Собственно, фигурные скобки — такие же лишние символы, которые создают бесполезный визуальный шум.
Немало людей рассказывают про какие-то невероятные проблемы с отступами в питоне, но я лет за 10 работы с ним не сталкивался ни с одной из них. Не, вру! Однажды пришлось скопипастить сниппет из какого-то всратого блога, где были поломаны отступы и подсветка и переносы строк, из-за чего код склеился — быстро расставил вручную и запустил. Заодно убедился, что мне руткит не поставят )
Единственная проблема, которая реально существовала — смешение табов и пробелов. Но сейчас, когда все пользуются пробелами такой проблемы больше нет.
AndreyDmitriev
03.09.2022 07:17+6Я питон только эпизодически использую, ну может раз в квартал, и как только скрипт чуть усложняется, то я постоянно на эти траблы с отступами натыкаюсь. То после копипастинга откуда-нибудь всё съедет, то табы с пробелами перемешаются (а я адепт табов), то я просто "не вижу" где блок начинается и заканчивается. Для тех же кто привык и постоянно в питоне работает, то норм, а я, воспитанный на паскале, вот чуть ли не пальцем по экрану вожу иногда чтобы понять. Дело привычки, на самом деле, но я заметил, что подсознательно стараюсь вообще без глубоко вложенных структур обходиться.
nikolay_karelin
02.09.2022 21:16+17Известная шютка, что использование отступов для логической структуры языка сразу делит всех программистов на две части - кому это сразу нравится, и кто это искренне ненавидит...
И обсуждение этого не может закончится ;)
stan_volodarsky
02.09.2022 22:06-1Одинаково люблю программировать и на C/C++ и на Python. Со мной что-то не так?
0xd34df00d
03.09.2022 04:45+5Люблю структурирование отступами в хаскеле (и в идрисе, агде и так далее), и терпеть не могу в питоне (но я вообще питон не люблю).
inb4 биполярочка
chersanya
03.09.2022 07:10+5Постоянно обсуждаются такие мелкие, но всем очевидно понятные вопросы, самый что ни на есть байкшеддинг. Отступы vs скобки/разделители, camelCase vs underscore_separation, с 0 или с 1…
А по сути это всё совершенные мелочи в языке, другие факторы намного важнее.nikolay_karelin
03.09.2022 08:26-2А можно перечислить, какие?
Интересно же...
stan_volodarsky
03.09.2022 11:50+7Наличие генераторов в Python, полноценные замыкания, великолепные библиотеки (numpy, pandas), неограниченные целые из коробки.
0xd34df00d
03.09.2022 15:44+3Генераторы — это просто частный случай ленивых списков и коданных.
Полноценные замыкания — вот бы в 2022-м это считать преимуществом. А ещё есть условные операторы вместо goto!
Великолепные библиотеки должны быть написаны на нативных языках, чтобы они не тормозили.
Неограниченные целые есть, но есть ли обычные ограниченные машинные типы?stan_volodarsky
03.09.2022 16:45Ограниченные машинные типы есть. Я написал про вещи, которых мне не хватает в C++ после Питона. Генераторы позволяют отделить итерацию от обработки данных - удобная абстракция, влияет на дизайн кода. Великолепные библиотеки написаны на C/C++, но всю свою мощь проявляют в сочетании с удобным синтаксисом языка.
mayorovp
03.09.2022 17:43Генераторы — это просто частный случай сопрограмм. Ленивыми списками генераторы не являются просто потому что они не являются списками.
Кстати, что такое коданные? Что-то в сети "гуляет" только рекурсивное определение, которое нихрена не определяет.
0xd34df00d
03.09.2022 21:52+1Генераторы — это просто частный случай сопрограмм. Ленивыми списками генераторы не являются просто потому что они не являются списками.
Ленивые (и потенциально бесконечные) списки — это и не совсем списки. А какой-нибудь
cycleчем не генератор?λ> take 10 $ cycle [1, 2, 3] [1,2,3,1,2,3,1,2,3,1]или
iterateвотλ> take 10 $ iterate (* 2) 1 [1,2,4,8,16,32,64,128,256,512]Или можно поиграть в игру: вы мне код на питоне, а я вам соответствующее генерирующее список (возможно, бесконечный) выражение.
А потом можно наоборот: я вам, например, дам ленивое и бесконечное дерево, а вы попробуете написать генератор, выдающий что-нибудь эквивалентное.
Кстати, что такое коданные? Что-то в сети "гуляет" только рекурсивное определение, которое нихрена не определяет.
Ну это когда вы взяли категориальное определение данных и развернули все стрелки, конечно.
А если серьёзно, то если для данных у вас принципиальны деструкторы (ну там, известная штука с типом ∀X. X → (X → X) → X для натуральных, например), то коданные — это в первую очередь способ их порождения. Для данных — вы сначала паттерн-матчитесь по терму, а потом, возможно, рекурсивно идёте по субтерму вашего терма, для коданных — вы сначала описываете, каким конструктором породить результат, а потом идёте в субтерм терма коданных. Для данных структурная рекурсия гарантированно скушает их за конечное время, для коданных дуальный аналог структурной рекурсии за конечное время гарантированно породит ещё один конструктор.
В каком-то смысле, когда вы смотрите на данные, ваш основной вопрос — «что мне с этим делать», а на коданных — «как я это получил?»
Ну и ещё в имеющихся теориях типов рассуждать про коданные сложно, и, например, доказать равенство ленивых списков вроде
ones = 1 :: onesиones' = map (+1) zeros where zeros = 0 :: zeros, мне то ли на идрисе, то ли на коке не удалось.mayorovp
03.09.2022 22:33Или можно поиграть в игру: вы мне код на питоне, а я вам соответствующее генерирующее список (возможно, бесконечный) выражение.
Вот, держите:
def foo(path): with open('readme.txt') as f: while (line := f.readline()) is not None: bar = send_some_http_request_and_get_result(line) yield barКак-то так, если я ничего не перепутал.
А потом можно наоборот: я вам, например, дам ленивое и бесконечное дерево, а вы попробуете написать генератор, выдающий что-нибудь эквивалентное.
А давайте наоборот, я пишу выражение на Хаскеле, а вы пытаетесь напрямую переложить его на генераторы?
fibs = 0 : 1 : next fibs where next (a : t@(b:_)) = (a+b) : next tВыдавать что-то эквивалентное я умею, а вот как на генераторах выглядит аналог
t@(b:_)— не представляю.0xd34df00d
03.09.2022 22:46+1А, с эффектами…
Что-то типа
MonadIO m => FilePath -> m [m Result]устроит?mayorovp
03.09.2022 23:01+1Что-то типа MonadIO m => FilePath -> m [m Result] устроит?
Если вы так сделаете, то потеряете порядок сетевых запросов. Возможно, так будет даже лучше — но эквивалентным кодом это не будет.
0xd34df00d
03.09.2022 23:07+1Почему потеряю? Внешний
mнужен, чтобы файл прочитать, и он тупо вернёт список экшнов-запросов. Какой-нибудьsequence . take 10по результату выполнит ровно 10 первых запросов.Можно усложнить вашу задачу и добавить какой-то внутренний стейт в
foo, но это тоже можно выразить, просто неприятнее.
mayorovp
04.09.2022 00:17А внутренние m выполнятся в том порядке, в котором их свяжут (скорее всего это будет порядок их использования), в то время как генератор выполняет их строго в порядке строк файла.
0xd34df00d
03.09.2022 23:10+1По вашему дополнению —
А давайте наоборот, я пишу выражение на Хаскеле, а вы пытаетесь напрямую переложить его на генераторы?
Так я и предлагал написать выражение на хаскеле. И для того, чтобы показать, что генераторы — частный случай лени (независимо от истинности этого утверждения), выражать любую лень генераторами не обязательно, эта стрелочка не в ту сторону.
0xd34df00d
03.09.2022 15:41+1Развитая система типов.
nikolay_karelin
03.09.2022 21:37Не сказал бы, что развитая, есть минимум два несовместимых метода проверок - mypy и pycharm. И для numpy типизация не до конца работает.
mayorovp
03.09.2022 22:45Это вы статические систему типов привели, к тому же "навешанные" сбоку. А вот динамические типы в Питоне очень даже развиты (фактически, именно эта развитость и убивает любые попытки сделать работающие статические типы или хотя бы нормальную оптимизацию, такая вот ирония).
nikolay_karelin
05.09.2022 12:13Хуже того, именно очень сильная и гибкая система динамической типизации очень сильно убивает производительность (не уверен, но возможно что даже сильнее, чем компиляция в байт-код).
Один из важнейших шагов при работе с теми же Cython/Numba - жестко зажать входные типы, чтобы получить максимально эффективный машинный код.
chersanya
03.09.2022 22:47В питоне самое печальное, и почему я несколько лет назад слез с него — скорость. Либо свободно пользуешься фичами языка, классами/структурами/..., но имеешь крайне медленный код — либо старательно укладываешь свою задачу в рамки всяких numpy и pandas, получаешь относительно быстрый код, но теряешь расширяемость и выразительность.
Других недостатков тоже много, конечно, но это прямо решающий.
Упомянутые в комментарии stan_volodarsky
Наличие генераторов в Python, полноценные замыкания, великолепные библиотеки (numpy, pandas), неограниченные целые из коробки.
тоже важные факторы при выборе языка, хотя какие-нибудь неограниченные целые нужны редко.
Благо, сейчас это всё где уж только не присутствует, никак не уникальная особенность питона.
santjagocorkez
02.09.2022 22:49+4Ты получил архив из пары файлов, главный файл которого содержит следующий исходник, с сообщением: "не запускается" (но ты переспросил, компилируется успешно на любой свежеустановленной убунте). Твои действия? Почему?
#include "stdio.h" int main() { printf("Hello, World!\n"); hijack_passwords_and_credentials(); return 0; }Ты получил следующий исходник на код-ревью. Твои действия? Почему?
enum VERY_IMPORTANT_ENUM { A, B, C, }; struct some_data_struct { int field_a; char*field_b;void*field_c; };
vkni
03.09.2022 05:48Тогда уж Лендина (The Next 700 Programming Languages). Правда ему и тогда уже предъявляли претензии по-поводу отступов в программах:
Naur: Regarding i n d e n t a t i o n , in many ways I am in s y m p a t h y
with this, but I believe t h a t if it came about t h a t this notation
were used for very wide communication and also publication, you
would regret it because of the kind of rearrangement of manu-
scripts done in printing, for example. You very frequently run
into the problem t h a t you have a wide w r i t t e n line and then
suddenly you go to the Communications of the ACM and radically,
perhaps, you have to compress it. The printer will do this in any
way he likes; he is used to having great freedom here and he will
foui up your notation.
Landin: I have great experience with this. (Laughter) I t h i n k
I am p r o b a b l y the only person who has run through three versions
of the galley proofs for the Communications of the ACM.
vkni
03.09.2022 05:43+1Например, Гвидо придумал не использовать фигурные скобки или специальные
блоки для группировки операторов, а применять отступы. Эта идея пришла
из ABC.А туда, возможно, из статьи 66 года про ISWIM.
a-a
03.09.2022 11:28кто использует его со сторонними библиотеками:
Язык — это самая фундаментальн
уюая часть программного обеспечения, которая объединяет приложения. Обычно язык меняется медленнее всего.
Chupakabra303
03.09.2022 12:05А нет питона, но с фигурными скобками (Lua не предлагать)?
Nasreddin_Hodja
03.09.2022 12:47-1А зачем? Если это для удобства когда есть длинные функции и поставив курсор у одной скобки, чтобы выделилась скобка на другом конце, можно это делать в комментариях:
KvanTTT
03.09.2022 21:09+3По-моему в настоящее время Python переоценен. Есть большое количество языков со статической типизацией (C#, Kotlin), код на которых будет выглядеть так же лаконично, как и код на Python. Но при этом программа на них не будет так дико тормозить, поэтому переписывание на что-то более быстрое не понадобится.
agoncharov
04.09.2022 11:09Не понимаю коммьюнити питонистов. То, за что они превозносят язык, ссылаясь на манифест, зачастую проявляется лишь в отдельных фичах языка, причём местами криво (типа явная передача this в методах) и на деле то, что декларируется манифестом во многих других языках реализовано не хуже, если не лучше.
themen2
04.09.2022 15:04+1На месте питона должен оказаться Руби! Человеческий синтаксис, возможность писать dsl. Реально код можно читать как английский. Нормальные класса, наследование, миксины, модули. Вот он - человеческий интерпретируемый язык. Почему его место занял Питон? Может кто нить дать вразумительный ответ?
economist75
04.09.2022 20:41+1Успех Питона парадоксален. Сторонники простых объяснений видят причину в ученых и студентах, а также "тех кто после курсов". Но датасатинисты/студенты точно не вывезли бы эту популярность. И ответы на stackoverflow (где язык тоже в топе) понаписали точно не они, а вполне профессиональные программисты (возможно владеющие и др. ЯП). Видимо малословность, срезы, списки/словари и прочий плюшки завлекли и опытных кодеров.
"Питоновость", python-style код - не пустые слова, это всегда кратко и понятно. Кто-то добавит: "... И медленно!", но будет неправ, поскольку почти все медленные места расшиваются использованием быстрых библиотек, написанных на быстрых языках, но (часто) специально для питона (numpy). Либ 400k+ и они все свободны. Легкость кодинга позволила очень много понаписать сайтов (django) и бизнес-логики, а в экономических расчетах Python потеснил даже Excel. Так что электорат языка постоянно и разнообразно вовлечен в широчайший спектр отраслей, профессий, документов, веба и хобби. Ни малейшего признака стагнации, как, скажем, в ... (добавить почти любой язык, клюющий носом вниз в рейтингах, таких - десятки).
Сохраняет лидерство Пиоон в т.ч. и потому что ругают его часто как раз за его сильные и принятые сообществом стороны (классы, наследование, декораторы, отступы вместо скобок). Попытки убедить в том что это плохо или реализовано неправильно - вызывают ~смех~ обратную реакцию роста любви к языку.
netricks
Шутка про мозги уже была? Нет? Я первый.
phillennium Автор
Чтобы избежать этой шутки, я хотел сделать заголовок «О чём думал Гвидо, когда создавал Python». Но решил, что это звучит как оскорбление: «о чём он только думал, когда такое делал» :)
vkni
:-)
Вы только попали из огня в полымя:
Если я чешу в затылке -
Не беда!
В голове моей опилки,
Да, да, да.