Обсуждение:Python/Архив/2021

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

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

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

Чушь в статье[править код]

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

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

Источники[править код]

Посмотрел Гугл Школяр. А там больше миллиона статей. Конечно, часть из них не о нашей теме, часть первоисточники, часть по слишком узким темам (типа машинного обучения и распознавания голоса). Но количество радует. 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++-код ([1]). А как Вы по этому источнику писали вообще, если там другое сказано? -- 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)[ответить]

@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)[ответить]
  • [4], нашёл вроде неплохой источник по обобщённому программированию. Python там не рассматривается, зато можно проследить суть методологии и есть сравнительная таблица по языкам. -- D6194c-1cc (обс.) 15:46, 13 февраля 2021 (UTC)[ответить]
    • Если Python не рассматривается, то вряд ли можно использовать. Если будем сравнивать с "сутью" из источника, получится орисс YarTim (обсуждение, вклад) 15:54, 13 февраля 2021 (UTC)[ответить]
      • Чтобы писать о поддержке той или иной концепции желательно понимать её суть, иначе из источников можно случайно перенести ошибки или что-то неправильно написать. Иногда приходится развивать смежные статьи, чтобы довести статью до качественного уровня. Чтобы до конца разобраться в статье про простуду, мне пришлось написать про ОРВИ и острый бронхит. -- D6194c-1cc (обс.) 16:29, 13 февраля 2021 (UTC)[ответить]
    • [5], ещё общая информация по обобщённому программированию, теория, пригодится. -- D6194c-1cc (обс.) 17:03, 13 февраля 2021 (UTC)[ответить]
  • Добавил вводную, один источник использовал вне контекста python3, но в контексте динамической типизации и ООП, второй взял предложенный здесь на arxiv.org, вроде препринт, но информация тривиальная. Думаю, тема раскрыта. -- D6194c-1cc (обс.) 18:08, 13 февраля 2021 (UTC)[ответить]

Состояние 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)[ответить]
    • Самое адеватное, что я пока нашёл, это вот: [6]. Только «[TO DO]» и «This document is» на последней странице что-то накладывают впечатление, что это какая-то незаконченная работа — в каком-то научном журнале или хорошей книге такого не должно быть YarTim (обсуждение, вклад) 18:10, 17 февраля 2021 (UTC)[ответить]
      • Вот нашёл то, что прямо в точку: [7]
        Имено с точки зрения: «структурное программирование характеризуется организацией кода с помощью последовательного выполнения, ветвления и цикла, в python такое есть, примеры: раз, два, три»
        Поискав по сайту, нашёл, что это Университет Де Поля, а это некоторый документ с неких лекций на IT 211 зимой 2019 YarTim (обсуждение, вклад) 18:28, 17 февраля 2021 (UTC)[ответить]
        • А ещё, у статьи нашей по 2-3 тысячи просмотров в день: [8] YarTim (обсуждение, вклад) 18:55, 17 февраля 2021 (UTC)[ответить]
          • Если честно, у этой статьи самая скучная статистика — она плоская. Мне больше всего нравится наблюдать за другой статистикой: [9], [10]. Если Вы тоже любите статистику и находить взаимосвязи, то эти ссылки окажутся Вам очень интересными. По Википедии на самом деле можно даже исследования было бы писать, если бы она была доведена до качественного уровня и стала стабильной, ну собственно я в этом направлении работаю. -- D6194c-1cc (обс.) 18:25, 19 февраля 2021 (UTC)[ответить]
            • Мы все в этом направлении работаем :-). Про Python, кстати, есть интересности, к примеру, пильчатость, связанная с днями недели (в субботу и воскресенье меньше чем по будням) и непонятно с чем связанный пик с октября по январь. YarTim (обсуждение, вклад) 19:16, 19 февраля 2021 (UTC)[ответить]
              • Что интересно, такой пик есть и у других статей по программированию: [11] YarTim (обсуждение, вклад) 19:23, 19 февраля 2021 (UTC)[ответить]
                • Я вообще имел в виду связь заболеваемости с работой учебных заведений, гипотеза сезонности вирусных инфекций из-за скученности людей. А Вы тут обнаружили парадокс 2020 года, вот это действительно удивительный резкий всплеск с чёткими границами. Интересно, конечно, что это было. Одно дело когда в Анафероне наблюдались резкие аномальные всплески посещаемости, которые можно связать с какой-нибудь рекламой, а тут — непонятно. -- D6194c-1cc (обс.) 20:15, 19 февраля 2021 (UTC)[ответить]
              • А про пильчатость — да, тут у многих статей она наблюдается, на выходных интерес у людей ко многим темам пропадает, если это касается работы или учёбы, особенно сильно все статьи проседают в новогодние праздники. Одна статья правда по пильчатости уникальная — это про простуду, поскольку этот диагноз официально нигде не используется, там отсутствуют проседания на выходных, очень удобно сравнивать график с графиками других заболеваний и со статьями, которые популярны у студентов. -- D6194c-1cc (обс.) 04:24, 20 февраля 2021 (UTC)[ответить]
    • Структурное программирование есть в любом популярном ЯП, его активно разбирали в 60-х-70-х годах, сейчас о нём нет смысла особо говорить. Тем более в статье про Python, где даже goto нет. Вот немного из старых времён: [12]. -- 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: Хотел сказать Вам спасибо за выделение парадигм отдельно от возможностей. Это было грамотным решением. Мне идея понравилась, язык хорошо подходит для обучения, поэтому рассматривание различных парадигм в нём будет очень кстати (по сравнению с другими языками). -- 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)[ответить]
          • У Гугл Букса есть, кстати, хорошая особеннность: можно выполнять поиск не только по предпросмотровой части, но по всей книге: [13] 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. А сейчас извините, комментарии мне сейчас не особо хочется писать, учитывая, что сегодня ни с того, ни с сего был на шаг ближе к вот этому: [14], в ближайшее время предстоит названивать в разные места, чтобы обезопасить людей вокруг, а сейчас предпочитаю поуделять больше времени семье. -- 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: [15]. Надо сказать, что отсюда я узнал про механизм переопределения метакласса, раньше не задумывался о том, как в Python работают абстрактные классы через ABCMeta. -- D6194c-1cc (обс.) 04:42, 1 марта 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, вы комментарием [16] противоречите источнику, в котором нет противопоставления - Programs in these languages generally contained more lines of code. Я поправил в статье, а вы удалили - верните обратно или перепешите как в источнике с "." между предложениями.— Saramag (обс.) 06:41, 21 марта 2021 (UTC)[ответить]

  • Каков будет ваш ответ по этому замечанию? [17] 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)[ответить]

Сложность СИ[править код]

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. [19]
Согласитесь, что мой перевод боле корректен и правая часть утверждения вытекает из левой, то есть по сути являются равнозначными. Верните мою правку и перестаньте, пожалуйста, везде добавлять превосходительную форму "крайне, значительно" (если уж хотите добавить перевод "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)[ответить]
        • [20] дескрипторы (не рекомендую вам их использовать при работе с файлами), [21] указатели. А Ява здесь причём, если обсуждаем С++? (Если вы про то, что это похожие языки и их можно сопоставлять вместе - то я не согласен) ", но является крайне сложным для понимания среди новичков, а для овладения навыками правильного использования указателей может потребоваться очень много времени" можно сократить до "но считается сложным для понимания начинающих программистов". 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)[ответить]
      • А я Вам напомню о НДА. Вы могли убрать информацию, которая, на Ваш взгляд, отсутствует в источнике, переформулировать её без потери смысла, но Вы удалили целиком весь текст, вместе со значимой информацией. В случаях вандализма это было бы оправданным, но сейчас не такой случай. Первый пункт я бы всё-таки отнёс к общеизвестным фактам или Вам нужен даже на такие тривиальные сведения источник? По второму, не буду возражать на замену на "очень", если того потребует компромиссное решение. По третьему пункту, не совсем понял, до сих пор Вы убирали информацию, а не пытались её корректировать. -- D6194c-1cc (обс.) 18:46, 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)[ответить]
  • Всё так, только проинициализировать забыли как-нибудь. Я же говорил, это должно работать на практике. Вопрос был в самом коде, всё ли там корректно написано? Пытаться исполнять тут что-либо бессмысленно. -- 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 ([23]). за пределами массива можно сравнивать лишь с элементом, следующим за последним. В моём примере в последней итерации происходит сравнение с указателем, который выходит за пределы массива (стоит до него), возможна гипотетическая ситуация, когда результат сравнения будет обратным. На практике такая ситуация, наверное, нереальна, но так писать не стоит. Как минимум это будет проблемой со статическими анализаторами или какими-нибудь опциями компиляции, выдающими ошибки для всего вообще. Да и ASAN тот же может скрешить приложение на этом месте. -- D6194c-1cc (обс.) 17:29, 23 марта 2021 (UTC)[ответить]
      • «У Вас замечания на пустом месте, Вам не кажется?» Ладно, поясню, вся информация подкреплена источниками, я подходил ответственно, обладаю достаточными знаниями и опытом для интерпретации текста по данной тематике. В статье море информации без источников, наверняка есть ошибочная, как было в случае с Ruby. Но Вы анализируете именно то, что я вносил и очень странно это аргументируете, естественно, мне непонятна Ваша позиция в данном случае, лучше качество статьи это не делает, а мою работу замедляет необходимостью излишних обсуждений. -- D6194c-1cc (обс.) 07:30, 21 марта 2021 (UTC)[ответить]
  • Ну и варианты перевода and, раз уж заговорили про английский язык: [24]. Всё зависит от контекста употребления. -- D6194c-1cc (обс.) 06:42, 21 марта 2021 (UTC)[ответить]
  • Думаю, "при этом" — компромисс между "и" и "но" YarTim (обсуждение, вклад) 09:15, 21 марта 2021 (UTC)[ответить]

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

  • Да, я тоже уже к ним приглядывался. И то, и другое про реализации рассказывает. Нужно будет объединять. Ну и список превратить в связный текст. Про PyPy можно отдельным подразделом рассказать. -- D6194c-1cc (обс.) 18:25, 25 марта 2021 (UTC)[ответить]
    • Думаю, из Википедии придется перенести список в Викиучебник. Дело в том, что по-хорошему надо писать раздел по вторичным источникам, они в принципе будут для CPython, PyPy, Jython и некоторым прочим, но будут ли они для условных «чтобы и на калькуляторе работало», в особенности, если учесть, что большая часть из них делается любителями? Я думаю, выход в том, чтобы в статье расписать только основные и сделать в начале раздела сделать примечание что «В разделе рассматриваются основные реализации Python. См. также список реализаций в Викиучебнике». Возможный недостаток в том, что за тем списком возможно никто не будет следить. YarTim (обсуждение, вклад) 12:46, 26 марта 2021 (UTC)[ответить]

Оформление списков[править код]

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

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

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

Актуальность источников[править код]

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

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

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

  1. The Google Mock class generator README. Google Test. github.com.

Saramag (обс.) 08:05, 8 апреля 2021 (UTC)[ответить]

[35] @Saramag, я специально снёс источник ложно покрывающий, чтобы потом не путаться, и потом найти приличный. YarTim (обсуждение, вклад) 02:42, 5 апреля 2021 (UTC)[ответить]

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

Если есть какие-то сомнительные утверждения, можно проверить с помощью WikiHistory когда кто-то вносил какой-то текст. Так, к примеру, я отловил это: [36] YarTim (обсуждение, вклад) 17:32, 5 апреля 2021 (UTC)[ответить]

Интроспекция[править код]

Насколько интроспекция относится к ООП? Может, раздел про интроспекцию переместить туда? YarTim (обсуждение, вклад) 07:09, 8 апреля 2021 (UTC)[ответить]

  • Я ранее считал, что получение данных об объектах во время выполнения программы относят к ревёрс-инженерингу, но вроде пишут, что [37] это часть ООП. Кстати в книге про хакинг через Пайтон) Думаю раздел можно перенести и удалить ряд повторений термина по всей статье. Saramag (обс.) 08:00, 8 апреля 2021 (UTC)[ответить]
  • По-моему, интроспекцию можно описать как самодостаточный раздел. Да, она обеспечивается за счёт ООП, но формально ещё доступен хеш глобальных переменных, и модуль inspect. -- D6194c-1cc (обс.) 16:47, 8 апреля 2021 (UTC)[ответить]
    • Да тут наверное дело не в "обеспечивается", а где используется. Прямо во время выполнения можно запросить комплексную информацию об объекте. Где это используется на практике? Когда программист имеет дело с хитровычурными классами. YarTim (обсуждение, вклад) 18:04, 8 апреля 2021 (UTC)[ответить]
      • Где используется - это примеры. А нам нужно описать, как обеспечивается, в основном, - механизмы, чем они могут быть полезны. Из примеров - отладка, обучение, диагностика, функции с переменным числом аргументов, сериализация, реализация всевозможных нестандартных возможностей. -- D6194c-1cc (обс.) 18:10, 8 апреля 2021 (UTC)[ответить]
    • Просто что вот я думаю: Python#Возможности скорее похож на некую свалочную ? подборку всяких интересных фич. Думаю, информацию нужно как-то упорядочнить и разнести. Возможно, что часть чего-то нужно будет удалить. Большую часть раздела составляет полу-орисс YarTim (обсуждение, вклад) 18:11, 8 апреля 2021 (UTC)[ответить]

Литература[править код]

Вот раздел "Литература". Что же он должен из себя представлять? Список книг-источников для статьи? Просто список книг для дополнительного чтения? Мне кажется, что первое. Стоит ли поудалять неиспользуемые книжки? YarTim (обсуждение, вклад) 05:38, 10 апреля 2021 (UTC)[ответить]

  • @Zanka, не подскажете ли? YarTim (обсуждение, вклад) 05:42, 10 апреля 2021 (UTC)[ответить]
    • Раздел литература в статусной статье представляет собой список книг, которые использовались при написании статьи. На них делаются ссылки через шаблон {{sfn}} с указанием конкретных страниц. Всё остальное из раздела литература можно убрать. Список книг для дополнительного чтения иногда оставляют, но это зависит от статьи и в данном случае это может оказаться ненужной вешалкой на все подряд учебники. — Zanka (обс.) 11:38, 10 апреля 2021 (UTC)[ответить]

Полу-безумная идея: а если PEP и документацию выделить в отдельную группу примечаний с помощью {{ref+}}?

Python позволяет улучшайзинг кода, начиная с версии 4.12[Док 1]. Идея реализовать улучшайзинг выдвигалась в PEP 1234[PEP 1] и PEP 4321[PEP 2]

Документация
PEP

YarTim (обсуждение, вклад) 14:27, 10 апреля 2021 (UTC)[ответить]

Чтобы узнать больше о компиляторах[править код]

online compiler for c++ — Эта реплика добавлена участником Cloudytechi147 (ов) 11:41, 20 сентября 2021 (UTC)[ответить]