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

↓

Пожалуйста, добавляйте новые темы снизу

Рефакторинг статьи

Немного подправил текст во многих местах. Считаю, что не нужно так хвалиться (хотя и понимаю, что очень хочется). Википедия должна подавать информацию нейтрально - факты. Надеюсь, что после исправления стало лучше. 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)

По поводу названия, взятого из Монти Пайтон -- все верно, но на логотипе почему-то змея, а не лики товарищей из Монти Пайтон. Ну а змея эта по-русски называется "питон", а не "пайтон". Еще меня смущает, почему вы название языка (имя собственное) пишете с маленькой буквы. Mr. Botanical (обс.)

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)

• В итоге код унесли на Викиверситет [1] - вот он [2]. @YarTim, может как-то туда ссылку вкрячим и перенесём удаляемые примеры отсюда? Saramag (обс.) 10:34, 24 марта 2021 (UTC)
  • Так вот же: Python#Примеры_программ, «В статье „Примеры программ на языке Python“ Викиверситета собраны примеры небольших программ, демонстрирующих некоторые возможности языка Python и его стандартной библиотеки». А те листинги попробую перенести. YarTim (обсуждение, вклад) 10:39, 24 марта 2021 (UTC)
    • Может тогда и "Примеры программ" сократим? Вообще конечно не очень звучит про "страницу Викивирситета"... Saramag (обс.) 10:43, 24 марта 2021 (UTC)
      • Тоже думал, что когда статья будет в своем идеальном состоянии, надо будет убрать примеров, так как примеров будет в достаточном количестве и в Викиверситете и по статье. YarTim (обсуждение, вклад) 10:51, 24 марта 2021 (UTC)
      • Вопрос: как тогда сделать ссылку на Викивеситет так, чтобы и была заметна, и так, чтобы было оформлено нормально? YarTim (обсуждение, вклад) 10:52, 24 марта 2021 (UTC)
      • Также есть викиучебник: b:Примеры программ на языке Python YarTim (обсуждение, вклад) 10:53, 24 марта 2021 (UTC)
        • Я не нашёл спецшаблонов под наш случай (Шаблон:Викиучебник не подходит) - давай так Примеры программ на языке Python. А это ссылка на учебник. А есть что-то подобное, но для Викиверситета?— Saramag (обс.) 11:03, 24 марта 2021 (UTC)
          • Практика по языку Python/Примеры программ на языке Python так? YarTim (обсуждение, вклад) 11:11, 24 марта 2021 (UTC)
            • Думаешь стоит показывать этот v: ? Я б его скрыл.— Saramag (обс.) 11:19, 24 марта 2021 (UTC)
              • Не-а YarTim (обсуждение, вклад) 11:21, 24 марта 2021 (UTC)

• • Нормально? [3] YarTim (обсуждение, вклад) 10:46, 24 марта 2021 (UTC)
    • вроде да. Saramag (обс.) 10:47, 24 марта 2021 (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)

Через 7 лет мне он все еще не нравится.

Про недостатки

Мне кажется, что "Отступление от объектно-ориентированной чистоты" и "Невозможность модификации встроенных классов" - это одна и та же проблема, а не две. (Само выражение "Отступления от объектно-ориентированной чистоты", на мой взгляд, смешно, так как Питон и не являет собой выражение чистоты какой-либо парадигмы). Вообще, говоря о недостатках и достоинствах сложно быть объективным, так как недостатки обычно играют роль только для части применений языка. Дизайн ЯП всегда компромисс, поэтому недостатки, на мой взгляд, должны быть написаны в формате, который обрисовывает обе стороны противоречия. РоманСузи 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)

То, что статья про статическую типизацию короткая — это не повод кромсать эту :) Перенести — да, если это будет уместно там. Про сравнение величин — это, насколько я знаю Питон, абсолютно не ляп, а корректное поведение: [4] [5]. Возможно, объяснение и эти ссылки следует добавить в статью, чтобы такое поведение не выглядело ляпом.

Идеи про раздел "Критика" вполне поддерживаю. --gribozavr 19:53, 14 июля 2008 (UTC)

В сравнениях тоже ляп. Например, 4 < '4' в 2.х выдает истину, а в 3.0 - исключение. (И это есть правильное поведение). Так что, все-таки есть еще более корректное поведение. РоманСузи 20:01, 15 июля 2008 (UTC)

По поводу критики, на сайте ibm.com есть две хорошие статьи под названием "Изящество и неловкость Python" [6] [7]. Оттуда я узнал про несогасованность операторов сравнения. Правда там не столько про недостатки языка, сколько про особенности, которые могут быть неочевидны новичкам. Козырь 11:34, 21 июля 2008 (UTC)

Кстати, в немецкой версии de:Python (Programmiersprache) есть раздел критика, где перечислены основные моменты. РоманСузи 19:38, 1 августа 2008 (UTC)

Насколько я знаю немецкий язык, там описаны следующие пункты:

• Необходимость указывать self как первый аргумент методов классов (на самом деле у статических методов (@staticmethod) и у методов класса (@classmethod) первый аргумент — не self);
• Аргумент по умолчанию вычисляется на этапе компиляции, а не на этапе выполнения. Подробнее см. [8];
• Необходимость указывать класс и экземпляр при вызове super. Будет исправлено в Python 3000 [9];
• Отсутствие конструкций 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 и т.п., но мы пользуемся названиями Модула, Ада, Си, Паскаль, Симула, Смолток и т.п. Чем "Питон" хуже? -- A^VB^talk 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

• Категория:Скриптовые языки
• Категория:Высокоуровневые языки программирования
• Категория:Объектно-ориентированные языки программирования
• Категория:Языки с динамической типизацией
• Категория:Функциональные языки программирования
• Категория:Языки программирования для искусственного интеллекта

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

• Категория:Кроссплатформенное программное обеспечение
• Категория:Программное обеспечение для Linux
• Категория:Программное обеспечение для Mac OS X
• Категория:Программное обеспечение для Windows

• Категория:Свободные компиляторы и интерпретаторы
• Категория:Свободные инструменты для разработки ПО
• Категория:Свободное ПО, написанное на Си

• "Языки программирования для искусственного интеллекта"? Какая-то очень странная категория, на грани ОРИССа. Искуственным интеллектом можно на практически любом языке заниматься, в том числе и на Питоне. Эта категория, как я понимаю, предназначена для 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)

Сделано Упомянул о них, а вот значимости данного скрипта для его упоминания я не увидел. --0x0F 11:44, 9 мая 2016 (UTC)

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

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

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

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

• Во-первых, ABV - AVB, вообще-то. Во-вторых, бессмысленно - вы не поверите, но даже в языках с динамической типизацией возможна статическая типизация (с ограничениями, разумеется). (А ваше сравнение женщин и мужчин некорректно, поскольку существуют гермафродиты). В-третьих, вы удаляете не просто общие слова про "достоинства и недостатки динамической типизации", а раздел, посвящённый особенностям типизации в Питоне. Возможно, стилистически там и есть лишние слова и даже фразы, но явно не весь раздел. Наконец, не его сторонних библиотек - а где вы видите "рассмотрение свойств сторонних библиотек"? Я вижу там упоминание сторонних библиотек в контексте расширения функционала языка, в том числе основанные на официальных планах. -- A^VB^talk 12:31, 29 мая 2012 (UTC)

• • Сорри, у миня плохое зрение поэтому неправильно написал ваш ник.

1. Про гермафродитов правильно, есть языки и со смешанной типизацией. Например haxe - http://haxe.org. Т.е. он статически типизирован как java, но у него есть особый тип Dynamic http://haxe.org/wiki/setlang?url=/ref/dynamic;lang=ru который предоставляет динамическое поведение.
2. Правильно, но этот подраздел называется "Недостаток отстувия статической типизации", переименуйте его в "особенности типизации python" удалите первый абзац, и перместите из раздела "недостатки" в другой раздел. И я не стану больше удалять. Либо если у вас больше нет контраргументов, я могу сам этим заняться. — Эта реплика добавлена с IP 109.195.172.54 (о) 12:44, 29 мая 2012 (UTC)

• со смешанной типизацией - я не об этом. Вот, с ходу, что вспомнилось, в качестве примера: http://lua-users.org/wiki/DetectingUndefinedVariables . Здесь обсуждается, среди прочего, как выполнять статический (на этапе компиляции) анализ обращений к неинициализированным переменным, но, в принципе, статический анализ можно применять и для других аспектов. переименуйте - простите, мне не до этого. Можете сами попробовать переформулировать. -- A^VB^talk 13:42, 29 мая 2012 (UTC)

Произношение

Почему же он "питон", если и в транскрипции и в источнике приведенном указывается что он "пайтон"? --RussianSpy 03:17, 1 декабря 2012 (UTC)

• Название не устоялось. Кто-то говорит (и пишет) Пайтон, кто-то Питон. (Лично предпочитаю Python и лишь в разговоре на русском - питон). Вот например статья: http://www.xakep.ru/magazine/xa/117/088/1.asp где пишется Питон, Python, хотя и говорится о Монти Пайтоне. Наверное, где-то в истории статьи есть более внятное начало статьи. РоманСузи 06:43, 1 декабря 2012 (UTC) исправил как было раньше. РоманСузи 07:07, 1 декабря 2012 (UTC)
  • Не знаю почему вы считаете, что не устоялось. По-русски возможно, но тогда можно сказать что и Найки не устоялось и Джава. Вариант Пайтон хоть и используется реже, чем Питон, но все-таки используется. А вариант Питон является не более, чем ошибкой и жаргонизмом вроде Ява, ЯваСкрипт, Жаба, ПэХэПэ или "Си решетка". Самостоятельно не стал исправлять только из уважения к тому, что статья уже с золотой звездой (хотя странно как она вообще ее получила) --RussianSpy 10:31, 1 декабря 2012 (UTC)
    • Вот поэтому я и пишу везде Python. Про пайтон там упомянуто, в чем сейчас проблема? РоманСузи 12:05, 1 декабря 2012 (UTC)
      • Нет сейчас все хорошо, спасибо. ;) --RussianSpy 18:20, 1 декабря 2012 (UTC)

А почему вообще в англоязычных странах слово питон называется как пайтон? почему пишется как python, а произносится как пайтон? 94.233.150.217 03:13, 5 марта 2013 (UTC)

см. также и ссылки

По просьбе участника Участник:ZloAlien поясняю вот эту мою правку. Во вполне законченных статьях не стоит растить раздел «см. также», что особенно касается такой статьи, как Python, так как если в этот раздел поместить всё, на что можно смотреть, получится огромный список (иначе нарушится баланс). Если Python(x,y) обладает значимостью (=соответствует критериям включения в Википедию), давайте для начала это покажем в статье (а статья сейчас предложена к удалению, и я не пока не нашел авторитетных источников по теме). Eric удален аналогично по причине нарушения нейтральности/взвешенности.

Если мы хотим сохранить статью Python в избранных, давайте не будем добавлять в неё все подряд.

Что касается pythonxy, то нужно подумать, где о нём может быть информация. Полагаю, что благодаря источникам вроде этого, или этого и еще нескольких (можно найти) при желании можно создать статью по теме Научные приложения языка Python (или подобное — это навскидку), где раскрыть тему. РоманСузи 12:50, 12 января 2013 (UTC)

Огромное спасибо за пояснения. К добавлению ссылок меня побудил тот факт, что когда я начинал знакомиться с Python, я не мог определиться с тем, какую IDE использовать. Использование консоли Python к сожалению не очень удобно, к тому же, я хотел создавать приложения с графическим интерфейсом. В результате длительных поисков я и остановил свой выбор на Eriс, а Python(x,y) стал настоящим открытием, которое показало какими возможностями обладает Python. Хотелось бы, что бы люди, начинающие изучение Python могли удобнее определиться с тем, какие инструменты они могли бы использовать. В связи с этим есть предложение добавить в статью ссылку на http://ru.wikipedia.org/wiki/Сравнение_IDE#Python (как альтернативу ссылке на Eric), поскольку про IDE в ней мало написано.

По Python(x,y) - буду искать АИ. А статью по теме Научные приложения языка Python пока создавать полагаю рановато - я не смогу материалом её грамотно наполнить, хотя, как погляжу, в научной среде Python используется довольно интенсивно (один Sage чего стоит). Но предложение заманчивое - надеюсь материала поднакоплю и статью создам. — Эта реплика добавлена участником ZloAlien (о • в)

• На мой взгляд — хорошее решение! Конечно, ссылка на сравнение IDE есть в навигации внизу, но читатель врядли будет искать там. Я добавил в см. также указанную Вами страницу, ведущую прямо к пункту о Python. Что касается python(x, y) — Вы сможете добавить его в таблицу? (полагаю, там можно снабдить ссылкой на официальный сайт пока нет АИ получше). РоманСузи 12:08, 13 января 2013 (UTC) Добавлю: добавив ссылку в смтакже я не противоречу сам себе, так как (сюрприз!) в статье вообще отсутствует раздел об IDE. Так что, если кому-то см. также будет мозолить глаза, пусть напишут коротко в тексте и уберут из см. также. (другими словами, полагаю, что см. также — временное решение) РоманСузи 12:13, 13 января 2013 (UTC)

• Python(x,y) добавить в таблицу было бы неправильно, поскольку данное программное обеспечение не является IDE. Это скорее сборка всевозможных модулей расширения. С одной стороны, такая сборка не представляет интереса, поскольку все её компоненты можно скачать отдельно. С другой стороны, она служит своего рода библиотекой модулей и программ и позволяет производить их быструю установку (и скачивание из одного места). Она важна тем, что позволяет получить представление о возможностях языка. АИ в Python(x,y) я добавлю, а оформить ссылку на статью - затрудняюсь. Кажется оптимальным упомянуть данное ПО в разделе "Модули расширения и программные интерфейсы". Впрочем, с этим можно не торопиться и подождать когда я побольше материала в Python(x,y) добавлю.ZloAlien 17:11, 14 января 2013 (UTC)ZloAlien

Типизация

Так у питона строгая или динамическая типизация? На странице языка написано, что строгая, а на странице динамической типизации есть ссылка на питон. 91.200.156.90 23:02, 6 апреля 2013 (UTC)Ринат

• Строгая динамическая. Строгая, так как у любого объекта тип всегда однозначно определен (известен). Динамическая, так как тип (соответственно, контроль типов при операциях) выполняется во время исполнения. Думаю, что АИ можно легко найти на эту тему. РоманСузи 06:37, 7 апреля 2013 (UTC)

• Строгая имхо означает, что не происходит неявного преобразования типов.

Указание источника?

Версия 06:33, 16 февраля 2014 (править) (отменить) РоманСузи (обсуждение | вклад) (отменён вклад без указания источника; автовикификация)

РоманСузи, а что из указанных проблем вызывает вопросы? Прям таки на все указанное в статье указаны источники?

— Эта реплика добавлена с IP 94.216.63.126 (о) 10:00, 16 февраля 2014 (UTC)

• Вы добавили достаточно много текста. Статья Python является статусной и утверждаемые в статье сведения должны содержать ссылку на авторитетный независимый источник (Вы же не сами это выдумали, правда?), так как иначе статья постепенно перестанет соответствовать избранному статусу. Поэтому, укажите Ваши источники или текст будет удаляться. Дело тут не в аргументах типа «не на все указаны источники». К качеству статусной статьи нужно относиться с особенной тщательностью, если мы хотим чтобы данная статья была и далее таковой. Впрочем, в обычных статьях подобный вклад тоже является медвежьей услугой. Положим, что Вы прочитали где-то, что "переход на версию 3 затягивается" и хотите внести в Википедию. Если Вы не написали источника (и при этом желательно авторитетного и независимого), то текст будет висеть до тех пор, пока некоторый редактор не пометит его, что требуется источник. Найти источник не по свежим следам очень сложно, поэтому вклад будет удален, потратив время трех участников впустую. Именно поэтому я сразу удалил текст (его собственно никогда и не видели обычные читатели, так как статья защищена). Надеюсь на понимание и более внимательное отношение к правилам Википедии. Тогда труд будет на пользу всем. РоманСузи 10:18, 16 февраля 2014 (UTC)

• Или "авторитетных" по вашему понятию источников нету, хотя "неавторитетных" полно (это про затягивается), или мне их выискивать и указывать влом (возвращенные фичи элементарно находятся в ченджлоге). В других статьях другие редактирующие обычно владеют предметом и не откатывают, а сами при необходимости добавляют ссылки - такие статьи редактировать приятно. Вы, судя по всему, им не владеете или пишете на нем какой-то научный/вузовский шлак (который представляет из себя сколько? 5 процентов применения питона?), иначе бы хотя бы часть из этого вы бы где-то слышали. А на каждую строчку искать "авторитетный" по каким-то вашим понятиям источник влом (блог ронахера - это АИ? А если я к тем же самым выводам приду - это уже не АИ будет?). За редактирование мне денег не платят и других кудосов тоже не дают. А вы давайте валяйте дальше со своими "статусными" статьями, замершими в состоянии нескольколетней давности. — Эта реплика добавлена с IP 94.216.39.227 (о) 20:07, 16 февраля 2014 (UTC)

Дело не во владении Романа предметом, статью будут читать и пользователи которые предметом не владеют. Википедия предоставляет пользователям инструмент для верификации данной в статьях информации, которым и являются ссылки на авторитетные источники. Прочтите правила о проверяемости и запрете оригинальных исследований, там есть ответы на ваши вопросы. А за редактирование и нам никто денег не платит, и гуглить подтверждения для безграмотного бреда, который добавил очередной гастролёр, решивший поделиться с миром своей великой мудростью, как-то тоже влом. Так что, если вы не будете редактировать, Википедия, наверняка, только выиграет. — WitcherGeralt 10:15, 17 февраля 2014 (UTC)

• Прошу в дальнейшем воздерживаться от правок подобных этой. Википедия не ваш личный блог. Старайтесь придерживаться энциклопедического стиля и не забывайте ссылаться на авторитетные источники, а также про викификацию и прочие аспекты оформления. — WitcherGeralt 13:20, 16 февраля 2014 (UTC)

• Я об этом обязательно подумаю, ога. — Эта реплика добавлена с IP 94.216.39.227 (о) 20:07, 16 февраля 2014 (UTC)

• Хамские комментарии будут удаляться. РоманСузи 17:26, 17 февраля 2014 (UTC)

Последние две правки

Знание того, что декоратор это замыкание сильно упрощает его понимание. Интересно, они были заимствованы из JS? 109.248.190.105 01:17, 11 октября 2016 (UTC)

Моя правка (комментарии)

https://ru.wikipedia.org/ruwiki/w/index.php?title=Python&diff=81834523&oldid=81538330 print() можно использовать в python 2 Psyco уже давно умер, и вместо него нужно использовать PyPy PyPy перемещён в списке реализаций на 1 место, т.к. он самый развитый из альтернативных реализаций. В PyPy JIT компилятор уже давно поставляется по умолчанию dict comprehensions были добавлены в python 2.7 (a, *rest, b) = range(5) - скобки не обязательны Tiberiumk (обс.) 14:30, 12 ноября 2016 (UTC)

Чушь в статье

Все объекты делятся на ссылочные и атомарные. К атомарным относятся int, long (в версии 3 любое число int, так как в версии 3 нет ограничения на размер), complex и некоторые другие. При присваивании атомарных объектов копируется их значение, в то время как для ссылочных копируется только указатель на объект, таким образом, обе переменные после присваивания используют одно и то же значение.

В питоне все объекты ссылочные. Пруфы будут?

• Вроде исправлено до конца, спасибо анониму с ip-адресом на 5.*. -- D6194c-1cc (обс.) 15:44, 25 января 2021 (UTC)
  • почти что ровно год с сообщения... YarTim (обсуждение, вклад) 16:25, 25 января 2021 (UTC)

Примеры

У:D6194c-1cc, что насчёт примеров? В принципе, можно двумя путями:
1. Описывается какая-то фича, за ней идёт сразу же демонстрация.
2. Всё свалить в один раздел.
При этом конечно же, надо, чтобы примеры были по источникам. Что, если из каждого источника вытащить по два-три листинга (чтобы не было копивио) и поместить в статью? YarTim (обсуждение, вклад) 16:33, 24 января 2021 (UTC)

• Немного не понял, почему вопрос именно ко мне, а не вообще, ну да ладно, я эту статью даже не читал ещё толком. На мой взгляд, лучше после наиболее значимых функций примеры вставлять, можно их также в спойлеры оформлять, если они более менее большие. Что касается источников, программный код легко проверяется, тут есть программисты, примеры составить очень легко. Если хотите подкреплять источниками, можно просто похожий пример делать и ставить на него источник. -- D6194c-1cc (обс.) 16:51, 24 января 2021 (UTC)
  • Ведь вы тоже хотите довести статью до статуса? . Мне кажется, что если мы будем писать в примерах отсебятину, кто-то скажет, что орисс. YarTim (обсуждение, вклад) 16:56, 24 января 2021 (UTC)
    • По многим темам Вы нужные примеры просто можете не найти, либо они будут не совсем такие, какие требуются. Так или иначе, примеры из книги лучше видоизменять. Предлагаете попробовать совместно доработать статью? Давайте. -- D6194c-1cc (обс.) 17:07, 24 января 2021 (UTC)
    • А Вы вообще насколько хорошо знакомы с Python? -- D6194c-1cc (обс.) 04:39, 25 января 2021 (UTC)
      • В первую очередь с точки зрения олимпиадного программирования. Вроде бы как на среднем уровне. С другой стороны конечно же надо чтобы кто-то шарящий следил, чтобы я не упал стремительным домкратом из-за незнания чего-то. YarTim (обсуждение, вклад) 09:26, 25 января 2021 (UTC)
        • У меня тоже Python не профильный язык, скорее вспомогательный. -- D6194c-1cc (обс.) 15:58, 25 января 2021 (UTC)
• Я пока паузу возьму на недельку-другую, нашёл более приоритетную задачку. Если что я могу потом поревьюить изменения все сразу, если будете вносить. -- D6194c-1cc (обс.) 17:32, 26 января 2021 (UTC)
  • В принципе, ничто по времени нас не ограничивает. Можно хоть год дорабатывать. YarTim (обсуждение, вклад) 18:38, 26 января 2021 (UTC)

Источники

Посмотрел Гугл Школяр. А там больше миллиона статей. Конечно, часть из них не о нашей теме, часть первоисточники, часть по слишком узким темам (типа машинного обучения и распознавания голоса). Но количество радует. YarTim (обсуждение, вклад) 19:45, 25 января 2021 (UTC)

• А что за источник такой home.simula.no? -- D6194c-1cc (обс.) 15:42, 26 января 2021 (UTC)
  • Случайно неправильно сделал ссылку и выводило 404. Поправил.
    Там была работа про производительность Cython YarTim (обсуждение, вклад) 16:04, 26 января 2021 (UTC)
    • Мне этот источник не кажется авторитетным, учитывая, что там говорится о компиляции напрямую в бинарный код, в то время как в оф. документации компиляция идёт в Си- и C++-код ([10]). А как Вы по этому источнику писали вообще, если там другое сказано? -- D6194c-1cc (обс.) 16:51, 26 января 2021 (UTC)
      • Впрочем, наверное, там имелось в виду, что код не просто транслируется в Си, но потом компилируется, странная формулировка: «Cython does not simply translate Python code to C code. Instead, it uses the Python run-timeenvironment, compiling everything directly to machine code.» -- D6194c-1cc (обс.) 17:03, 26 января 2021 (UTC)
        • В оригинале (в англовики) там это стояло без источника (несмотря на то что это ХС, хотя и избранная в 2009 году). Решил найти источник, подтверждающий это. Видимо, не до конца вчитался. Посмотрю что-то другое тогда. YarTim (обсуждение, вклад) 17:09, 26 января 2021 (UTC)
          • А ещё что за прямые вызовы API C из интерпретатора? Мой мозг долго и упорно не мог понять, что не так с этой фразой. -- D6194c-1cc (обс.) 17:15, 26 января 2021 (UTC)
            • When speed is important, a Python programmer can move time-critical functions to extension modules written in languages such as C, or use PyPy, a just-in-time compiler. Cython is also available, which translates a Python script into C and makes direct C-level API calls into the Python interpreter.
              Ну, давайте пока что про всякого рода вспомогательные программы и надстройки не будем пока что писать. Потом напишем отдельный раздел. YarTim (обсуждение, вклад) 18:25, 26 января 2021 (UTC)
• D6194c-1cc, нашёл большую базу пиратских книжек по программированию, не знаю, что там с авторскими правами. Ссылку здесь оставить или прислать по википочте? YarTim (обсуждение, вклад) 07:27, 16 февраля 2021 (UTC)
  • Ещё у меня есть сканер. Если надо, могу какие-то страницы от книги Рамальо кинуть. YarTim (обсуждение, вклад) 11:16, 16 февраля 2021 (UTC)
  • Я не сторонник пиратства, хоть и в России живу. Книги я покупаю, как и музыку, игры и софт. В ходе редактирования Википедии у меня уже небольшая коллекция книг по медицине накопилась, в то время как даже до «Чистого кода» никак не доберусь. Один раз мне скинули книгу в электронной версии, так я после прочтения из уважения к автору купил бумажную версию (которую, правда, потом подарил, но обязательно куплю ещё одну, т.к. книга была очень интересная, про работу мозга). Пиратские версии я рассматриваю лишь как способ оценки того, что стоит купить.

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

-- D6194c-1cc (обс.) 16:18, 16 февраля 2021 (UTC)

• Ладно... Как по мне, нету ничего морально плохого нет в том, чтобы для Википедии использовать защищённые авторским правом источники. Статья-то улучшится, авторы не потеряют денег. Мне кажется, что часто будут возникать моменты, что какая-то вещь адекватно описана только в какой-то книжке, которую даже Гугл-букс не оцифровал. И будет выбор: описывать штуковину, или не описывать. YarTim (обсуждение, вклад) 16:58, 16 февраля 2021 (UTC)

Python#Типы_и_структуры_данных

@D6194c-1cc Перевел таблицу из англовики. Вопрос: как объяснить, что такое элипсис? Как я понял, это некоторый экзотический тип, существующий в самом языке, но использующийся в первую очередь NumPy-ем YarTim (обсуждение, вклад) 20:10, 12 февраля 2021 (UTC)

• Книжка Рамальо, которая лежит передо мною хороша тем, что концетрируется именно на такого рода тонкостях. В принципе, нормальное объяснение выловил? YarTim (обсуждение, вклад) 20:43, 12 февраля 2021 (UTC)
  • Многоточие предлагаю всё же называть по-русски, по крайней мере это название используется в интернете наряду с троеточием. Многоточие позволяет не указывать полный срез для всех измерений (dimensions), то есть заменить множество «:, » на «...». Указание же в конце не имеет смысла, т. к. a[0, ...] — это то же, что и a[0]. По крайней мере к таким выводам я пришёл экспериментируя с numpy.arange(16).reshape(2, 2, 2, 2). -- D6194c-1cc (обс.) 11:44, 13 февраля 2021 (UTC)

Обобщённое программирование в Python

Насколько вообще корректно говорить об обобщённом программировании (Generics) в языке с динамической типизацией, в котором невозможно явно указать тип? Я не смог найти серьёзного источника, который бы явно говорил об обобщённом программировании в python или о его отсутствии. То есть generics есть как набор pep'ов, но они лишь на уровне подсказок (hints), а для их полноценной работы требуется предобработка вне интерпретатора python. Полноценные же generics реализуются посредством использования линтера mypy. -- D6194c-1cc (обс.) 11:54, 13 февраля 2021 (UTC)

• Ну, бОльшую часть статьи составляет нечто, граничащее с ориссом. Узнал кто-то, что в Python есть некие "дженерики", узнал, что оные "дженерики" относятся к обобщённому программированию и написал. Для статьи про программирование это не так страшно, как для статьи про медицину. Но, чтобы ляпсусов не было, надо писать по источникам.
  Сносим? YarTim (обсуждение, вклад) 12:19, 13 февраля 2021 (UTC)
  • Переформулировал. Меня больше интересовало несколько иное, динамическая типизация как бы ограниченно интегрирует в себе обобщённое программирование, но отсутствие статическое типизации не позволяет делать адекватный контроль типов аргументов. Поэтому и полагаю, что говорить об обобщённом программирования в данном случае не совсем корректно.

А что касается «не так страшно» в программировании, в плане парадигм неважно, но к некоторым вещам лучше подходить серьёзно, я начал редактировании Википедии как раз с «починки» примеров кода, где отсутствовало освобождение переменных. То есть новичок скопирует код себе и получит утечку, но не факт, что узнает о ней, а со временем отсутствие освобождения памяти может стать привычкой. По этой же причине, например, я не перехожу небольшие дороги на красный, даже если машин нет и все идут (хотя, конечно, по молодости всё было наоборот), потому что это плохой пример, который потом могут перенять рядом стоящие дети или мамаши с детьми, наблюдающие как все спокойно идут на красный, а если хотя бы один человек не пойдёт, то это уже повод для размышлений. Серьёзный подход должен быть ко многим вещам, на самом деле.

-- D6194c-1cc (обс.) 13:07, 13 февраля 2021 (UTC)

• Орисс — штука плохая в любом случае. Я про то, что если кто-то будет писать орисс про Python, то будет меньше шансов, что будет какая-то недостоверная или плохая информация. К примеру потому что програмирование — штуковина для просвещённых, а просвящённые-просвящённые, которые хотят написать что-то в Википедию — люди довольно интелегентные YarTim (обсуждение, вклад) 13:37, 13 февраля 2021 (UTC)

• Тема интересная, но для исключения ВП:ОРИСС требуются источники (и достаточно авторитетные — статья на Хабре для этого не подойдёт, так как заявление достаточно сильное), в которых будет прямо написано о поддержке generic programming и о том, как именно эта поддержка работает. Кроме того, было бы неплохо указать о каком именно варианте обобщенного программирования идёт речь, раз уж пишем об этом. Соответственно, если источников нет — нужно будет утверждение удалить. Особой просвящённости для это не требуется, хотя умение грамотно реферировать — конечно. РоманСузи (обс.) 14:03, 13 февраля 2021 (UTC) Собственно, кое-что есть и в книгах. Можно найти через гугл: Python Scripting for Computational Science, Hans Petter Langtangen, Springer Science & Business Media, 9.1.2009 - 8.9.2. Some aspects of generic programming, p. 432 - к сожалению, у меня нет доступа к этой книге. РоманСузи (обс.) 14:14, 13 февраля 2021 (UTC)
  • Я просто сейчас искал что-то в гугл школяре, нашел ещё это [11]:
    The next feature any language needs in order to be considered a high-level language is generic programming. Even though VHDL provides a limited amount of generic programming it falls short when compared to a high-level language. Given the dynamic nature of Python it naturally provides possibilities for very generic programming. ARGG-HDL tries to preserve the generic programming model from Python as much as possible
    Работа посвящена HDL-фреймворку на основе Python. Подойдет ли этот источник? YarTim (обсуждение, вклад) 14:22, 13 февраля 2021 (UTC)
    • Здесь речь как раз о том, что динамическая типизация решает задачи обобщённого программирования, то, о чём я выше писал. Именно в такой формулировке и нужно добавлять информацию в статью. -- D6194c-1cc (обс.) 15:27, 13 февраля 2021 (UTC)
      • Ага, хорошо.
        P.S. Если мы доведем статью до статуса, что если потом будем писать в резюме про это общественно полезное дело? YarTim (обсуждение, вклад) 15:36, 13 февраля 2021 (UTC)
        • О каком резюме речь-то? -- D6194c-1cc (обс.) 15:46, 13 февраля 2021 (UTC)
          • Отучусь в школе, отучусь в университете, пойду устраиваться на работу, подам резюме YarTim (обсуждение, вклад) 15:49, 13 февраля 2021 (UTC)
            • Ещё в школе учитесь, получается? Рекомендую изучать программирование через написание какого-нибудь проекта, можно опен-сурс, потом в резюме этот проект указать. Работодателям нужен опыт в первую очередь, причём желательно совместной разработки, например, через git. -- D6194c-1cc (обс.) 16:29, 13 февраля 2021 (UTC)
  • Пытаюсь найти эту книжку в инете. YarTim (обсуждение, вклад) 14:30, 13 февраля 2021 (UTC)
    • Вот тут: [12], страница (самого pdf-ника) 453 YarTim (обсуждение, вклад) 14:43, 13 февраля 2021 (UTC)
• [13], нашёл вроде неплохой источник по обобщённому программированию. Python там не рассматривается, зато можно проследить суть методологии и есть сравнительная таблица по языкам. -- D6194c-1cc (обс.) 15:46, 13 февраля 2021 (UTC)
  • Если Python не рассматривается, то вряд ли можно использовать. Если будем сравнивать с "сутью" из источника, получится орисс YarTim (обсуждение, вклад) 15:54, 13 февраля 2021 (UTC)
    • Чтобы писать о поддержке той или иной концепции желательно понимать её суть, иначе из источников можно случайно перенести ошибки или что-то неправильно написать. Иногда приходится развивать смежные статьи, чтобы довести статью до качественного уровня. Чтобы до конца разобраться в статье про простуду, мне пришлось написать про ОРВИ и острый бронхит. -- D6194c-1cc (обс.) 16:29, 13 февраля 2021 (UTC)
  • [14], ещё общая информация по обобщённому программированию, теория, пригодится. -- D6194c-1cc (обс.) 17:03, 13 февраля 2021 (UTC)
• Добавил вводную, один источник использовал вне контекста python3, но в контексте динамической типизации и ООП, второй взял предложенный здесь на arxiv.org, вроде препринт, но информация тривиальная. Думаю, тема раскрыта. -- D6194c-1cc (обс.) 18:08, 13 февраля 2021 (UTC)

Python 3

Состояние Python 2 уже историческое, а в статье есть формулировки типа "реализация Python 3 для встроенных систем". Может просто Python, без числа? Думаю, читатели будут понимать, что речь идёт про третью версию. YarTim (обсуждение, вклад) 18:20, 13 февраля 2021 (UTC)

• Я бы использовал нумерацию там, где говорится о возможностях, которые между Python 2 и Python 3 отличаются. Что касается, MicroPython, то лучше оставить указание версии, если для 2-й части его реализации не существовало. Для общей информации, конечно, лучше просто Python. -- D6194c-1cc (обс.) 18:33, 13 февраля 2021 (UTC)
  • «Я бы использовал нумерацию там, где говорится о возможностях, которые между Python 2 и Python 3 отличаются.» — Вот тут поправлю себя, лучше явно версии указывать лишь там, где ведётся сравнение возможностей python2 и python3, а по умолчанию описывать python 3 без указания версии или уже с указанием конкретной версии, в которой функция появилась, например, «python 3.8». -- D6194c-1cc (обс.) 19:23, 13 февраля 2021 (UTC)
    • «На текущий момент активно развивается версия языка Python 3, версия Python 2 же поддерживается лишь для обеспечения работоспособности уже существующих проектов и не предназначена для использования в новых проектах» — точно соответствует настоящему моменту? Поддержка Python ведь закончилась ещё в апреле 2020. Может, просто в историю написать, что до этого момента долго была поддержка Python 2 была такого рода? YarTim (обсуждение, вклад) 20:16, 16 февраля 2021 (UTC)
      • Спасибо за замечание, раздел про историю я как раз ещё не читал. Разнёс информацию. Про окончание поддержки Python2 я оставил в преамбуле, думаю много таких же как я людей, которые ещё не в курсе об окончании срока поддержки. -- D6194c-1cc (обс.) 04:45, 17 февраля 2021 (UTC) D6194c-1cc (обс.) 04:45, 17 февраля 2021 (UTC) D6194c-1cc (обс.) 04:45, 17 февраля 2021 (UTC)

Парадигмы

@YarTim: А что Вы хотите описывать в разделе про структурное программирование? Общий контрол флоу уже начал описываться в синтаксисе и семантике. Если переносить его в раздел про структурное программирование, то будет странно, что часть возможностей описана в одном разделе, а часть в других. -- D6194c-1cc (обс.) 17:57, 17 февраля 2021 (UTC)

• Планирую сделать отдельный раздел, в котором расписывается по каждой парадигме. Найду какую-нибудь работу, рассказывающую про Python и про признаки структурного программирования в Python. Также как раздел про функциональное. YarTim (обсуждение, вклад) 18:02, 17 февраля 2021 (UTC)
  • Самое адеватное, что я пока нашёл, это вот: [15]. Только «[TO DO]» и «This document is» на последней странице что-то накладывают впечатление, что это какая-то незаконченная работа — в каком-то научном журнале или хорошей книге такого не должно быть YarTim (обсуждение, вклад) 18:10, 17 февраля 2021 (UTC)
    • Вот нашёл то, что прямо в точку: [16]
      Имено с точки зрения: «структурное программирование характеризуется организацией кода с помощью последовательного выполнения, ветвления и цикла, в python такое есть, примеры: раз, два, три»
      Поискав по сайту, нашёл, что это Университет Де Поля, а это некоторый документ с неких лекций на IT 211 зимой 2019 YarTim (обсуждение, вклад) 18:28, 17 февраля 2021 (UTC)
      • А ещё, у статьи нашей по 2-3 тысячи просмотров в день: [17] YarTim (обсуждение, вклад) 18:55, 17 февраля 2021 (UTC)
        • Если честно, у этой статьи самая скучная статистика — она плоская. Мне больше всего нравится наблюдать за другой статистикой: [18], [19]. Если Вы тоже любите статистику и находить взаимосвязи, то эти ссылки окажутся Вам очень интересными. По Википедии на самом деле можно даже исследования было бы писать, если бы она была доведена до качественного уровня и стала стабильной, ну собственно я в этом направлении работаю. -- D6194c-1cc (обс.) 18:25, 19 февраля 2021 (UTC)
          • Мы все в этом направлении работаем . Про Python, кстати, есть интересности, к примеру, пильчатость, связанная с днями недели (в субботу и воскресенье меньше чем по будням) и непонятно с чем связанный пик с октября по январь. YarTim (обсуждение, вклад) 19:16, 19 февраля 2021 (UTC)
            • Что интересно, такой пик есть и у других статей по программированию: [20] YarTim (обсуждение, вклад) 19:23, 19 февраля 2021 (UTC)
              • Я вообще имел в виду связь заболеваемости с работой учебных заведений, гипотеза сезонности вирусных инфекций из-за скученности людей. А Вы тут обнаружили парадокс 2020 года, вот это действительно удивительный резкий всплеск с чёткими границами. Интересно, конечно, что это было. Одно дело когда в Анафероне наблюдались резкие аномальные всплески посещаемости, которые можно связать с какой-нибудь рекламой, а тут — непонятно. -- D6194c-1cc (обс.) 20:15, 19 февраля 2021 (UTC)
                • Может, какой-то виток идеи удалёнки во время пандемии и всяких курсов типа «Python ЗА 21 ДЕНЬ»? YarTim (обсуждение, вклад) 20:25, 19 февраля 2021 (UTC)
            • А про пильчатость — да, тут у многих статей она наблюдается, на выходных интерес у людей ко многим темам пропадает, если это касается работы или учёбы, особенно сильно все статьи проседают в новогодние праздники. Одна статья правда по пильчатости уникальная — это про простуду, поскольку этот диагноз официально нигде не используется, там отсутствуют проседания на выходных, очень удобно сравнивать график с графиками других заболеваний и со статьями, которые популярны у студентов. -- D6194c-1cc (обс.) 04:24, 20 февраля 2021 (UTC)
  • Структурное программирование есть в любом популярном ЯП, его активно разбирали в 60-х-70-х годах, сейчас о нём нет смысла особо говорить. Тем более в статье про Python, где даже goto нет. Вот немного из старых времён: [21]. -- D6194c-1cc (обс.) 19:38, 17 февраля 2021 (UTC)
    • Ну, я не знаю. Ты имеешь в виду, что это слишком тривиально для того, чтобы описывать? Вроде бы есть такая парадигма, почему бы и не описать. YarTim (обсуждение, вклад) 19:42, 17 февраля 2021 (UTC)
      • Будьте добры на «Вы», пожалуйста, — сетевой этикет. Просто это незначимо в современном мире. Упомянуть можно одним или двумя предложениями, но не в виде отдельного раздела. -- D6194c-1cc (обс.) 19:57, 17 февраля 2021 (UTC)
        • Извиняюсь, иногда так соскакиваю. Моя задумка в том, что всё, что упомянуто в Python#Концепция_и_философия подробно расписать в отдельном разделе. Ну, если вот так подсократить, то нормально? YarTim (обсуждение, вклад) 20:09, 17 февраля 2021 (UTC)
          • Я бы структурное программирование и обобщённое расписал в корне раздела парадигм в рамках вводной. Отдельные разделы для них бессмысленны. А выделяющиеся, в том числе нетипичные, парадигмы уже можно по отдельным разделам расписывать. -- D6194c-1cc (обс.) 20:22, 17 февраля 2021 (UTC)
            • Как я понял Вашу задумку, про такого рода «засчитывающихся автоматом» парадигм написать про них в вводную раздела, а на важные выделять подразделы. Не лучше ли так: вверх в подразделах пусть будут самые важные парадигмы (ООП и функциональное), а неважные, выделить вместе в один подраздел «Остальные парадигмы»? YarTim (обсуждение, вклад) 20:40, 17 февраля 2021 (UTC)
              • Про остальные было первой идеей, которая мне пришла в голову. Мне кажется, что как вводная это лучше. В идеале можно описать там кратко все парадигмы в виде связного текста, а в отдельные разделах — уже более подробно, если информации много. -- D6194c-1cc (обс.) 04:31, 18 февраля 2021 (UTC)
                • Думаю, что лучше если сначала распишем раздел максимум, что могут дать АИ, потом переоформим. YarTim (обсуждение, вклад) 07:37, 19 февраля 2021 (UTC)

@YarTim: Хотел сказать Вам спасибо за выделение парадигм отдельно от возможностей. Это было грамотным решением. Мне идея понравилась, язык хорошо подходит для обучения, поэтому рассматривание различных парадигм в нём будет очень кстати (по сравнению с другими языками). -- D6194c-1cc (обс.) 11:17, 22 февраля 2021 (UTC)

АОП

Вот что пишет Рамальо: «В динамическом языке типа Python реализовать аспектно-ориентированное программирование гораздо проще, и существует несколько каркасов, в которых это сделано. Самым известным из них является каркас zope interface, который вкратце обсуждается в разделе „Дополнительная литература“ главы 11». Возможно, пригодится. Сейчас я пытаюсь понять, что такое декораторы. YarTim (обсуждение, вклад) 20:14, 21 февраля 2021 (UTC)

• Суть — функция, в которую в качестве аргумента передаётся декорируемая функция. Так можно подменять функцию, видоизменять её поведение или результат. Набросал пример, который облегчит понимание:

def print_decorator(function):
    def wrapper(text):
        print("<wrapped>")
        function(text)
        print("</wrapped>")
    return wrapper

@print_decorator
def print_function(text):
    print(text)

-- D6194c-1cc (обс.) 20:33, 21 февраля 2021 (UTC)

• По факту по вызову print_function("текст") будет вызвано print_decorator::wrapper("текст"). -- D6194c-1cc (обс.) 20:37, 21 февраля 2021 (UTC)
  • Я уже посмотрел в интернете и в документации... Всё равно спасибо. YarTim (обсуждение, вклад) 20:41, 21 февраля 2021 (UTC)
  • Что-то подумал, что мне нужно сам язык немного подтянуть. Пока могу быть неактивен. YarTim (обсуждение, вклад) 19:54, 23 февраля 2021 (UTC)
    • Да, конечно. Попутно скажите, в той книге про парадигмы много рассказывается? По теоретической части вообще много информации? Думаю, не прикупить ли её в свою коллекцию, всё-таки качественный источник на русском (хотя надо сказать, что такие книги быстро устаревают). -- D6194c-1cc (обс.) 04:45, 24 февраля 2021 (UTC)
      • Про парадигмы — скорее просто упоминаются, хотя некоторые упоминания могут в принципе помочь в работе над статьёй. Книга специализируется на некоторых не очень очевидных программистам штуках типа тех же декораторов. Насчёт степени устаревания — лично я не знаю. Книга 2015 года (оригинал), переведена в 2016. Сам автор писал, что на на момент написания книги самой последней версией была 3.4, а большинство программистов всё ещё писали на Python 2. На Гугл Букс можно бесплатно прочитать оглавление и предисловие. YarTim (обсуждение, вклад) 14:56, 24 февраля 2021 (UTC)
        • У Гугл Букса есть, кстати, хорошая особеннность: можно выполнять поиск не только по предпросмотровой части, но по всей книге: [22] YarTim (обсуждение, вклад) 15:00, 24 февраля 2021 (UTC)
        • Хотя насчёт того, что просто упоминается, неправильно сказал.
          Объектно-ориентированное — есть на ~50 страниц часть "Объектно-ориентированные идиомы"
          Функциональное — три страницы посвящены пакетам связанным с ФП, а также через сотню страниц есть хорошее замечание про нечистоту.
          Аспектно-ориентированное — тот фрагмент, что я скидывал, потом вкратце рассказ про этот zope interface
          Метапрограммирование — отдельная часть книги на ~100 страниц
          Вроде бы всё, что беглый поиск по книге дал YarTim (обсуждение, вклад) 15:27, 24 февраля 2021 (UTC)
          • Согласно WikiHistory, нам уже принадлежит по 10-15% текста, находящегося в статье. Замечают ли читатели, что мы дорабатываем статью? YarTim (обсуждение, вклад) 18:53, 28 февраля 2021 (UTC)
            • Какая разница сколько принадлежит? Такая информация вкупе со статистикой просмотров будет интересна разве что лишь новичками, которые пишут свою первую качественную статью, потом это уже становится рутиной. -- D6194c-1cc (обс.) 04:42, 1 марта 2021 (UTC)
              • Я имел ввиду прогресс, что мы уже переработали 20-30% текста YarTim (обсуждение, вклад) 07:22, 1 марта 2021 (UTC)
                • Если по этому критерию, то я в разделах считаю. Пока отражено всё основное в преамбуле (про метапрограммирование ещё добавлю) и вроде почти доработан до конца раздел про применение. -- D6194c-1cc (обс.) 17:23, 1 марта 2021 (UTC)
                  • Раздел про применение, кстати, можно разбить на пару-тройку подразделов, но я ещё не совсем понимаю, по какому критерию в таком случае лучше разделять. Поэтому пока буду полировать его периодически. -- D6194c-1cc (обс.) 18:07, 1 марта 2021 (UTC)
                    • @D6194c-1cc точно надо именно std::cout << "Hello, world!" << std::endl; а не в начале программы прописать using namespace std;? В учебниках везде через using namespace std;, чтобы каждый раз не писать std:: YarTim (обсуждение, вклад) 14:11, 4 марта 2021 (UTC)
                      • Для учебников можно, в реальной жизни это скорее плохая практика — подключать именно пространство имён std. Всегда есть шанс, что очередная библиотека каким-либо названием пересечётся с названием из std, это может произойти просто при начале использования новой библиотеки,пространство имён которой может быть более желательным, чем std. К тому же так мы явно говорим, что элемент из состава стандартной библиотеки, читабельность возрастает. Для часто используемых элементов можно использовать using, например, using std::cout. А сейчас извините, комментарии мне сейчас не особо хочется писать, учитывая, что сегодня ни с того, ни с сего был на шаг ближе к вот этому: [23], в ближайшее время предстоит названивать в разные места, чтобы обезопасить людей вокруг, а сейчас предпочитаю поуделять больше времени семье. -- D6194c-1cc (обс.) 18:38, 4 марта 2021 (UTC)
                      • Всё-таки забавные совпадения, когда утром звонит робот и предлагает бесплатное медицинское обследование, а вечером приходится идти в травм. пункт, ну да ладно. Можете про ABC перенести в раздел истории, здесь это не значимо. Сравнивать имеет смысл с популярными современными типовыми языками, то есть с C++, Java, Perl, Go. С Perl — потому как его как раз python должен был вытеснить будучи более удобным, а с Go — потому как это его прямой конкурент и в некоторых областях начал его теснить. -- D6194c-1cc (обс.) 11:30, 7 марта 2021 (UTC)
                        • Оговорился, не в раздел истории, а в статью про историю. -- D6194c-1cc (обс.) 11:31, 7 марта 2021 (UTC)
                          • Ага. Думаю, туда следет засунуть и Python#Языки,_которые_повлияли_на_Python. Логично, что и про ABC и про языки которые повлияли на Python источники будут первичные (ибо только сам Гвидо сможет сказать, откуда он брал идеи). А "История" будет базироваться именно на первичке. YarTim (обсуждение, вклад) 12:03, 7 марта 2021 (UTC)
                            • P.s. а Python#Языки,_на_которые_повлиял_Python не надо никуда переместить? YarTim (обсуждение, вклад) 12:37, 7 марта 2021 (UTC)
                              • Как мне кажется, это тоже история. Но эти разделы в идеале лучше по абзацу на каждый расписать по обобщающим вторичкам, если таковые найдутся, конечно. Даже если по первичкам, текст должен быть последовательный и связный, а не просто набор фактов. Пока можно было бы их в статью про историю перенести, а потом уже разбираться что к чему. А здесь написать с нуля. -- D6194c-1cc (обс.) 12:51, 7 марта 2021 (UTC)
                                • Такие «гуманитарные» вещи типа истории крайне поверхностно обсуждаются в вторичных источниках потому что всем интересна тема не того что когда-то там тридцать лет назад, а то, что можно сделать с помощью Python сейчас.
                                  Ещё, кстати, осложняет написание статьи, что Python будет первой статусной статьёй по языку программированию в рувики. То, что было избрано в 2005 не в счёт. По каким-то внутренним стандартам было бы легче писать. YarTim (обсуждение, вклад) 13:08, 7 марта 2021 (UTC)
                                  • И это при том, что РФ как раз славится хорошими программистами, мы можем делать потрясающие вещи, но не быстро. По стандартам, ну, из простого — истории минимум, всё в отдельную статью. Для учебных языков можно со стороны парадигм уделить внимание. Системные языки — со стороны безопасности и особенностей типа UB. Тут от конкретного языка всё зависит. Первую статью напишем, дальше видно будет. Кстати, Python важен тем, что может забустить подготовку новых специалистов и используется в том числе и в науке. А Си, например, важен тем, что в нём крайне легко допускать ошибки, но на нём традиционно писались наиболее серьёзные вещи (например, ОС Linux), то есть производительность, безопасность и уязвимости в том числе, впрочем в статье я когда-то застрял из-за того, что по неопытности не знал что делать с выносом некоторых разделов, статьи для которых уже были, но плохого качества, потом как-нибудь вернусь к доработке. -- D6194c-1cc (обс.) 14:32, 7 марта 2021 (UTC)
                                    • Дело в том, что большая часть «крутых программистов» в первую очередь — сугубо технари, и не очень в гуманитарную область. И те, кто увлекается программированием из Википедистов, в основном делают ботов или шаблоны. А я — полимат. И, судя по тому, что работаете программистом и увлекаетесь медициной, вы тоже . YarTim (обсуждение, вклад) 14:51, 7 марта 2021 (UTC)
          • По метапрограммированию есть хороший ресурс на ibm.com: [24]. Надо сказать, что отсюда я узнал про механизм переопределения метакласса, раньше не задумывался о том, как в Python работают абстрактные классы через ABCMeta. -- D6194c-1cc (обс.) 04:42, 1 марта 2021 (UTC)

• Впервые вижу перевод «framework» как каркаса, вроде обычно как фреймворк и переводят. Перевод в книге, возможно, не лучший. -- D6194c-1cc (обс.) 20:55, 21 февраля 2021 (UTC)

Содержание статьи

Так, краткий план, что надо бы сделать
0 Преамбула В приличном состоянии
1 История Дополнить, найти источники
2 Название языка Найти источник, что лого ассоциируется с змеёй
3 Концепция и философия В приличном состоянии
4 Портируемость Дополнить, поискать источники
5 Типы и структуры данных Дополнить, поискать источники. Стоит заметить, что таблица, вроде бы, неполная. Надо дополнить из документации
6 Синтаксис и семантика Переписать, поискать источники
7 Парадигмы Дополнить, поискать источники по тому, что не описано
7.1 Объектно-ориентированное программирование Дополнить, поискать источники
7.2 Обобщённое программирование В приличном состоянии
7.3 Функциональное программирование В приличном состоянии
7.4 Структурное программирование Дополнить, поискать источники
8 Возможности Переписать, поискать источники
9 Библиотеки Дополнить, поискать источники
10 Примеры программ Думаю, если мы доведём статью до идеального состояния, раздел не понадобится, ибо достаточно примеров будет в соответствующих разделах
11 Профилирование и оптимизация кода Поискать источники
12 Сравнение с другими языками Дополнить, поискать источники
13 Критика В приличном состоянии, хотя на отдельные утверждения надо добавить источники
14 Реализации Дополнить, поискать источники
15 Специализированные подмножества/расширения Python Дополнить, поискать источники
16 Инструменты поддержки программирования Дополнить, поискать источники
17 Применение В приличном состоянии

YarTim (обсуждение, вклад) 20:00, 1 марта 2021 (UTC)

Ссылки

На завтра, чтобы не забыть, про сравнение c++ java и python:
https://oaktrust.library.tamu.edu/handle/1969.1/ETD-TAMU-1997-THESIS-Z46
https://www.cs.tufts.edu/~nr/cs257/archive/lutz-prechelt/comparison.pdf
https://www.nsl.com/papers/phone/jccpprtTR.pdf
https://www.researchgate.net/profile/Giuseppe-Destefanis-2/publication/295918668_A_Statistical_Comparison_of_Java_and_Python_Software_Metric_Properties/links/59e85534458515c3630ff910/A-Statistical-Comparison-of-Java-and-Python-Software-Metric-Properties.pdf
https://ieeexplore.ieee.org/abstract/document/7126267
https://www.researchgate.net/profile/Muhammad-Ateeq-2/publication/271425337_C_or_Python_Which_One_to_Begin_with_A_Learner%27s_Perspective/links/551c68fc0cf20d5fbde5404e/C-or-Python-Which-One-to-Begin-with-A-Learners-Perspective.pdf
https://iopscience.iop.org/article/10.1088/1742-6596/423/1/012027/pdf YarTim (обсуждение, вклад) 20:37, 1 марта 2021 (UTC)

• Куча интервью с Гвидо:

https://www.python.org/doc/essays/foreword/
https://docs.python.org/3/faq/general.html#why-was-python-created-in-the-first-place
https://web.archive.org/web/20081229095320/http://www.computerworld.com.au/index.php/id%3B66665771
https://web.archive.org/web/20090302001051/http://www.computerworld.com.au/article/255835/-z_programming_languages_python?pp=2
https://web.archive.org/web/20081016011216/http://www.computerworld.com.au/index.php/id;66665771;pp;3
https://web.archive.org/web/20081016011222/http://www.computerworld.com.au/index.php/id;66665771;pp;4
https://web.archive.org/web/20081016011226/http://www.computerworld.com.au/index.php/id;66665771;pp;5
https://web.archive.org/web/20120415101527/http://onlamp.com/lpt/a/2431
https://www.artima.com/intv/python.html
https://www.artima.com/intv/pyscale.html
https://www.artima.com/intv/speed.html
https://www.artima.com/intv/pycontract.html
https://www.artima.com/intv/strongweak.html
https://www.artima.com/intv/pycomm.html
— YarTim (обсуждение, вклад) 19:09, 3 марта 2021 (UTC)

Понимание vs опыт

Структура изложения

1. Коллега @D6194c-1cc, вы комментарием [25] противоречите источнику, в котором нет противопоставления - Programs in these languages generally contained more lines of code. Я поправил в статье, а вы удалили - верните обратно или перепешите как в источнике с "." между предложениями.— Saramag (обс.) 06:41, 21 марта 2021 (UTC)

• Каков будет ваш ответ по этому замечанию? [26] Saramag (обс.) 06:47, 21 марта 2021 (UTC)
  • В статье в ВП уже есть упоминание "Python сравнивается с C++/Java с точки зрения лаконичности, простоты". Получается, что идёт дублирование данных про "многокодость" С. Выбирайте, что из двух оставляем. Saramag (обс.) 07:32, 21 марта 2021 (UTC)
    • Это вводная, дальше идёт расшифровка. Здесь ещё не говорится, что лучше, а что хуже. -- D6194c-1cc (обс.) 08:13, 21 марта 2021 (UTC)
      • Это раздел в энциклопедии, а не вводная часть исследования - обобщающие слова идут в преамбуле. Saramag (обс.) 08:20, 21 марта 2021 (UTC)
        • Это энциклопедия и обычный русский язык, изложение материала. Одно и то же можно написать по разному, в данном случае получились сначала ключевые моменты, по каким критериям сравнивают, а дальше детали, сравнение и всё остальное. Текст в будущем может измениться, но сейчас, думаю, это неважно. не вижу здесь поводов для каких-либо споров вообще. -- D6194c-1cc (обс.) 12:28, 21 марта 2021 (UTC)
          • Вы сами подтверждаете, что произвели группировку общих выводов с последующим их разъяснением - так пишутся научные работы. У нас идёт последовательная передача фактов. Сгруппированные выводы присутствуют в преамбуле. Saramag (обс.) 08:38, 22 марта 2021 (UTC)
  • Противопоставление же вполне логично, оно указывает на вполне очевидные достоинства и недостатки языков. Ставить точку в предложении только потому, что так в источнике — это уже доведение до абсурда, не более. -- D6194c-1cc (обс.) 08:13, 21 марта 2021 (UTC)
    • "на вполне очевидные достоинства и недостатки языков" то, что в Питоне можно сделать за одну строку вместо 30 на С++ - называется скорость разработки. Вы меня обвиняете в ВП:НДА? Про точку - структура АИ напрямую влияет на отображение текста (данное правило было принято как раз в таких случаях). Saramag (обс.) 08:19, 21 марта 2021 (UTC)
      • Спасибо коллеге [27] - на мой взгляд вопрос решён.— Saramag (обс.) 09:17, 21 марта 2021 (UTC)

Сложность СИ

2. The use of pointers in C and C++ can be overwhelming for a learner, and it may take some time to master their use. [28]
Согласитесь, что мой перевод боле корректен и правая часть утверждения вытекает из левой, то есть по сути являются равнозначными. Верните мою правку и перестаньте, пожалуйста, везде добавлять превосходительную форму "крайне, значительно" (если уж хотите добавить перевод "overwhelming", то задумайтесь над тем, что это не следует научному стилю). Saramag (обс.) 06:29, 21 марта 2021 (UTC)

• Да, там именно слово «master» в форме глагола. И да, у меня пересказ, а не перевод, прямой перевод запрещён правилами, его необходимо хоть немного, да видоизменить. Источнику соответствует, действительности тоже. Неновички тоже мало что знают про выравнивания или про паддинги, к примеру. У Вас замечания на пустом месте, Вам не кажется? -- D6194c-1cc (обс.) 06:39, 21 марта 2021 (UTC)
  • Не переходите на мою личность или мотивы - ВП:ЭП. Пересказ не должен менять суть - дескрипторы это сложная тема для начинающих программистов, а не что-то недосягаемое. В конце-концов - это статья не о С++ , поэтому в целом замечание в стиле его недостатков без сравнения с Пайтоном неуместно. Saramag (обс.) 06:51, 21 марта 2021 (UTC)
    • Какие ещё дескрипторы? Под дескрипторами обычно понимают файловые дескрипторы, это не в тему. По остальному, там сравнение трёх языков, Java там фигурирует именно в контексте сравнения с Python и C++. -- D6194c-1cc (обс.) 07:23, 21 марта 2021 (UTC)
      • [29] дескрипторы (не рекомендую вам их использовать при работе с файлами), [30] указатели. А Ява здесь причём, если обсуждаем С++? (Если вы про то, что это похожие языки и их можно сопоставлять вместе - то я не согласен) ", но является крайне сложным для понимания среди новичков, а для овладения навыками правильного использования указателей может потребоваться очень много времени" можно сократить до "но считается сложным для понимания начинающих программистов". Saramag (обс.) 08:07, 21 марта 2021 (UTC)

В общем я отменяю вашу правку по ВП:КММ, так как консенсуса достичь не получилось.— Saramag (обс.) 08:50, 22 марта 2021 (UTC)

• А теперь объясните всё-таки, почему Вы именно удаляете этот кусов текста: «Использование указателей в C++ позволяет эффективно работать с памятью, но является крайне сложным для понимания среди новичков, а для овладения навыками правильного использования указателей может потребоваться очень много времени». Это часть сравнения по части работы с памятью с Python. Написано верно, написано по источнику, именно пересказ своими словами. Даёт представление о разнице между простыми языками и системными (Си, на котором основан C++ - это всё-таки надассемблер. можно сказать). Без этого куска изложение материала получается неполным. -- D6194c-1cc (обс.) 18:11, 23 марта 2021 (UTC)
  • Ещё раз вам напомню, что не я должен вас убеждать в некорректности ваших правок, а вы мне доказывать их правильность.
    1. Откуда вы взяли утверждение, что "позволяет эффективно работать с памятью"? В этом источнике его нет.
    2. Почему использовали превосходительные формы "крайне", "очень много"?
    3. Правильно понимаю, что моё предложение о выборе одного из типов указаний на сложность вы не хотите вносить в статью? Saramag (обс.) 18:36, 23 марта 2021 (UTC)
    • Давайте-ка я (YarTim) попробую разобраться в чём спор идёт. YarTim (обсуждение, вклад) 18:43, 23 марта 2021 (UTC)
      • Оригинальная фраза из источника:
        «The use of pointers in C and C++ can be overwhelming for a learner, and it may take some time to master their use»
        Буквальный перевод:
        «Использование указателей в Си и C++ может быть сложным (подавляющим, непреодолимым — overwhelming) для новичка, и может потребоваться некоторое время, чтобы освоить их использование»
        То, что предлагается в статью:
        «Использование указателей в C++ позволяет эффективно работать с памятью, но является крайне сложным для понимания среди новичков, а для овладения навыками правильного использования указателей может потребоваться очень много времени» YarTim (обсуждение, вклад) 18:49, 23 марта 2021 (UTC)
        • Мой вариант, который можно было бы оставить в статье:
          «Использование указателей в C++ может быть сложным для понимания среди новичков, и овладение навыками правильного использования указателей может занять некоторое время обучения.»
          По-факту то, что "позволяет эффективно работать с памятью" заменено ссылкой на статью Указатель (тип данных), ведь в той статье сказано это самое и даже больше. Плюс немного менее сочные эпитеты, более-менее соответствующие источнику. YarTim (обсуждение, вклад) 19:07, 23 марта 2021 (UTC)
          • Saramag, D6194c-1cc, вас в принципе устраивает такой вариант? YarTim (обсуждение, вклад) 19:10, 23 марта 2021 (UTC)
            • Да, норм. Saramag (обс.) 19:12, 23 марта 2021 (UTC)
            • Ну, раз предложили, добавите сами Ваш вариант в статью? Но под overwhelming подразумевалось всё-таки «непосильным». -- D6194c-1cc (обс.) 18:33, 25 марта 2021 (UTC)
              • И в конце слово «обучения», думаю, лишнее. -- D6194c-1cc (обс.) 18:34, 25 марта 2021 (UTC)
                • Тогда "довольно сложным" и без "обучения". Перегруза смыслового значения, думаю не будет. YarTim (обсуждение, вклад) 19:55, 25 марта 2021 (UTC)
    • А я Вам напомню о НДА. Вы могли убрать информацию, которая, на Ваш взгляд, отсутствует в источнике, переформулировать её без потери смысла, но Вы удалили целиком весь текст, вместе со значимой информацией. В случаях вандализма это было бы оправданным, но сейчас не такой случай. Первый пункт я бы всё-таки отнёс к общеизвестным фактам или Вам нужен даже на такие тривиальные сведения источник? По второму, не буду возражать на замену на "очень", если того потребует компромиссное решение. По третьему пункту, не совсем понял, до сих пор Вы убирали информацию, а не пытались её корректировать. -- D6194c-1cc (обс.) 18:46, 23 марта 2021 (UTC)
      • "переформулировать её без потери смысла" - вот я пытался внести альтернативный вариант, но вы его отменили [31]. Saramag (обс.) 19:12, 23 марта 2021 (UTC)

Рабочий код

• • • • • «Поскольку собственные указатели C++ (*) и ссылки (&) не являются управляемыми ссылками, сборщик мусора не может автоматически обновлять их адреса. Для решения этой проблемы используйте декларатор дескриптора, чтобы задать переменную, которую сборщик мусора будет учитывать и обновлять автоматически.»

Хоть описывают и схожие понятия, но в корне отличаются. К дескриптору Вы не прибавите смещение, чтобы получить доступ к полю. И не добавите перед указателем область с описанием RTTI. Есть очень много нестандартных применений указателей, а есть очень много сюрпризов. Вот например, сможете сказать, этот код корректный или нет?

int a[5];
int *a_end = a + 5;
// инициализация a
for(int *n_ptr = a_end - 1; n_ptr >= a; --n_ptr) { std::cout << *n_ptr << std::endl; }

Код должен быть абсолютно рабочий (но не проверял), в теории должен отработаться на всех компиляторах. Но он правильный? Просто вывод всех чисел в обратном порядке, но через указатели. -- D6194c-1cc (обс.) 12:44, 21 марта 2021 (UTC)

• Погонял по компиляторам.
  Visual Studio:
  
-858993460
-858993460
-858993460
-858993460
-858993460

  Первый попавшийся онлайн-компилятор:
  
-797305568
0
4196160
0
4196576

  Второй попавшийся онлайн-компилятор:
  
1
0
4196925
0
6294528

  Что-то не то? YarTim (обсуждение, вклад) 19:07, 21 марта 2021 (UTC)

• Всё так, только проинициализировать забыли как-нибудь. Я же говорил, это должно работать на практике. Вопрос был в самом коде, всё ли там корректно написано? Пытаться исполнять тут что-либо бессмысленно. -- D6194c-1cc (обс.) 04:59, 22 марта 2021 (UTC)
  • Изначально надо было заполнить массив от 1 до 5? Сейчас проверю. YarTim (обсуждение, вклад) 07:54, 22 марта 2021 (UTC)
    • Теперь нормально выводит от 5 до 1. YarTim (обсуждение, вклад) 08:00, 22 марта 2021 (UTC)
      • Вопрос не в этом, код корректный или нет? На вопрос так никто и не ответил. -- D6194c-1cc (обс.) 18:20, 22 марта 2021 (UTC)
        • корректный... YarTim (обсуждение, вклад) 08:24, 23 марта 2021 (UTC)
          • Рабочий, но не корректный. Мало кто знает такие нюансы, когда я начинал, тоже не знал. В этом и проблема указателей в Си, для правильной работы с ними необходимо прочитать стандарт, мало кто его читал целиком и полностью. К счастью ключевые моменты есть в CERT. Увы, прямой цикл можно таким образом делать, а обратный - undefined behavior ([32]). за пределами массива можно сравнивать лишь с элементом, следующим за последним. В моём примере в последней итерации происходит сравнение с указателем, который выходит за пределы массива (стоит до него), возможна гипотетическая ситуация, когда результат сравнения будет обратным. На практике такая ситуация, наверное, нереальна, но так писать не стоит. Как минимум это будет проблемой со статическими анализаторами или какими-нибудь опциями компиляции, выдающими ошибки для всего вообще. Да и ASAN тот же может скрешить приложение на этом месте. -- D6194c-1cc (обс.) 17:29, 23 марта 2021 (UTC)
            • Хотя насчёт ASAN я погорячился, он не скрешит, он срабатывает только на разыменовывания, насколько помню. -- D6194c-1cc (обс.) 17:37, 23 марта 2021 (UTC)
              • Значит вот так вот... YarTim (обсуждение, вклад) 18:42, 23 марта 2021 (UTC)
                • Да, в системном программировании всё неоднозначно. А насчёт разыменовывания, подразумевался доступ на чтение или на запись. Как обычно сначала написал, потом подумал. -- D6194c-1cc (обс.) 18:52, 23 марта 2021 (UTC)

• • • «У Вас замечания на пустом месте, Вам не кажется?» Ладно, поясню, вся информация подкреплена источниками, я подходил ответственно, обладаю достаточными знаниями и опытом для интерпретации текста по данной тематике. В статье море информации без источников, наверняка есть ошибочная, как было в случае с Ruby. Но Вы анализируете именно то, что я вносил и очень странно это аргументируете, естественно, мне непонятна Ваша позиция в данном случае, лучше качество статьи это не делает, а мою работу замедляет необходимостью излишних обсуждений. -- D6194c-1cc (обс.) 07:30, 21 марта 2021 (UTC)
      • Вы можете не отвлекаться на обсуждения, а принимать мои корректирующие правки. Saramag (обс.) 07:33, 21 марта 2021 (UTC)
        • Корректирующие принимаю, ошибочные — нет. -- D6194c-1cc (обс.) 07:58, 21 марта 2021 (UTC)
• Ну и варианты перевода and, раз уж заговорили про английский язык: [33]. Всё зависит от контекста употребления. -- D6194c-1cc (обс.) 06:42, 21 марта 2021 (UTC)
• Думаю, "при этом" — компромисс между "и" и "но" YarTim (обсуждение, вклад) 09:15, 21 марта 2021 (UTC)

Python#Реализации и Python#Портируемость

Связаны ли логически эти два раздела? Может, слить? YarTim (обсуждение, вклад) 12:04, 24 марта 2021 (UTC)

• Да, я тоже уже к ним приглядывался. И то, и другое про реализации рассказывает. Нужно будет объединять. Ну и список превратить в связный текст. Про PyPy можно отдельным подразделом рассказать. -- D6194c-1cc (обс.) 18:25, 25 марта 2021 (UTC)
  • Думаю, из Википедии придется перенести список в Викиучебник. Дело в том, что по-хорошему надо писать раздел по вторичным источникам, они в принципе будут для CPython, PyPy, Jython и некоторым прочим, но будут ли они для условных «чтобы и на калькуляторе работало», в особенности, если учесть, что большая часть из них делается любителями? Я думаю, выход в том, чтобы в статье расписать только основные и сделать в начале раздела сделать примечание что «В разделе рассматриваются основные реализации Python. См. также список реализаций в Викиучебнике». Возможный недостаток в том, что за тем списком возможно никто не будет следить. YarTim (обсуждение, вклад) 12:46, 26 марта 2021 (UTC)
    • Интересная идея. Список так или иначе будет вычищаться из этой стати. По разделам будут описаны Jython и IronPython, т. к. значимы. Часть остальных - вкратце по вторичкам, если таковые найдутся. -- D6194c-1cc (обс.) 16:47, 26 марта 2021 (UTC)
      • Перенести в Викиучебник можно, а так в ВП ещё одна статья появится (надо тока АИ общий поискать). Saramag (обс.) 06:50, 27 марта 2021 (UTC)
        • Возможно будет как раз-таки проблема с обобщающим АИ. Интуиция подсказывает, что обобщающего источника нету. А если есть, то рассматривается максимум несколько основных. И не будут включать какие-нибудь любительские на калькуляторы. YarTim (обсуждение, вклад) 07:11, 27 марта 2021 (UTC)
          • А нам не обязательно, чтобы все были указаны в одном АИ - вот вроде достаточно и этого [34]. Если другой погуглить надо - напишите. Saramag (обс.) 11:09, 27 марта 2021 (UTC)
            • Ага, спасибо. YarTim (обсуждение, вклад) 13:29, 27 марта 2021 (UTC)

Оформление списков

@YarTim: Ваши правки не соответствуют правилам русского языка. Точки с запятой ставятся в том случае, если элементы списка являются сложными предложениями и начинаются со строчной буквы: [35]. В данным случаях должна быть точка, раньше было правильно. -- D6194c-1cc (обс.) 20:30, 25 марта 2021 (UTC)

• Ага, учту. YarTim (обсуждение, вклад) 07:05, 26 марта 2021 (UTC)
• Может Реализации в отдельный список-статью вынести? Saramag (обс.) 20:41, 26 марта 2021 (UTC)
  • Тема ровно выше. Я предложил в Викиучебник. YarTim (обсуждение, вклад) 06:08, 27 марта 2021 (UTC)

Излишние сноски

@YarTim: Я думаю, излишне указывать ссылки на оф. сайты в сносках после названий интерпретаторов. Есть интервики-ссылки, по ним можно узнать оф. сайты. Сноски лучше использовать для подтверждения информации. В некоторых случаях я также использовал для ссылок на соответствующую документацию, но это также спорный момент. -- D6194c-1cc (обс.) 19:30, 29 марта 2021 (UTC)

• Убрал YarTim (обсуждение, вклад) 19:54, 29 марта 2021 (UTC)

Актуальность источников

Что насчёт актуальности и давности источников? Есть ли какие-то психологические барьеры актуальности? К примеру, я нашёл цельную книжку под CC по Jython, но она 2010 года. YarTim (обсуждение, вклад) 12:26, 30 марта 2021 (UTC)

• Давайте ссылку - посмотрим вместе) (В целом срок источника не важен, но конечно может быть обсужден при описании изменившихся со временем парадигм). Я бы в старых книгах уточнял версию Питона, для которой написана та или иная информация (кроме общей истории языка). И по версии лицензии лучше лишний раз проверить правильность атрибуции. Saramag (обс.) 12:35, 30 марта 2021 (UTC)
  • [36] [37]. Нашёл ещё вот что [38] [39], но последняя не под CC YarTim (обсуждение, вклад) 12:43, 30 марта 2021 (UTC)
    • В первой указан http://creativecommons.org/licenses/by-sa/3.0/ - можно использовать прям дословным цитированием с указанием ссылки на книгу (чтобы при проверке на копивио не было вопросов). Вторая книга лично мне не нравится по началу "A long time ago, in a galaxy far, far away...
      Okay, maybe not so long ago, unless you are thinking in terms of “web years.", наверное стоит посмотреть более подробно авторитетность издательства, автора. Saramag (обс.) 12:55, 30 марта 2021 (UTC)
      • всяких шутников лучше не использовать. Лучше первую. Цельная книжка, её не хватит? YarTim (обсуждение, вклад) 13:04, 30 марта 2021 (UTC)
        • Я вопроса не понял про "цельная" и на что её не хватит. Можете перефразировать? Saramag (обс.) 13:05, 30 марта 2021 (UTC)
          • Лучше не использовать вторую книжку, а только первую. Или ещё что-нибудь, если найдётся YarTim (обсуждение, вклад) 13:08, 30 марта 2021 (UTC)

Применение

Набросал пометки, отметил ложное покрытие источниками. Имхо, надо писать что-то вроде "Intel, Google, NASA и Facebook используют Python, т.к. Python хорош как скриптовый язык", может можно упомянуть про использование в важных программах типа Блендера. Только там ещё были какие-то неизвестные программы, которые я пометил. Их сносить? Можно руководствоваться в принципе, [40] просмотрами статей о каких-то программах. YarTim (обсуждение, вклад) 19:33, 30 марта 2021 (UTC)

• Я бы вообще убрал заметки "написан на", кроме ситуаций с упоминанием особенностей языка, раскрывающем объект статьи. Например, "Google начал спонсировать разработку языка с 2010 года"[41]... "11 февраля 2011 года Google спонсировали 350 тыс. долларов на поддержание критически важной системы PyPI" [42] [43] (хотя про систему пакетов есть отдельная статья - просто пример для этой). Saramag (обс.) 02:31, 31 марта 2021 (UTC)
  • Доп. аргумент - пробовали создать статью Список программного обеспечения, написанного на языке программирования Python, но он оказался незначим (значит скорее всего перечисление написанного софта не имеет места в принципе). Вот список, кстати, Проект:Информационные технологии/Списки/Список программного обеспечения, написанного на языке программирования Python. Saramag (обс.) 02:33, 31 марта 2021 (UTC)
    • Вычистил всякое то, что показалось незначимым. Ничего лишнего не удалил? YarTim (обсуждение, вклад) 09:41, 31 марта 2021 (UTC)
      • Python используется в системах сборки проектов, что обусловлено отсутствием необходимости предварительной компиляции исходных файлов, например в проекте Google Test он используется для генерации исходного кода mock-объектов для классов языка C++".
        Поищу АИ понезависимее (немного модифицировал текст из статьи). Saramag (обс.) 10:21, 31 марта 2021 (UTC)
        • В том источнике нету то, что используется хорошая особенность отсутствия предкомпиляции. YarTim (обсуждение, вклад) 11:07, 31 марта 2021 (UTC)
      • Удалили очень значимое и по АИ - про научные вычисления. Я верну. -- D6194c-1cc (обс.) 16:26, 31 марта 2021 (UTC)
• А зачем убирать пояснение о том, что Reddit — социальная сеть? Не все знают, что это такое, такие уточнения лишними не будут, информацию легче воспринимать. -- D6194c-1cc (обс.) 16:39, 31 марта 2021 (UTC)
  • Ну, я знаю. YarTim (обсуждение, вклад) 17:18, 31 марта 2021 (UTC)
• А никому не кажется, что после удаления кучи субъективно незначимой информации связность текста в разделе про применение упала до очень низкого качества? -- D6194c-1cc (обс.) 17:30, 1 апреля 2021 (UTC)
  • Тогда обсудим поподробнее. YarTim (обсуждение, вклад) 17:34, 1 апреля 2021 (UTC)
    • Задумка была такой, что идёт сфера применения, а к ней примеры, один - два. То есть раскрываем тему по реальным проектам. Примеры нужны, при этом некоторые являются весьма специфичными. Если убирать примеры как незначимые, то мы просто уменьшаем качества раздела. -- D6194c-1cc (обс.) 17:40, 1 апреля 2021 (UTC)
      • Лучше подумать. Лучше пока не будем трогать раздел. YarTim (обсуждение, вклад) 17:48, 1 апреля 2021 (UTC)
        • О чём думать? Предложение коллеги D6194c-1cc правильное. Нужно определится с АИ и по нему написать. Saramag (обс.) 18:52, 1 апреля 2021 (UTC)
          • Не получится найти АИ, где будет подробно описано именно применение с разными примерами. Я пробовал. -- D6194c-1cc (обс.) 18:57, 1 апреля 2021 (UTC)
            • Ну, я думаю, оставим то, что есть. Только, надо бы определиться с несколькими не очень известными программками YarTim (обсуждение, вклад) 19:13, 1 апреля 2021 (UTC)
              • Что-то заметил, что начал немного общаться с трудом. Олимпиадное программирование — очень мозгосносная тема. Пытаюсь понять алгоритм A* для задачки, и ничего не могу понять. Потом приходит озарение, как сделать по-своему, а потом оказывается, что получился, в принципе, этот же алгоритм. Сумрачный гений, блин. А ещё, в олимпиадах по программированию математики больше, чем в олимпиадах по математике. YarTim (обсуждение, вклад) 19:32, 1 апреля 2021 (UTC)

Сносить?

По большей части на Python написана также графическая программа Veusz (англ.)русск.[183], позволяющая создавать качественные графики, готовые для размещения в научных публикациях[184][значимость факта?] YarTim (обсуждение, вклад) 19:17, 1 апреля 2021 (UTC)

Библиотека Astropy — популярный инструмент для астрономических расчётов[185][значимость факта?]. YarTim (обсуждение, вклад) 19:17, 1 апреля 2021 (UTC)

Так, движок свободного видеоредактора OpenShot реализован в виде библиотеки libopenshot, написанной на C++ с использованием библиотек на Си, а все возможности полностью покрыты прикладным интерфейсом программирования Python[178][значимость факта?]. YarTim (обсуждение, вклад) 19:17, 1 апреля 2021 (UTC)

Также Python подходит для выполнения нестандартных или сложных задач в системах сборки проектов, что обусловлено отсутствием необходимости предварительной компиляции исходных файлов. В проекте Google Test он используется для генерации исходного кода mock-объектов для классов языка C++[186][значимость факта?]. YarTim (обсуждение, вклад) 19:17, 1 апреля 2021 (UTC)

• Нужно некое частное употребление? YarTim (обсуждение, вклад) 19:17, 1 апреля 2021 (UTC)
  • Про Veusz - хороший пример, поскольку также позволяет делать графики для научных публикаций, очень подходит к предыдущей информации. А Astropy - узкоспециализированное ПО, но популярное в своей сфере. Пара примеров, которые дополняют область научного использования, почему, собственно, нет? -- D6194c-1cc (обс.) 19:31, 1 апреля 2021 (UTC)

Думаю, какие-то ссылки на никомунеизвестные программы лучше снести. Хотя бы это. Источники на некоторые утверждения, помеченные [источник?] можно в принципе найти. YarTim (обсуждение, вклад) 19:17, 1 апреля 2021 (UTC)