Requests: Рассмотрите возможность включения запросов в стандартную библиотеку Python 3.5

Да, потому что это упрощает весь процесс и не снижает производительность. Так да.

• Какое влияние это окажет на способность запросов развиваться и расти?
• Согласуется ли частота выпуска запросов с частотой выпуска Python? Большая разница здесь может быть хорошим признаком того, что stdlib не подходит для запросов.

Давайте рассмотрим несколько людей, мнение которых нас очень волнует:

@shazow @kevinburke @dstufft @alex @ sigmavirus24

Что случилось с «стандартной библиотекой там, где все умирает»?

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

Стоимость моих 2 $ ВАЛЮТЫ:

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

Я думаю, что реальность такова, что если этот модуль войдет в стандартную библиотеку, текущая основная команда уйдет от него. Мне, конечно, неинтересно следить за ним в трясине ядра разработки. Скорее всего, обработкой запросов в stdlib будет @ sigmavirus24 , и он всего лишь один человек. Такая потеря направления со временем неизбежно приведет к размыванию интерфейса библиотеки, и я думаю, что это было бы трагедией.

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

Я не думаю, что вы на самом деле _ можете_ добавлять запросы в stdlib без предварительного добавления chardet и urllib3 или удаления своей зависимости от них. Также есть вещь, в которой Python не хочет поставлять пакет CA Bundle, поэтому вам нужно будет изменить его, чтобы он использовал пакет системной платформы, как это естественно делает Python сейчас.

Кроме того, я не уверен. Это, безусловно, упростило бы получение запросов, однако часть моей работы над pip в основном состоит в том, чтобы упростить получение таких вещей, как запросы, без необходимости добавлять их в stdlib. Кроме того, несколько сбивает с толку наличие нескольких способов выполнения HTTP-запросов в stdlib Python. Унификация urllib и urllib2 была хорошей вещью в Python stdlib, и я не думаю, что повторное добавление этого с urllib.request и «requests» также является хорошей идеей. Наконец, я не думаю, что это действительно поможет многим людям, это войдет только в 3.5+, поэтому любой, кто хочет использовать запросы, должен будет либо использовать версию, которая находится на PyPI, либо сделать 3.5 своей минимальной поддерживаемой версией Python, чего я не делаю. Думаю, это вполне реально в ближайшем будущем.

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

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

Как насчет того, чтобы дистрибутивы Python поставлялись с установленным по умолчанию?

Нет, не будет.

request абсолютно не подходит для включения stdlib по многим причинам, указанным до меня. Сама по себе зависимость urllib3 - полная остановка; мы не хотим, чтобы он умирал в stdlib.

Что _would_ быть полезным, так это добавить что-то _basic_ и подобное запросам, построенным на основе текущих HTTP-ресурсов stdlib, что позволяет пользователям выполнять простые запросы get / post на https, не практикуя магию крови.

Также напоминаем, что он будет добавлен только в Python 3. :) (и не ранее Python 3.6).

Вы устали поддерживать это, Кеннет? ;)

Я не думаю, что мы сможем даже начать обсуждение этого вопроса, пока кто-нибудь не скажет, что станет с httplib, urllib и друзьями. Добавление запросов без учета сложности выбора, я думаю, хуже, чем ответ «игнорируйте stdlib, просто используйте запросы». Это регресс ко временам urllib, urllib2.

Я думаю, что реальность такова, что если этот модуль войдет в стандартную библиотеку, текущая основная команда уйдет от него. Мне, конечно, неинтересно следить за ним в трясине ядра разработки. Скорее всего, обработкой запросов в stdlib будет @ sigmavirus24 , и он всего лишь один человек. Такая потеря направления со временем неизбежно приведет к размыванию интерфейса библиотеки, и я думаю, что это было бы трагедией.

Я бы забрел в stdlib, чтобы попытаться помочь, но, учитывая тот факт, что ровно один из я не знаю, сколько предыдущих наборов исправлений, которые я отправил, было принято, и еще один _reviewed_ заставляет меня опасаться возиться с этим процессом. Я знаю, что основные разработчики полностью заняты более важными вещами. Я также знаю, что кто-то другой случайным образом решил, что они хотят поддерживать httplib / http, но они явно не подходят для этой работы (пока), и у меня нет терпения работать с httplib, когда исправляют, что и @Lukasa, и я вокруг, непроверенные и не заботящиеся (когда они исправляют насущные проблемы с библиотекой).

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

request абсолютно не подходит для включения stdlib по многим причинам, указанным до меня. Сама по себе зависимость urllib3 - полная остановка; мы не хотим, чтобы он умирал в stdlib.

@Kennethreitz (и, следовательно, проект в целом) всегда утверждал, что urllib3 - это деталь реализации. Многие из важнейших функций запросов полностью обрабатываются urllib3, но это не значит, что их нельзя с осторожностью преобразовать в действительно независимую библиотеку.

Что касается зависимости от chardet: это было не чем иным, как головной болью для нас (и для меня в частности). Раньше у него были отдельные кодовые базы для py2 и py3, пока я не поместил его в единую библиотеку кодовой базы (которая только за последние несколько месяцев была объединена обратно в chardet). Библиотека медленная и требует огромного количества памяти (из-за чего многие люди так разозливаются, что кричат ​​на нас здесь, в системе отслеживания проблем). Это не совсем точно, и универсальная диаграмма Mozilla, по которой он был смоделирована, была практически оставлена ​​Mozilla. Так что удаление chardet, вероятно, в любом случае было бы чистым плюсом.

Что касается того, должны мы это делать или нет, меня, откровенно говоря, не волнует. Все, что будет в stdlib, в конечном итоге будет запросами только в API. Скорость внедрения Python 3 достаточно низкая, поэтому я не думаю, что люди будут серьезно затронуты этим в течение следующих N лет (где N - глобально неизвестное количество лет для 3,5, которое будет использоваться в производстве корпорациями).

И, как я уже сказал, в этот момент я, вероятно, просто буду создавать запросы или использовать urllib3.

На днях я подробно обсуждал это с Гвидо - сначала нужно было включить чардет. Я думаю, что urllib3 и запросы могут быть включены в пакет http вместе.

Однако я очень склонен согласиться с @hynek и @dstufft. Возможно, с запросами все в порядке :)

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

: блестки:: торт:: блестки:

Кроме того, кажется, что добавление нового модуля http в stdlib без asyncio-истории
помешанный на мне.

Вск, 25 января 2015 г., 13:15:51 Кеннет Райтц [email protected]
написал:

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

[изображение:: блестки:] [изображение:: торт:] [изображение:: блестки:]

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71384152
.

Я не думаю, что мы можем даже начать обсуждать этот вопрос, пока кто-то не скажет, что станет с httplib, urllib и друзьями.

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

: +1:: металл:

Чтобы быть ясным, мой вышеупомянутый комментарий о повторной реализации urllib3 для включения в stdlib не следует воспринимать легкомысленно. Объем работы, необходимой для этого, будет огромен, потому что urllib3 - это продукт (вероятно, 10 или более) лет работы разработчиков.

Я тоже говорил с Гвидо о добавлении urllib3 в stdlib несколько лет назад и пришел к выводу, что это не лучшая идея, но на данный момент я довольно нейтрально к ней отношусь.

API urllib3 был в основном стабильным и почти полностью обратно совместимым уже несколько лет. Его темп, возможно, даже медленнее, чем у stdlib сегодня, при этом подавляющее большинство изменений являются незначительными исправлениями или улучшениями безопасности (с редкими добавлением обратно совместимых функций, таких как детализированные тайм-ауты / повторные попытки). Если кто-то действительно хотел попробовать включить urllib3 в стандартную библиотеку, я не думаю, что это ужасная идея - это просто не лучшая идея.

(Я не говорю о запросах, поскольку он движется совсем другим темпом с другими целями, чем urllib3.)

На мой взгляд, лучшей идеей было бы для PSF нанять (или, может быть, Kickstart или что-то в этом роде) 1-3 разработчика для создания новой библиотеки http поверх asyncio с поддержкой HTTP / 2 с сильным вдохновением от urllib3, запросов , и гипер. Я был бы рад увидеть как можно больше кода, взятого дословно, но разложенного в последовательной, модульной и многократно используемой манере. В идеале нацелитесь на Python 4 или что-то в этом роде и избавьтесь от всех URL-адресов и httplib. Я ожидаю, что это будет 6-9 месяцев тяжелой работы, но, возможно, и больше.

Самая худшая часть urllib3, которую я хотел бы видеть замененной, если кто-то попытается переписать ее согласно предложению @sigmavirus24 , заключается в том, что она зависит от httplib. Функциональность urllib3 существенно ограничена из-за большого количества кода, потраченного на устранение недостатков httplib. Хотя если для этой цели серьезно отнестись к поддержке HTTP / 2, то объем повторной реализации HTTP / 1.1 был бы очень утешительной частью требуемой работы.

Много PyCons назад мы встретились и разработали макет совершенно новой библиотеки http, которая преобразовывает все части в идеальное расположение, которое мы могли представить в то время. Я был бы счастлив откопать эти заметки, если кто-то попытается это сделать.

+1 @shazow

Опять же, если у кого-то найдется время и желание взяться за этот довольно большой проект, я набросал предполагаемый дизайн API, который может стать хорошей отправной точкой.

Да, потому что единственный способ разрешить запросы в качестве зависимости - это если они находятся в stdlib.

Тем не менее, urllib3 содержит функции, которые действительно нужны людям, поэтому мне достаточно иметь это в stdlib.

Вы не пользуетесь никакими зависимостями?

@dstufft это в проектах, которые обычно этого не делают, где каждый не может беспокоиться о том, чтобы выяснить, как использовать urllib. (люди не добавляют его как dep из-за ssl / etc в целом, а из-за лени)

@dstufft также многоверсионный deps в основном затрудняет использование вещей в библиотеках. Вы, вероятно, захотите использовать запросы в своем проекте, и если нам это потребуется, есть вероятность причинения вреда, если изменения API произойдут в версиях.

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

@ sigmavirus24 Я не согласен. API запросов был изменен в прошлом. API меняются, поэтому у нас есть версии, вот почему зависимости сложны. Это идеальный случай для такого обсуждения, потому что запросы являются зависимостью во многих проектах.

Если вы перейдете в stdlib, API должен быть стабильным.

@dcramer API сломался ровно один раз, в 1.0. API меняются, но API запросов тоже не планирует никаких изменений. Единственное изменение, которое у нас было, - это добавление параметра json который ничего не ломает. Вы можете продолжать обвинять нас в слишком частом нарушении API, но когда в таких проектах, как OpenStack, в течение долгого времени были требования, определенные как >=1.2.3 , я думаю, что это многое говорит о стабильности запросов. API был стабильным именно потому, что после того, как мы вырезали 1.0, мы отклонили все новые дополнения к API (с очевидным недавним исключением добавления параметра json ), и мы очень строго следили за тем, чтобы не нарушать API. Если вы не являетесь потребителем запросов, вы бы этого не узнали. Так что я не принимаю ваше незнание на свой счет.

Кроме того, если API stdlib предположительно настолько стабилен, объясните, почему argparse нарушил его общедоступный API между Python 3.3 и 3.4?

@ sigmavirus24 вы теперь просто превращаете это в обсуждение API. Я просто указал на причину, по которой я не включаю его, потому что он может меняться, и все используют его, и все используют разные версии. Здорово, что вы, ребята, никогда не меняете свой API, но у меня нет ни желания, ни времени следовать этому или предполагать, что это правда.

Вы знаете, что Python тоже меняет свой API, на самом деле довольно часто, иногда очень серьезно, возможно, вы слышали о Python 3?

Что ж, я ухожу из этой дискуссии. Я ясно высказал свое мнение. Не уверен, о чем вы все причитываете.

Я думаю, что нужно ответить на следующие ключевые вопросы:

1. Как бы вы хотели изменить стандартную документацию (включая учебник)? Нынешние стандартные библиотеки HTTP API восходят к эпохе, когда отказ от деталей конкурирующих протоколов (например, FTP против HTTP) считался желательным подходом. В последующие полтора десятилетия сообщество веб-разработчиков сошлось на HTTPS + JSON в качестве предпочтительного подхода к взаимодействию клиент / сервер в стиле запрос / ответ для большинства случаев использования, кроме удаленного выполнения команд (которое использует SSH или Windows RCP), API запросов - это де-факто стандартная клиентская реализация этой модели для современных приложений Python.
2. Вы хотите, чтобы API запросов был обновлен со стандарта де-факто до стандарта де-юре, чтобы он автоматически включался во все каналы распространения CPython, получал долгосрочные гарантии поддержки CPython (и наших коммерческих распространителей), а также вся образовательная деятельность "только стандартная библиотека"? (Последние по-прежнему очень распространены, поскольку критерии для использования в корпоративных средах часто включают поддержку и гарантии IP, которые есть в CPython, а в запросах нет. В текущей ситуации многие пользователи просто не будут рассматривать запросы как вариант, потому что для них слишком много работы, чтобы получить аккредитацию для использования)
3. Какие еще модули в стандартной библиотеке можно было бы улучшить с помощью таких запросов, как API?
4. Было бы лучше оставить запросы неизменными как независимую от версии реализация API, и вместо этого добавить новый API, основанный на запросах, в стандартную библиотеку, подобно тому, как Гвидо подошел к работе по стандартизации ayncio?

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

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

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

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

Готовы ли вы сделать это, имея людей, работающих над некритическими сервисами, где очень низкий уровень надежности (часто менее 99% времени безотказной работы) вполне приемлем, жалуясь на то, что ваши глубокие проблемы с доверием необоснованны, и просто вопрос глупой зацикленной политики, которая они не могут беспокоиться о себе?

Кроме того, я хотел бы исправить ошибочное предположение: подавляющее большинство программистов Python, вероятно, даже не слышали о pip, не говоря уже о запросах. Это те люди, которые запускают скрипты в системе Python для долгосрочной поддержки выпусков Linux, и большинство разработчиков с открытым исходным кодом быстро выражают неописуемое презрение к ним, не останавливаясь на размышлениях о том, какие обстоятельства могут сыграть роль, чтобы их подход стал хорошей идеей.

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

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

В качестве более конкретного примера того, как пузырь фильтров «сообщества открытого исходного кода» может исказить нашу точку зрения: Jenkins занимает более 70% рынка корпоративных развертываний CI.

Будьте очень, очень осторожны, полагаясь на интуицию относительно того, что «все знают», когда вы основываете эту точку зрения на отдельных лицах и организациях, которые активно участвуют в разработке открытого исходного кода. Подавляющее большинство разработок программного обеспечения по-прежнему выполняется на заказ для удовлетворения потребностей конкретной организации, и подавляющее большинство людей, занимающихся этим, по-прежнему получают свои инструменты и информацию от коммерческих поставщиков, а не от сообщества разработчиков ПО с открытым исходным кодом.

@dcramer
Не уверен, о чем вы все причитываете.

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

@ncoghlan

По пункту 1: я думаю, что документация будет значительно упрощена с помощью запросов (как запросов) в stdlib. Одна из первых вещей, которые я делаю при изучении нового языка, - это выясняю, как работает HTTP. Наличие этого - то, от чего руководство выиграет в любом случае.

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

По пунктам 3 и 4: Я не уверен, что это что-то здесь обсуждается. Может быть, питон-идеи были бы лучше.

Что касается идеи управляемой разработки PSF, я категорически против этого, поскольку у нас нет инфраструктуры управления, чтобы справиться с подобными вещами.

Это интересно. Я не думал, что это вероятность, но было бы здорово иметь что-нибудь получше, чем http (lib).

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

Я не уверен, о каком рычаге вы говорите. Я видел, что Debian и другие распространители в CPython сломали surepip, venv и другие вещи. Однако это не относится к этому обсуждению.

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

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

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

Реальность такова, что эти люди никогда не догонят, не так ли? Люди все еще используют программное обеспечение на Python 2.4 и 2.5. Балансировщики нагрузки F5 по-прежнему поддерживают только Python 2.5. 2.7 будет использоваться, вероятно, до конца моей естественной жизни (которая, я надеюсь, будет довольно долгой). Неужели на этих людей это решение повлияет сильнее всего? Те же самые люди, которых вы описываете, могут никогда не совершить прыжок на Python 3. И в настоящее время это все еще _leap_. Возможно, к тому времени, когда они решат это рассмотреть, Python 3.8, 3.9 или 4.2 выйдет из употребления и доставит им гораздо меньше хлопот.

Правильно, я хочу сказать, что цель включения стандартной библиотеки очень сильно отличается от цели более распространенной задачи по предоставлению библиотеки с открытым исходным кодом для использования другими разработчиками с открытым исходным кодом. Если команда запросов решит продолжать предоставлять только независимо поддерживаемую библиотеку (общественная услуга, за которую я безмерно благодарен, вы, ребята, делаете отличную работу!), И не будет поддерживать стремление к стандартизации API, тогда мы будем полагаться на на распространителях, таких как RHEL / Fedora / CentOS, Debian / Ubuntu, ActiveState, Enthought и Continuum Analytics, чтобы взять модуль и стандартизировать его _в любом случае_, чтобы люди могли предположить, что он всегда будет доступен (или, по крайней мере, достаточно часто, чтобы они были счастливы полагаться на API в однофайловых скриптах, которые не полностью упакованы с соответствующими объявлениями зависимостей). Тем не менее, большая часть вводной документации, скорее всего, по-прежнему будет направлять людей на использование HTTP в стандартной библиотеке, поэтому будут ли их обучать «HTTP для Python, выпуск 2001 г.» или «HTTP для Python, выпуск 2015 г.» будет зависеть от того, получат ли они его из исходный код "только стандартная библиотека" или тот, который включает рекомендованные сторонние модули.

Как и в случае с virtualenv и PEP 405, или Twisted + Tornado против asyncio, или ipaddr против ipaddress, я не думаю, что имеет смысл включать _requests себя_ в стандартную библиотеку. Скорее, я думаю, что имеет больше смысла поддержать включение API запросов _inspired_, который не учитывает весь код совместимости между версиями, объединение сертификатов и т. Д. И т. Д., И просто предоставляет API по умолчанию и документацию для обработки аутентифицированных HTTP-запросов до 2015 стандарты. Затем в 2030 году мы будем жаловаться на то, насколько архаичен дизайн _requests_ API по стандартам 2030 года («HTTP? Кто это еще использует?!?!»), Но это нормально, просто эти циклы работают (до появления первого AJAX а затем появился JSON, XML-RPC был королем горы). Если вы потратите 5 лет на разработку API, прежде чем люди начнут жаловаться на его устаревание, у вас все хорошо, 10 - впечатляюще, а 15 - действительно впечатляюще.

Главное, чтобы начать этот процесс, - это кто-то, достаточно мотивированный идеей доступности API запросов повсюду, чтобы отстаивать усилия по стандартизации, выполнять работу по внедрению и стремиться к поддержке stdlib хотя бы в первые несколько лет. Альтернативой является продолжение в значительной степени полагаться на распространителей для охвата разработчиков, которые не желают и / или не могут загружать и запускать произвольный код из Интернета (категория, которая включает всех в любой отрасли с строгими нормативными требованиями должной осмотрительности, а также всех работая на другие организации с таким же низким аппетитом к риску).

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

С точки зрения циклов обновления, одна из ключевых вещей, о которых идет речь в восходящей стандартизации (даже в Python 3), - это консенсус сообщества. При этом библиотеки, которые являются «backports» для функций Python 3, становятся намного проще, чтобы оправдать объединение с Python 2. Лично я все же хотел бы увидеть сумо-релиз Python 2, который выполняет именно такое объединение (unittest2, subprocess32, enum34, contextlib2 , trollius и т. д.), но это отдельная отдельная политическая битва, особенно с точки зрения убеждения людей в том, что интерес и ресурсы для поддержания такого независимого распределения сумо от перераспределителя до 2020 года действительно доступны.

@dcramer спасибо, что ценно : heart:

@ sigmavirus24 все хорошо :)

Мне нечего добавить к включению stdlib, кроме
Было бы неплохо взглянуть на некоторые PEP или темы или поговорить о том, что должно быть
в Python stdlib и, возможно, оглянуться на прошлогодний или около того
развития с точки зрения того, "как решить эту проблему
другое, если это был модуль в стандартной библиотеке ".

Поскольку это может стать де-факто темой, на которую смотрят люди, когда говорят
"что мы должны добавить / изменить при рассмотрении вопроса о добавлении запросов в stdlib",
Я хотел бы еще раз сказать об обновлении иерархии исключений. я
обычно возникают два вопроса, когда запрос не выполняется: а) Какие
подразумеваемое? и б) Могу ли я безопасно повторить запрос?
Ошибка поиска DNS и сломанный канал имеют разные последствия.
но запросы в настоящее время группируют как ConnectionError. Я подробно описал некоторые
работ, задействованных здесь:
https://gist.github.com/kevinburke/b98e053a4bf9835c67bb

Рад обсудить больше с заинтересованными людьми.

Кевин Берк
телефон: 925.271.7005 | twentymilliseconds.com

Вс, 25 января 2015 г., в 20:15 ncoghlan [email protected] написал:

В качестве более конкретного примера того, как фильтрация "сообщества открытого исходного кода"
пузырь может исказить нашу перспективу: Дженкинс занимает более 70% рынка
в корпоративных развертываниях CI.

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71413074
.

FWIW, я думаю, что формулировка http://docs.python-requests.org/en/latest/dev/philosophy/ ,

Essentially, the standard library is where a library goes to die.
It is appropriate for a module to be included when active 
development is no longer necessary.

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