статьиGNU Free Documentation License материалы взяты из Википедии Статья была изменена. Оригинал статьи.

Обсуждение:Python

Материал из Энциклопедии в свободной энциклопедии
Перейти к: навигация, поиск
Это страница обсуждений и предложений для статьи Python
Правила обсуждений
Cscr-featured.svg

Эта статья входит в число избранных статей русской Энциклопедии. См. страницу обсуждения. Избрана 9 ноября 2005 года.
Mergedisputed.svg
 Эта статья была предложена к объединению со статьёй Список программного обеспечения, написанного на языке программирования Python.
В результате обсуждения было решено статьи не объединять.
Аргументы и итог обсуждения доступен на странице Энциклопедия:К объединению/26 июня 2011. Повторное выставление статьи к объединению при отсутствии веских оснований для пересмотра предыдущего решения может рассматриваться как нарушение правила «Энциклопедия: Не доводите до абсурда» (см. пункт в„–8 в разделе «Не играйте с правилами»).
Страница сохранена 2012-05-29
Пожалуйста, добавляйте новые темы снизу.

Содержание


[править] Рефакторинг статьи

Немного подправил текст во многих местах. Считаю, что не нужно так хвалиться (хотя и понимаю, что очень хочется). Энциклопедия должна подавать информацию нейтрально - факты. Надеюсь, что после исправления стало лучше. 62.248.239.110 16:04, 27 января 2007 (UTC) Роман Сузи.

Полагаю, что информацию о самом Питоне (и станд. библиотеке) нужно сильно переделать. В настоящий момент информация, содержащаяся в статье, очень несбалансирована. Такое ощущение, что где-то должна быть другая статья, которая описывает обычные возможности Питон. Но ведь это не так. В результате у тех, кто первый раз читает статью может сложится превратное ощущение, что самое главное в Питон - генераторы, функциональное программирование и тому подобные "нетривиальные" штучки. Убежден, что это неправильно. Должна быть краткая и точная информация о языке, с указанием всего, даже очевидного. И для такого изложения не нужно существенно больше места. Например, синтаксис можно проиллюстрировать одним большим примером. Типы данных помимо перечисления могут содержать срез некоторых важных моментов (например, изменчивость-неизменчивость). Слова о пространстве имен и области видимости не помешает. Пара предложений об операциях над типами, листинг с примерами литералов - и читатель получит представление об этой теме. Если нет возражений, я постараюсь найти время для этих изменений. РоманСузи 11:27, 28 января 2007 (UTC)

Предлагаю вынести в отдельный раздел информацию по альтернативным реализациям питона. Сейчас она разбросана по нескольким разделам что не позволяет их(реализации) хорошо описать. Я хотел добавить описание по stackless но так и не нашел где это сделать. Так-же сильно неполное описание, ИМНО, по такому весьма важному проекту как PyPy. Возможно имеет смысл вынести PyPy и stackless в отдельные статьи.koder 13:48, 30 января 2007

Также я думаю что необходимо перестроить подборку ссылок на внешние ресурсы. Сейчас там все свалено - так например в разделе "Расширения и библиотеки" приведена ссылка на форумы по питону. Для начала я вынес ссылки на альтернативные реализации в отдельную группу. Наверное нужно указать ссылки на какие ресурсы имеет смысл добавлять внизу статьи - т.к. просто билиотек и расширений в питоне очень много. Например преименовать раздел в "Наиболее важные/полезные/большие/???? расширения и библиотеки" koder 15:19, 30 января 2007

Возможно стоит позаимствовать некоторые идеи из стать по Руби? Например добавить краткое описание средств разработки и раздел с отрицательными сторонами. Если никто не против то я добавлю. K.Danilov aka koder 17:19, 2 февраля 2007 (UTC)

Может быть, стоит выделить описание средств разработки в отдельную статью? Что касается отрицательных сторон, то я полагаю, что не нужно выделять их в отдельный раздел как это было (положительное размазано по всей статье, отрицательное собрано). Думаю, в разделе сравнения с другими языками самое место критике Питона и для других оценочных высказываний. А конкретные отрицательные стороны можно по ходу повествования давать. РоманСузи 18:47, 2 февраля 2007 (UTC)

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

Наверно, а то действительно может сильно раздуться. А по поводу отрицательных сторон - например IMHO нужно написать что модель питона не позволяет перегрузку фукций / методов, управляемую компилятором, а все нужно делать руками, но для этого существуют уже готовые решения (замедляющие выполнение кода). Но где это написать я не вижу. K.Danilov aka koder 10:57, 3 февраля 2007 (UTC)

Есть мысль добавить (возможно отдельной статьей) програму строк так на 80 - 100, которая покажет всю мощь питона по сравнению с С++/Java(например минимальный RPC сервер/клиент прим в 100 строк влезет) а там будет и pickle и интроспекция и многопот и замыкания др. K.Danilov aka koder 12:09, 3 февраля 2007 (UTC)

Также отдельной статьей нужно, по-моему, более подробное описание модулей стандартной библиотеки. Разумеется, не для замены документации, а для освещения наиболее характерных вещей. Например, difflib, elementtree, email, sqlite и т.п. хорошие кандидатура, как и множество других полезных модулей, о которых можно хотя бы параграфом рассказать. Насчет "модель питона не позволяет перегрузку фукций / методов, управляемую компилятором" нужно доступнее написать. РоманСузи 09:13, 4 февраля 2007 (UTC) Спасибо, прочитал. Честно говоря, никогда с такой проблемой не сталкивался. Вилимо, она очень специфична именно для межъязыкового общения. РоманСузи 20:45, 6 февраля 2007 (UTC)

Сделал статью для примеров.Python примеры программ. Ее нужно дооформить(как минимум). Усе приглашаются к написанию. K.Danilov aka koder 11:02, 5 февраля 2007 (UTC)

Базовая статья уже больше 75к при рекомендуемом размере не более 50к. Может вынести описание сторонних библиотек в отдельную статью? K.Danilov aka koder 14:18, 5 февраля 2007 (UTC)

Кажется, недостаток перегрузка (а, наверное, точнее - диспетчеризация) на основе сигнатуры сильно раздута в тексте. Может быть, ее куда-нибудь выделить и/или подсократить? Лично мое мнение, что это вообще очень мелкая проблема, которая может быть уложена в пару предложений и ссылок на понятия типа сигнатура и т.п. Тем более, эта проблема будет скоро решена: http://www.artima.com/weblogs/viewpost.jsp?thread=155514 РоманСузи 15:11, 8 февраля 2007 (UTC)

Относительно терминов. В ООП применяются разные термины - поля, свойства, атрибуты, члены и т.п. В этой статье они все используются (или у меня такое ощущение). Предлагаю как-то унифицироваться или хотя бы где-то написать, что это одно и тоже. Сам я употребляю методы (те, что можно вызывать) и атрибуты (все атрибуты, в тч методы). Свойства только в случае явного оформления. А ведь еще есть слоты... Поля вообще не употребляю - так как в документации по Питону такого нет. Члены тоже странно звучат. РоманСузи 15:11, 8 февраля 2007 (UTC)

По поводу полей/методов/etc - ок, давайте все переименуем. По поводу перегрузки - если человек серьезно писал на С++ то перейдя на Python это первое и основное что СИЛЬНО достает. А насчет ее решения - даже PEP'а еще нет. А блог - он блог и есть (к тому-же годичная давность). Но вот по пов. размера я согласен. Давайте перенесем из основной статьи большую часть про выражения, перегрузку,etc. а оставим только аннотацию - примерно как с ООП. А для полного варианта сделаем отдельную статью, например Расширенный обзор возможностей ЯП Python K.Danilov aka koder 15:59, 8 февраля 2007 (UTC)

Я создал примерный вариант сокращенной статьи Python/Temp , в ней еще нужно(IMHO) почистить блоки Выражения и Профилирование и оптимизация кода. Расширенной статьи нет, поэтому если будем перехдить на сокращенный вариант, то нужно сначала создать ее и соответвтующие ссылки. K.Danilov aka koder 18:04, 8 февраля 2007 (UTC)

Я успел немного подправить основную статью ;-) сорри. По поводу статьи я полагаю, что в целом скелет должен остаться, где будут изложены самые основные положения (например, как про ООП). Наверное, логично вынести в отдельную статью обзор стандартной библиотеки. Почти все примеры, кроме самых коротких (меньше 3-4 строк), тоже в Примеры. Но при выносе можно делать ссылки. Функциональное программирование тоже можно вынести по аналогии с ООП. И описание языка (операторы, выражения, и тп.). Вообще я думаю, что статья про Питон полезна для Энциклопедии именно в силу того, что она привносит много своей терминологии, разбавляя бульон (или винегрет ;-) под названием С++,Джава,Дельфи. Поэтому я считаю, что терминология из документации по Питону имеет очень важное значение так как несет культуру рассуждения о языках программирования. Поэтому если перегрузка сильно достает, давайте напишем отдельный раздел для "иммигрантов" из Java, C++, Delphi... Я уже 8 лет на Питоне программирую и никогда не чувствовал проблемы по поводу перегрузки функций! (Мне даже сам этот сишный термин не нравится, так как он говорит не о том, что должно быть, а о том, что нужно сделать, чтобы было! Как будто это какой=то клудж (исторически он такой и есть)!) Еще я предлагаю использовать (там где уместно) статьи про конкретные понятия. Я видел примеры на Delphi,Java,C++, но Питона я еще не видел - но уже кое-где добавил ;-) Про методы и поля - переименуем в какую сторону? Нужно к единому мнению прийти. РоманСузи 17:54, 9 февраля 2007 (UTC)

Посмотрел Python/Temp. Полагаю, что нужно сокращать объем не совсем так, сминая, скажем, "другие" возможности в одну секцию. Думаю, что лучше программу забросить в Примеры и об этом где-нибудь сказать - что примеры там-то. РоманСузи 18:08, 9 февраля 2007 (UTC)

Ну пусть будут методы/атрибуты мне все равно )). Часть про перегрузку я укоротил до минимума. Если Появится раздел "для эмигрантов" то ее конечно можно перместить туда, только я боюсь придется в этот раздел большую часть статьи перенести )), Python, однако, сильно не "С". > Еще я предлагаю использовать (там где уместно) статьи про конкретные понятия это про генераторы отдельно, про замыкания отдельно? Правильно я понял? Тогда я думаю все-же лучше их в одну согнать. Сложно будет про итераторы целую статью написать IMHO. По поводу стандартной библиотеки +1 и статью про мудули тоже. Хотя внешние модули в основной статье мне нравятся в текущем состоянии. Просто в отдельной статье можно больше написать. По пов. Python/Temp - ну так поправьте на свой вкус )) K.Danilov aka koder 18:40, 9 февраля 2007 (UTC)

> это про генераторы отдельно, про замыкания отдельно? Правильно я понял? Тогда я думаю все-же Нет. Я имею в виду, что статья про Питон должна их упоминать и где возможно - иллюстрировать. Про итераторы не сложно статью написать. Вместо Python-Temp - поправил в основной - кажется, до 75 Кб уменьшилась. Наверное, можно немного успокоиться. Убрал все большие примеры в... Примеры. В общем, если не считать несколько раздутых Оптимизации и Недостатков, вроде статья общими стараниями приобрела подобающий вид. РоманСузи 18:53, 9 февраля 2007 (UTC) Ок тогда Python/Temp удаляем.

> Раздел про Недостатки не нравится... Какие-то оправдания сплошные...

Так и должно быть, по идее - вот есть недостатки , мы их признаем, но пытаемся исправить.

> все недостатки сводятся к быстродействию

И отсутствию статической типизации. А больше объективных я не вижу. Ок будем считать что рефакторинг окончен, кроме части про библиотеку и расширения K.Danilov aka koder 19:12, 9 февраля 2007 (UTC)

Стандартную библиотеку выделил в отдельную статью (она того заслуживает). А вот расширения - точно не знаю, как это назвать правильно в Энциклопедии (Программное обеспечение для Python? Модули для Python? Обзор библиотек модулей Python?). Этих расширений тьма-тьмущая. Нужно с самого начала какое-то подразделение сделать. Думаю, тут тоже нужна отдельная статья и из стандартной библиотеки туда будет много ссылок типа: например, sqlite имеет привязки в стандартной библиотеке, а вот о привязкам к другим БД см. там-то. Выдумывать классификацию для софта не нужно - можно взять из PyPi http://cheeseshop.python.org/pypi?%3Aaction=list_classifiers РоманСузи 19:40, 9 февраля 2007 (UTC)

Собственно, было бы неплохо сказать пару предложений про модули и пакеты в Питоне вообще... И про zip... И про дистрибуцию модулей как-то умолчали - distutils, eggи ... Правда, нужно самое главное сказать... А это главное не просто выделить. РоманСузи 21:00, 9 февраля 2007 (UTC)

Заменил сценарный на скриптовый - если уж даже категория называется скриптовые языки, а судя по гуглу "сценарный язык" встречается намного реже. РоманСузи 19:04, 31 августа 2007 (UTC)

[править] Единая терминология

Предлагается использовать ту, что идет из доков по Питон.

  • методы (а не члены-функции и т.п.)
  • атрибуты (а не члены или поля)
  • свойства (а не поля)

Изменяемый (неизменяемый) или изменчивый (неизменяемый)? Судя по lingvo.yandex.ru (mutable) изменчивый - mutable, изменяемый - variable. Тоже самое по данным http://www.multitran.ru

[править] Си и Питон

Максим Разин откатил мою правку о том, что сравнивать эффективность программ на Си и Питоне можно только для некоторых, подходящих назначению последнего, случаях. Мне это видится совершенно неоспоримым, но раз уж он откатил, выношу эту тему на суд участников. Согласен, что весьма хорошо было бы описать те случаи, когда Питон действительно сравним по скорости с Си, но так или иначе оставлять обобщение этого в статье нельзя. Ramir в реплика добавлена в 00:36, 10 ноября 2005 (UTC)

Ой, я прогнался. Там всё указано. Ramir в реплика добавлена в 01:56, 10 ноября 2005 (UTC)

[править] Примеры приложений

Полагаю, надо исключить примеры приложений, где питон использован лишь в качестве вспомогательного средства - для плагинов и т.п. (как например в Blender). А включать только примеры приложений, в реализации которых язык использован в качестве основного или единственного. -- Участник:Сибирский Лайка 16/11/05

  • Почему бы не перечислить и те, и другие - особенно если это популярные программы..? по-моему, полезная информация. Может быть, сделать два раздельных списка примеров. - Bepa talk 21:27, 16 ноября 2005 (UTC)
    А тоже вариант. Сейчас разделю списки. -- Участник:Сибирский Лайка 17/11/05
    Разделил. Да, так определённо лучше. Ссылки тоже разделил на информационные и ссылки на библиотеки. -- Участник:Сибирский Лайка 18/11/05

Добавил в приложения, написанные на Python игру Blade of darkness. В какой раздел её следует включить не знаю, поэтому сунул пока в "Другие области применения". Тех кто в курсе дел прошу исправить. Stebanoid 06:03, 8 сентября 2007 (UTC)

[править] Питон & пайтон

217.23.124.154 заменил русское название языка в начале статьи "(питон, пайтон)" на "(пайтон, питон)". Как я понимаю, на первом месте должно быть более более распространённое русское название, а это по-моему питон. В своё время общался с десятками питоновских программеров, только от двоих слышал "пайтон", остальные используют вариант "питон". "Пайтон" - неприжившаяся калька[источник?]. Предлагаю вернуть к старой версии. -- Участник:Сибирский Лайка 18/11/05

Согласен, исправляю Maxim Razin 01:30, 18 ноября 2005 (UTC)

Надо или восстановить "(пайтон, питон)", или убрать вариант "питон" вообще. Правильно -- только "пайтон" (по правилам произнесения собственных имен людей в языке оригинала), а "питон" -- жаргонный просторечный вариант. Потому что язык программирования назван не в честь пресмыкающегося питона, а в честь шоумена по имени Монти Пайтон. Энциклопедия -- это энциклопедия, преследует образовательную цель, и факты должны излагаться с позиции правильности, а не из распространенности мнений. в Эта реплика добавлена с IP 195.64.201.37 (о) 10:15, 1 февраля 2007 (UTC)

Полностью поддерживаю --Vanuan 14:11, 9 марта 2009 (UTC)
Название языка программирования в не имя человека. Нужно называть так, как лучше звучит в русском языке, а не в английском.  в Эта реплика добавлена участником DeLZeX (о · в) 06:18, 14 апреля 2011 (UTC)

[править] Snake Picture

under "Стандартная библиотека" the snake picture is noted in english, please translate it to Russian. в Эта реплика добавлена с IP 89.1.185.159 (о) 16:44, 29 июня 2006 (UTC)

Done --qvvx 21:43, 29 июня 2006 (UTC)

[править] Что такое?!!!

Что такое? Я взял ваш код - и вот что получил: Traceback (most recent call last):

 File "<stdin>", line 5, in ?
 File "/usr/lib/python2.3/urllib2.py", line 129, in urlopen
   return _opener.open(url, data)
 File "/usr/lib/python2.3/urllib2.py", line 326, in open
   '_open', req)
 File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain
   result = func(*args)
 File "/usr/lib/python2.3/urllib2.py", line 901, in http_open
   return self.do_open(httplib.HTTP, req)
 File "/usr/lib/python2.3/urllib2.py", line 895, in do_open
   return self.parent.error('http', req, fp, code, msg, hdrs)
 File "/usr/lib/python2.3/urllib2.py", line 352, in error
   return self._call_chain(*args)
 File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain
   result = func(*args)
 File "/usr/lib/python2.3/urllib2.py", line 412, in http_error_default
   raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)

urllib2.HTTPError: HTTP Error 403: Forbidden

Это что, сюрприз, да? в Эта реплика добавлена с IP 195.19.204.69 (о) 16:56, 24 июля 2006 (UTC)

Нет. По всей видимости, запрещено так просто брать страницу с Энциклопедии. Я исправил URL на python.org -- заработало 62.248.239.110 18:56, 27 января 2007 (UTC)

[править] Лишний else

Господа, исправьте, ради Бога, ваши коды! Какой может быть "else" после "return" - и в Си, и в Питоне? Си:

int factorial(int x)

   {      
       if (x == 0) 
           {return 1;}
       return x * factorial (x - 1);
   }

Питон:

def factorial(x):

   if x is 0:
       return 1
   return x * factorial (x - 1)

в Эта реплика добавлена с IP 217.148.216.218 (о) 11:13, 18 января 2007 (UTC)

А в чем проблема-то? else может быть, а может и не быть. Можно и от if избавиться и в Си, и в Питоне... Суть примера не в этом. 62.248.239.110 19:02, 27 января 2007 (UTC)
Более того, else может использоваться для улучшения читаемости, он просто ничего не меняет с точки зрения компилятора. в doublep 11:59, 30 января 2007 (UTC)

[править] Компактность записи кода

По-моему, пример функции, считающей факториал, на C неудачен. Короче написать так:

int factorial(int x)
 {
     return (!x) ? 1 : x * factorial(x-1);
 }


194.85.82.254 00:40, 7 февраля 2007 (UTC)Случайный прохожий

Написан самый компактный из легко читаемых. В питоне тоже можно написать

def f(x) : return ( x and f(x - 1) * x or 1 )

или ( для 2.5)

def f(x) : return ( 1 if x == 0 else f(x - 1) * x )

K.Danilov aka koder 08:42, 7 февраля 2007 (UTC)

Кстати, неудачно само сравнениев Чувствуется, что пример, мягко говоря, искусственный. «Этот втрюкв позволяет заметно сократить количество строк и символов в программе» в но здесь легко можно обойтись без нескольких скобок, разве нет?

Программа на C Эквивалентная программа на Python 
 int factorial(int x) {
     if (x == 0)                     
         return 1;
     else
         return x * factorial(x-1);
 }

 def factorial(x):
     if x == 0:
         return 1
     else:
         return x * factorial(x-1)

Понятно, что в других ситуациях Питон выигрывает сильнее, но тогда и нужно приводить именно другие ситуации. в Александр Крайнов 00:22, 2 декабря 2007 (UTC)

В более длинных примерах выигрыш питона уже не так заметен, не считая того, что строк вообще может не стать больше - скобки можно писать и в одной строке. Более того, операторные скобки позволяют более чётко контролировать логику программы на больших паллетных фрагментах при редактировании, чего питону зачастую не хватает. В целом - холиварный вопрос и не стоящий выеденного яйца, показывающий лишь однобокость позиций отдельных, фанатично настроенных товарищей. --Aleks Revo 06:26, 22 марта 2011 (UTC)

[править] Примеры кода

Для них есть отдельная статья Python примеры программ РоманСузи 19:42, 9 февраля 2007 (UTC)

Надо бы поместить примерчик кода, чтобы был понятен начинающим, но не примитивен (без Hello world всяких там). Вероятно что-то отражающее специфику языка в словари и списки и их обработка, определение какой-нибудь функции, что-нибудь с lambda и пр. Какие будут предложения? в Эта реплика добавлена участником Сибирский Лайка (о · в) 23:13, 29 августа 2004 (UTC)

Думаю нужно добавить раздел "примеры кода" и в него поместить несколько различных программок, демонстрирующих различные аспекты языка. В качестве начала могу предложить традиционный поиск факториала, а также простых чисел. Обе эти программы есть в python tutorial. Если согласны, то я добавлю. --skyrider 00:32, 31 Авг 2004 (UTC)

Да без вопросов. Давай сюда свои примеры. Ещё хорошо бы небольшой туториал добавить по Qt и wxWidget. fantom-lab@mail.ru ВАлерий Шипков. 07 нбр 2005 в Эта реплика добавлена с IP 217.168.78.28 (о) 15:04, 7 ноября 2005 (UTC)

[править] Почему слово Питон нельзя склонять?!

Например слово интернет можно склонять, а питон вдруг на этой странице оказывается несклоняемым. Прошу вас подумать над этой проблемой. в Эта реплика добавлена с IP 213.159.245.126 (о) 15:42, 10 февраля 2007 (UTC)

Питон или Пайтон это транслитерация английского слова(кстати никакого отношения к змее не имеет). Это слово не является русским, это просто "калька". Слово же интернет есть в русском словаре(хотя и заимствовано). Насколько я понимаю именно поэтому Пайтон не склоняется, в отличии от интернета. P.S. подписывайтесь, пожалуйста. K.Danilov aka koder 12:58, 11 февраля 2007 (UTC)

даже, если это фамилия вымышленного персонажа, не факт, что она обозначает не вид змей. Те, кто используют название Питон - подразумевают именно прямой перевод Python в этом смысле, а не звукоподражание непереводимой фамилии. Другой вопрос, почему нельзя склонять "пайтон"? В русском языке хватает звукоподражаний, которые успешно склоняются, так как слово имеет вполне удобную для этого форму. Со временем эти слова попадают в словари или забываются. Отказ же от склонения, потому что кто-то что-то "свыше" не одобрил ещё - исключительно религиозный вопрос. Язык живой и определяется его носителями, а не законодателями. Кстати, англоязычные имена и фамилии склоняются "на ура", вспомним, хотя-бы, Шерлока Холмса и Доктора Уотсона. Да и в статья про Летающий цирк Монти Пайтона тоже склонять не стесняются. А тут, среди программистов вдруг начались странные по своей природе споры. --Aleks Revo 19:27, 22 марта 2011 (UTC)

Эта проблема достаточно интересна. Если кто помнит, сколько было копий сломано как же правильно писать BASIC: бэйсик-бейсик, Бейсик-Бэйсик, Basic, BASIC и склонять ли его, писать ли в кавычках или без. Если уж перевели название на русский, то наверное можно начать и склонять - во всяком случае, Паскаль и Бейсик давно склоняют. Сам я то и дело делаю ошибку со склонением потому привык писать Python. По данным опроса общественного мнения http://pythonbook.it-arts.ru/node/82 - все-таки люди хотят склонять, либо писать по-английски. Так что предлагаю склонять, хотя писать по прежнему с большой паллетный буквы - все-таки Питон пока не интернет ;-) Ну или по-английски писать - там где контекст неоднозначен. РоманСузи 13:36, 11 февраля 2007 (UTC)

"Питон пока не интернет" - в чём суть разницы? По возрасту они близки, по распространению они никогда не будут близки в силу различий между ЯП и системой коммуникаций, те кто говорят "питон" по большей части ассоциируют именно со змеем, что достаточно отражено, в том числе, и в статье. --Aleks Revo 19:27, 22 марта 2011 (UTC)

[править] Сборка мусора и подсчет ссылок в Java

Я закомментировал предложение В отличие от Java, CPython использует для управления памятью и подсчет ссылок, и «сборку мусора» Т.к. оно AFAIK неверно - как раз эта комбинация в Java и используется. K.Danilov aka koder 08:26, 2 апреля 2007 (UTC)

[править] Почему "Литература" находится в разделе "Ссылки"?

ИМХО, это отдельный раздел. Alex977 09:45, 19 июня 2007 (UTC)

Согласен, выделил в отдельный раздел K.Danilov aka koder 14:07, 19 июня 2007 (UTC)

[править] Кто на кого повлиял

Сейчас в статьях ЯП в разделах "Создан под влиянием" и "Оказал влияние на" творится что-то невообразимое. Во-первых - если пройтись по статьям других языком то окажется что на питон повлияли чуть ли не половина из них. С месяц назад подправил статью по Аде сейчас нашел в статье по Haskell (все что, как некоторые думают, Python взял из Haskell(а именно list comprehension) на самом дела туда(в Haskell) пришло из других языков без изменений).
Во-вторых - на каждом языке(в смысле английском,русском,etc) они разные. Может это можно как-то организовать? Предлагаю добавить в статью раздел(небольшой), описывающий как конкретный язык повлиял на Python и на основе этого раздела формировать список влияния. Из текущего списка для меня не понятно как на питон повлияли Tcl и Perl. Так-же в списке не хватает Java - из нее были стянуты: модель исключений, пакеты,immutable строки и часть стандартной библиотеки(unittest например). Индексация массивов очень близка к Fortran.
Хорощо еще было-бы заварганить бота, для автоматической проверки/построения зависимостей из статей.
K.Danilov aka koder 09:49, 25 июня 2007 (UTC)

[править] О недостатках Питон

Раздел про Недостатки не нравится... Какие-то оправдания сплошные... В основном, все недостатки сводятся к быстродействию и отсутствию статической типизации (даже пресловутые перегрузки!). Питон не лишен недостатков, но может быть где-то в Сети есть уже готовый список? Иначе в разделе одни оправдания... РоманСузи 19:04, 9 февраля 2007 (UTC)

[править] Про недостатки

Мне кажется, что "Отступление от объектно-ориентированной чистоты" и "Невозможность модификации встроенных классов" - это одна и та же проблема, а не две. (Само выражение "Отступления от объектно-ориентированной чистоты", на мой взгляд, смешно, так как Питон и не являет собой выражение чистоты какой-либо парадигмы). Вообще, говоря о недостатках и достоинствах сложно быть объективным, так как недостатки обычно играют роль только для части применений языка. Дизайн ЯП всегда компромисс, поэтому недостатки, на мой взгляд, должны быть написаны в формате, который обрисовывает обе стороны противоречия. РоманСузи 19:08, 8 августа 2007 (UTC)

> "Отступление от объектно-ориентированной чистоты" и "Невозможность модификации встроенных классов"
> - это одна и та же проблема, а не две

IMHO нет. Возможность модификации классов во время исполнения - относится к динамическим возможностям языка а не к ООП. Например Java ООЯП до "мозга костей" но модифицировать там классы нельзя (по крайней мере приемлемыми средствами).

"Отступления от объектно-ориентированной чистоты" переименовал в "Отступления от принципов ООП". Было действительно криво. Если есть идеи получше - правьте )).

> Дизайн ЯП всегда компромисс, поэтому недостатки, на мой взгляд, должны быть написаны в формате,
> который обрисовывает обе стороны противоречия

Я старался. Но мне действительно сложно найти где len(x) лучше чем x.len(). Разве что на символ меньше. Но если у Вас есть примеры - укажите их в статье.

P.S. Я попробовал разделить понятия "язык"(как стандарт == описание) и "реализация". Но вышло, IMO, кривовато - посмотрите заголовок пож.

K.Danilov aka koder 10:05, 9 августа 2007 (UTC)

> мне действительно сложно найти где len(x) лучше чем x.len()

Конечно, о вкусах не спорят, но следуя той же логике вместо 2 + 2 нужно писать 2.add(2). Просто присутствие встроенной функции len() подчеркивает, что она играет очень важную роль во всем языке, обслуживая встроенные структуры данных. Например, мне почему-то кажется, что (если уж на то пошло) вместо len(x) нужно писать x.length(). А это еще длиннее... РоманСузи 17:33, 29 августа 2007 (UTC)

[править] Python 3000

Предлагается поместить соответствующий раздел в основную статью (в английской Энциклопедии он отдельной, но кто-то предлагает объединить).РоманСузи 17:27, 29 августа 2007 (UTC)

[править] Javascript

В разделе про Psyco написано про трансяцию в Javascript. Подозрваю что это ошибка, возможно имелась в ввиду Java. Поправьте статью если я прав. --82.207.49.249 22:56, 10 февраля 2008 (UTC)

Я не нашел места где сказано о трансляции python в JavaScript c помощью psyco. Они оба упоминаются в разделе о PyPy но не связанны между собой. Просто PyPy умеет и трансляцию в JavaScript и psyco. K.Danilov aka koder 21:54, 11 февраля 2008 (UTC)

Понятно, это я действительно ступил. Кстати не знал что PyPy может это делать, спасибо. --194.44.22.44 12:12, 12 февраля 2008 (UTC)

[править] Раздел о недостатках

Посмотрев свежим взглядом статью я пришел к выводу, что раздел "Недостатки" нуждается в серьезном сокращении или вынесении куда-либо еще (может, особенно заинтересованные могут его хостить у себя?). Полагаю, что на каждый недостаток нужно выделить не более одного предложения. Например, отсутствие статической типизации как и перегрузка функций вообще вопрос спорный: мало ли чего в каком языке есть. Кому-то может макросы нужны, goto или еще что. Столько места потрачено на иллюстрацию некорректный сравнений! И т.д. В общем, давайте раздел сильно сократим, так как иначе это не статья, а дискуссионный форум, что не вполне Энциклопедии подходит. Нужны факты. Да, нет статической типизации. Да, некоторые считают это большой паллетный проблемой: вот ссылка на статью Кнута, Дейкстры и т.п. РоманСузи 18:52, 13 июля 2008 (UTC)

Пока что добавил флаг об отсутствии нейтральности. РоманСузи 18:59, 13 июля 2008 (UTC)

Я только что просмотрел и пришёл к выводу, что ни в коем случае не нужно сокращать раздел! Он хорошо и аргументированно написан, приведены интересные примеры из других языков. Утверждения типа "Низкое быстродействие" и "Отсутствие статической типизации" следует вынести в отдельный раздел, например "Критика", так как эти утверждения рассмотрены с обоих сторон и доказывается их несостоятельность в некоторых контекстах. И как раз с нейтральностью тут всё ИМХО в порядке. --gribozavr 19:15, 13 июля 2008 (UTC)
Я не говорю, что раздел плохо написан. Просто он занимает порядка 15 процентов всей статьи (на глаз, по скроллингу). А например статья про статическую типизацию вообще всего один абзац, хотя там-то как раз и можно на более общем уровне вопрос раскрыть или в динамической типизации. Низкое быстродействие интерпретируемых языков тоже не чисто питоновская черта. А ляп со сравнением величин разных типов - нужно ли выносить в статью вообще? На то есть багтрекер bugs.python.org. На мой взгляд, лучше несколько слов о "ловушках" сказать (например, семантика ссылок может дать неожиданные для новичка результаты и тп). Другими словами- информация в разделе по большей части дельная и долго обкатывалась, но я сомневаюсь, что ее место в настоящем объеме в статье про Python. А если раздел Критика создать, дак тогда и про отступы нужно сказать: критики со всех сторон много разной. Наверное, можно только быстродействие и GIL оставить в недостатках, а остальное в Критику и может быть с другими статьями поделиться? РоманСузи 19:30, 14 июля 2008 (UTC)
То, что статья про статическую типизацию короткая в это не повод кромсать эту :) Перенести в да, если это будет уместно там. Про сравнение величин в это, насколько я знаю Питон, абсолютно не ляп, а корректное поведение: [1] [2]. Возможно, объяснение и эти ссылки следует добавить в статью, чтобы такое поведение не выглядело ляпом.
Идеи про раздел "Критика" вполне поддерживаю. --gribozavr 19:53, 14 июля 2008 (UTC)
В сравнениях тоже ляп. Например, 4 < '4' в 2.х выдает истину, а в 3.0 - исключение. (И это есть правильное поведение). Так что, все-таки есть еще более корректное поведение. РоманСузи 20:01, 15 июля 2008 (UTC)
По поводу критики, на сайте ibm.com есть две хорошие статьи под названием "Изящество и неловкость Python" [3] [4]. Оттуда я узнал про несогасованность операторов сравнения. Правда там не столько про недостатки языка, сколько про особенности, которые могут быть неочевидны новичкам. Козырь 11:34, 21 июля 2008 (UTC)
Кстати, в немецкой версии de:Python (Programmiersprache) есть раздел критика, где перечислены основные моменты. РоманСузи 19:38, 1 августа 2008 (UTC)
Насколько я знаю немецкий язык, там описаны следующие пункты:
  • Необходимость указывать self как первый аргумент методов классов (на самом деле у статических методов (@staticmethod) и у методов класса (@classmethod) первый аргумент в не self);
  • Аргумент по умолчанию вычисляется на этапе компиляции, а не на этапе выполнения. Подробнее см. [5];
  • Необходимость указывать класс и экземпляр при вызове super. Будет исправлено в Python 3000 [6];
  • Отсутствие конструкций do: ... while и switch: ... case:;
  • Результат деления двух целых чисел в целое число. Будет исправлено в Python 3000;
  • GIL.
К стати, немецкая статья отмечена звездочкой, хотя она в несколько раз короче русской! Козырь 12:18, 5 августа 2008 (UTC)

[править] Субъективное мнение

Реализация ООП в Питоне является элегантной, мощной и хорошо продуманной

Убирать надо такие ничем не подкреплённые субъективизмы. --Seleckis 15:21, 11 апреля 2009 (UTC)

Там еще "но" добавлено:

но вместе с тем достаточно специфической по сравнению с другими объектно-ориентированными языками.

А особенно если дать Энцикло-ссылку на Элегантный ;-) то не совсем понятно, элегантен Python или экстравагантен ( Экстравагантность). Но полагаю, что "этико-эстетические" категории все-таки можно давать языку программирования. РоманСузи 18:05, 17 мая 2009 (UTC)

Согласен, складывается ощущение что статью писали люди с комплекасами. Быстрый, мощный, богатый, хорошо продуманный... детский сад, ей богу. Писать нужно сухимим фактами в Энциклопедии, а не высокохудожественным текстом, а третья сторона сама сравнит и примет решение, хорошо продумано или плохо. 95.133.172.177 11:09, 29 ноября 2009 (UTC)

[править] Новый перевод "Дзена Python

Некоторые из принципов откровенно непонятные. Я перевожу блог Гвидо ван Россума об истории Питона и заодно перевел принципы заново. Вот что получилось. Собственно, зацените.


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

Явное лучше неявного.

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

Сложное лучше усложнённого.

Плоское лучше вложенного.

Разрежённое лучше плотного.

Удобочитаемость важна.

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

При этом практичность важнее безупречности.

Ошибки никогда не должны возникать незаметно.

За исключением незаметности, которая задана явно.

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

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

Даже если этот путь с первого взгляда может быть не очевиден (особенно если вы не голландец).

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

При этом «никогда» часто бывает лучше, чем «прямо сейчас».

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

Если реализацию легко объяснить в то в ее основе может быть хорошая идея.

Пространства имён в великолепная идея. Давайте наделаем их побольше!

Ziderzee 00:00, 7 мая 2009 (UTC)

Хороший перевод. Я бы убрал попытаться из "соблазна попытаться угадать", а также "За исключением незаметности, которая задана явно." перефразировал. В оригинале говорится в трех словах. РоманСузи 17:56, 17 мая 2009 (UTC)

[править] Питон?

Почему именно Питон? Я думаю, стоит слово "Питон" в статье целиком поменять на Python. --.silent 16:20, 11 августа 2009 (UTC)

  • Честно говоря, не вижу в использовании названия "Питон" никакого криминала, требующего немедленного удаления всех таких вариантов из статьи. В конце концов, языки называются Modula, Ada, C, Pascal, Simula, Smalltalk и т.п., но мы пользуемся названиями Модула, Ада, Си, Паскаль, Симула, Смолток и т.п. Чем "Питон" хуже? -- AVBtalk 16:30, 11 августа 2009 (UTC)
Скорее наоборот, всюду, включая название, Python имеет смысл заменить на Питон. В любом случае, единообразность должна быть. --Plest 13:30, 16 декабря 2009 (UTC)

[править] Автор Дзена

>>> import this; The Zen of Python, by Tim Peters

Ясно же написано, Тим Петерс (накрайняк - Питерс). Откуда взялся Тим Пейтерс? Или по аналогии с Питон - Пайтон?

--91.200.106.28 09:32, 26 августа 2009 (UTC)noname

[править] Комплексы авторов

Питон, как и многие другие интерпретируемые языки, не применяющие, например, JIT-компиляторы, имеют общий недостаток в сравнительно невысокую скорость выполнения программ.[39] Однако, в случае с Python этот недостаток компенсируется уменьшением времени разработки программы.

в это как вообще понимать? Он хоть и короткий, зато белый? 95.133.172.177 11:14, 29 ноября 2009 (UTC) Так и понимать - скорость исполнения результирующей программы принесена в жертву уменьшению времени ее написания. Это не комплексы авторов, а принципы проектирования языка. K.Danilov aka koder 11:39, 29 ноября 2009 (UTC)

это вообще характеристика интерпретируемых языков, если уже на то пошло. Питон, похоже, "более интерпретируемый среди интерпретируемых" )) --Aleks Revo 06:45, 22 марта 2011 (UTC)

[править] Символ % для форматирования строк

Насколько мне известно, от этого элемента синтаксиса хотят избавиться в Python 3.2, а начиная с 3.0 рекомендуют не пользоваться. Это надо отразить в разделе "Синтаксис и семантика, выражения". 194.190.225.135 10:48, 4 декабря 2009 (UTC)

Вот ссылка: http://docs.python.org/dev/py3k/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting 194.190.225.135 10:58, 4 декабря 2009 (UTC)

[править] Применение Питона

Мне думается неплохо бы было расписать плюсы и минусы применения Питона в контексте различных категорий задач, как то: создание сайтов, разработка серверных приложений, простых или сложных веб-интерфейсов, десктоп-приложений и т.д --Inventor10 06:55, 28 мая 2010 (UTC)

[править] Категории

Предложение

Эти категории перенести в категорию Python

А эти перенести с статьи о реализациях питона, к самому языку они отношения не имеют.

  • "Языки программирования для искусственного интеллекта"? Какая-то очень странная категория, на грани ОРИССа. Искуственным интеллектом можно на практически любом языке заниматься, в том числе и на Питоне. Эта категория, как я понимаю, предназначена для DSL-языков (иначе бы туда все языки можно подобавлять), коим Питон не является, поэтому удаляем эту категорию. -- X7q 20:53, 3 июня 2010 (UTC)
  • Раз возражений не поступало, в Сделано--AlexVinS 12:06, 13 июня 2010 (UTC)

[править] Энциклофикация расширений

Здравствуйте! Зачем было Энциклофицировать расширения .py, .pyw, .pyc, .pyo? Первый ведет на статью о национальном домене верхнего уровня для Парагвая. Все остальные ведут на эту статью. Смысл тогда в Энциклофикации? --Cheburator-all [ Обс ] 02:59, 4 сентября 2010 (UTC)

[править] Re: нонсенс! θ в‰  с

Я согласен с утверждением, что θ в‰  с. Но куда девать тогда bluetooth -> блютус, где θ == с? Если применяются такие варианты транскрипции, может стоит вернуть этот вариант? Он не является широко употребляемым, но такое произношение допускается. Mystic-Mirage 19:57, 18 октября 2010 (UTC)

А ещё Голсуорси. Но это, как и в случае с суши в исключение, устоявшаяся разговорная форма, утвердившаяся в языке до того, как распространилась (а на самом деле не распространилась) правильная транскрипция слова. --Денис Кривошеев 14:46, 7 августа 2011 (UTC)

[править] Регулярные выражения

Хотелось бы хотя бы немного почитать о них здесь. В разделе "Влияние других языков на Python", наверное, можно было бы упомянуть, что их формат унаследован из Perl. Может быть, даже стоит упомянуть стандартную и полезную программку для их проверки в redemo.py. 79.132.161.174 18:43, 21 ноября 2011 (UTC)

[править] Отсутствие статической типизации как недостаток

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

  1. Python - язык с динамической типизацией, и говорить об отсутвии статической как о недостатке бессмысленно. Это подобно тому, что рассматривать отсутсвие полового члена у женщины как недостаток. Но всем известно что это не является недостатком, т.к. женщина это женщина, а мужчина это мужчина. Бывают динамически типизируемые языки, бывают статически. Python динамический, но это не является его недостатком, а является его свойством. Вот и всё.
  2. В enci есть статья про динамическую типизацию все факты там уже приведены: Про ошибки: "Статическая типизация позволяет уже при компиляции заметить простые ошибки «по недосмотру». Для динамической типизации требуется как минимум выполнить данный участок кода.", про скорость "Низкая скорость, связанная с динамической проверкой типа. К тому же большинство языков с динамической типизацией интерпретируемые, а не компилируемые",
  3. Статья про Python и должна рассматривать свойства Python а не его сторонних библиотек. Расуждения о typecheck, PEAK и др. библиотеках, если они значимы, должны находится в отдельных статьях. Подобно тому как для c++ существуют статьи про Boost, TR1, TR2.

Я уже пытался удалить этот пункт, но тов. ABV его вернул. Призываю ABV к развёрнутой аргументации своей позиции. в Эта реплика добавлена с IP 109.195.172.54 (о) 12:17, 29 мая 2012вЋ (UTC)

  • Во-первых, ABV - AVB, вообще-то. Во-вторых, бессмысленно - вы не поверите, но даже в языках с динамической типизацией возможна статическая типизация (с ограничениями, разумеется). (А ваше сравнение женщин и мужчин некорректно, поскольку существуют гермафродиты). В-третьих, вы удаляете не просто общие слова про "достоинства и недостатки динамической типизации", а раздел, посвящённый особенностям типизации в Питоне. Возможно, стилистически там и есть лишние слова и даже фразы, но явно не весь раздел. Наконец, не его сторонних библиотек - а где вы видите "рассмотрение свойств сторонних библиотек"? Я вижу там упоминание сторонних библиотек в контексте расширения функционала языка, в том числе основанные на официальных планах. -- AVBtalk 12:31, 29 мая 2012 (UTC)
    • Сорри, у миня плохое зрение поэтому неправильно написал ваш ник.
  1. Про гермафродитов правильно, есть языки и со смешанной типизацией. Например haxe - http://haxe.org. Т.е. он статически типизирован как java, но у него есть особый тип Dynamic http://haxe.org/setlang?url=/ref/dynamic;lang=ru который предоставляет динамическое поведение.
  2. Правильно, но этот подраздел называется "Недостаток отстувия статической типизации", переименуйте его в "особенности типизации python" удалите первый абзац, и перместите из раздела "недостатки" в другой раздел. И я не стану больше удалять. Либо если у вас больше нет контраргументов, я могу сам этим заняться. в Эта реплика добавлена с IP 109.195.172.54 (о) 12:44, 29 мая 2012вЋ (UTC)
  • со смешанной типизацией - я не об этом. Вот, с ходу, что вспомнилось, в качестве примера: http://lua-users.org/DetectingUndefinedVariables . Здесь обсуждается, среди прочего, как выполнять статический (на этапе компиляции) анализ обращений к неинициализированным переменным, но, в принципе, статический анализ можно применять и для других аспектов. переименуйте - простите, мне не до этого. Можете сами попробовать переформулировать. -- AVBtalk 13:42, 29 мая 2012 (UTC)
Источник в «/w/index.php?title=Обсуждение:Python&oldid=44854242»
Пространства имён

Варианты
Действия