Requests: Considere la inclusión de solicitudes en la biblioteca estándar de Python 3.5

Sí, porque simplifica todo el proceso y no sacrifica el rendimiento. Entonces sí.

• ¿Qué tipo de impacto tendría esto en la capacidad de las solicitudes para evolucionar y crecer?
• ¿La frecuencia de publicación de las solicitudes coincide con la de Python? Una gran diferencia aquí podría ser una buena indicación de que stdlib no es el lugar adecuado para las solicitudes.

Hagamos un CC de algunas personas cuyas opiniones nos interesan mucho:

@shazow @kevinburke @dstufft @alex @ sigmavirus24

¿Qué pasó con "la biblioteca estándar es donde las cosas van a morir"?

La pregunta de la cadencia de liberación es buena; Me preocuparía perder la capacidad de la solicitud para evolucionar libremente. Dicho esto, quizás una biblioteca central de solicitudes sea una buena opción.

El valor de mis 2 $ CURRENCY:

No estaría dispuesto a hacerlo. Creo que estar fuera de la biblioteca estándar nos ha dado la libertad de tomar decisiones que beneficien a nuestros usuarios sin quedar atrapados detrás de las políticas de desarrollo principales para el soporte y el lanzamiento de versiones. Nos permite discrepar respetuosamente con las prioridades del desarrollo principal. Y nos permite tomar decisiones ideológicas, que ha sido el alma de este proyecto durante más de tres años.

Creo que la realidad es que si este módulo ingresa a la biblioteca estándar, el equipo central actual lo dejará. Ciertamente tengo poco interés en seguirlo hasta el atolladero que es el desarrollo principal. Lo más probable es que administre solicitudes en stdlib es @ sigmavirus24 , y él es solo un hombre. Esa pérdida de dirección conducirá inevitablemente a una erosión de la interfaz de la biblioteca con el tiempo, y creo que sería algo trágico.

Lo único que nos da estar en la biblioteca estándar es nuestro tiempo atrás. Esa es una buena razón para ponerlo allí, si eso es lo que crees que necesita, pero no creo que debamos pretender que mejorará la biblioteca o el ecosistema de Python.

No creo que en realidad _pue_ agregar solicitudes a stdlib sin primero agregar chardet y urllib3 o eliminar su dependencia de ellos. También existe el problema en el que Python no quiere enviar un paquete de CA, por lo que deberá modificarlo para que utilice el paquete de plataforma del sistema como lo hace Python de forma natural ahora.

Además de eso, no estoy seguro. Ciertamente facilitaría la obtención de solicitudes, sin embargo, parte de mi trabajo en pip es básicamente hacer que sea fácil obtener cosas como solicitudes sin necesidad de agregarlas a stdlib. Además de eso, también es algo confuso tener varias formas de realizar solicitudes HTTP en Python stdlib. La unificación de urllib y urllib2 fue algo bueno en Python stdlib y no creo que volver a agregar eso con urllib.request y "solicitudes" tampoco sea una buena idea. Finalmente, no creo que realmente ayude a muchas personas, esto solo entraría en 3.5+, por lo que cualquier persona que quiera usar solicitudes tendría que usar la versión que está en PyPI o hacer 3.5 su versión mínima de Python compatible que yo no Creo que es algo realista que suceda en un futuro cercano.

Si bien creo que tener solicitudes en la biblioteca estándar ayudaría a los nuevos usuarios, no sé si ayudaría a la comunidad de Python en su conjunto. Los usuarios experimentados saben cómo utilizar Requests y saben cómo instalarlo.

Me preocuparía especialmente el efecto escalofriante que tendría en el nuevo desarrollo, ya que otros no estarían dispuestos a contribuir, sabiendo que no verían sus cambios contribuidos en una versión fácil de usar durante mucho tiempo.

¿Qué pasa con el término medio de hacer que las distribuciones de Python se envíen con él instalado de forma predeterminada?

No, no lo haría.

Las solicitudes son absolutamente inadecuadas para la inclusión de stdlib por las muchas razones expuestas ante mí. La dependencia de urllib3 por sí sola es un completo espectáculo; no queremos que muera en stdlib.

Lo que _sería_ útil es agregar algo _básico_ y similar a las solicitudes creadas sobre los recursos http actuales de stdlib que permite a los usuarios realizar solicitudes simples de obtención / publicación en https sin practicar magia de sangre.

También le recordamos que se agregaría solo a Python 3. :) (y no antes de Python 3.6).

¿Estás cansado de mantenerlo Kenneth? ;)

No creo que podamos empezar a discutir esta cuestión sin que alguien nos diga qué será de httplib, urllib y amigos. Agregar solicitudes sin abordar la complejidad de la elección es, creo, peor que la respuesta "ignore la biblioteca estándar, solo use solicitudes". Es una regresión a los días de urllib, urllib2.

Creo que la realidad es que si este módulo ingresa a la biblioteca estándar, el equipo central actual lo dejará. Ciertamente tengo poco interés en seguirlo hasta el atolladero que es el desarrollo principal. Lo más probable es que administre solicitudes en stdlib es @ sigmavirus24 , y él es solo un hombre. Esa pérdida de dirección conducirá inevitablemente a una erosión de la interfaz de la biblioteca con el tiempo, y creo que sería algo trágico.

Me adentraría en stdlib para tratar de ayudar, pero dado que exactamente uno de los que no sé cuántos conjuntos de parches anteriores he enviado ha sido aceptado y otro _reviewed_ me hace recelar de querer molestarme con ese proceso. Sé que los desarrolladores centrales están completamente abrumados por cosas más importantes. También sé que alguien más ha decidido al azar que quiere mantener httplib / http, pero claramente no son adecuados para el trabajo (todavía) y no tengo la paciencia para trabajar en httplib cuando los parches que tanto @Lukasa como yo nos sentamos alrededor, sin revisar y sin importarle (cuando solucionan problemas urgentes con la biblioteca).

Probablemente terminaría bifurcando solicitudes para seguir usándolo.

Las solicitudes son absolutamente inadecuadas para la inclusión de stdlib por las muchas razones expuestas ante mí. La dependencia de urllib3 por sí sola es un completo espectáculo; no queremos que muera en stdlib.

Siempre ha sido un argumento de @kennethreitz (y por lo tanto, del proyecto en su conjunto) que urllib3 es un detalle de implementación. Muchas de las características más importantes de las solicitudes son manejadas por completo por urllib3, pero eso no significa que no puedan reimplementarse con cuidado en una biblioteca verdaderamente libre de dependencias.

Respecto a la dependencia de chardet: no ha sido más que un dolor de cabeza para nosotros (y para mí específicamente). Solía ​​tener bases de código separadas para py2 y py3 hasta que lo puse en una sola biblioteca de base de código (que solo en los últimos meses se ha fusionado nuevamente en chardet propiamente dicho). La biblioteca es lenta y un gran acaparamiento de memoria (lo que enfurece a muchas personas hasta el punto de gritarnos aquí en el rastreador de problemas). No es del todo exacto y el universalchardet de Mozilla en el que se basa ha sido abandonado por Mozilla. Por lo tanto, eliminar el chardet probablemente sería un positivo neto de todos modos.

En cuanto a si deberíamos hacer esto o no, francamente no me preocupa. Lo que sea que esté en stdlib terminaría siendo solicitudes solo en API. La tasa de adopción de Python 3 es lo suficientemente lenta como para que no creo que las personas se vean afectadas de manera significativa por esto durante los próximos N años (donde N es el número de años globalmente desconocido para que las corporaciones utilicen 3.5 en la producción).

Y como dije, probablemente terminaría bifurcando solicitudes o usando urllib3 directamente en ese momento.

Discutí esto extensamente con Guido el otro día; primero habría que incluir a chardet. Creo que urllib3 y las solicitudes podrían incluirse juntas en el paquete http.

Sin embargo, estoy muy inclinado a estar de acuerdo con @hynek y @dstufft. Quizás las solicitudes estén bien tal como están :)

De cualquier manera, si tiene una opinión que le gustaría compartir, puede compartirla aquí (o en cualquier momento).

: destellos:: pastel:: destellos:

Además, parece que agregar un nuevo módulo http al stdlib sin asyncio-story
loco para mí.

El domingo 25 de enero de 2015 a las 1:15:51 p.m. Kenneth Reitz [email protected]
escribió:

De cualquier manera, si tiene una opinión que le gustaría compartir, está
bienvenido a compartirlo aquí (o en cualquier momento).

[imagen:: destellos:] [imagen:: pastel:] [imagen:: destellos:]

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71384152
.

No creo que podamos comenzar a discutir esta pregunta sin que alguien diga qué será de httplib, urllib y amigos.

Este es mi problema. Creo que primero hay que resolver la confusa situación actual.

: +1:: metal:

Para que quede claro, mi comentario anterior sobre la reimplementación de urllib3 para su inclusión en stdlib no debe tomarse a la ligera. La cantidad de trabajo necesario para hacer eso sería inmensa porque urllib3 es el producto de (probablemente 10 o más) años de trabajo de desarrollador.

Yo también hablé con Guido sobre lanzar urllib3 al stdlib hace algunos años con la conclusión de que no es una gran idea, pero soy bastante neutral al respecto en este momento.

La API de urllib3 ha sido en su mayor parte estable y prácticamente completamente compatible con versiones anteriores durante varios años. Su ritmo es posiblemente incluso más lento que el del stdlib actual, y la gran mayoría de los cambios son correcciones menores o mejoras de seguridad (con adiciones ocasionales de funciones compatibles con versiones anteriores como tiempos de espera / reintentos granulares). Si alguien realmente quisiera tratar de incluir urllib3 en la biblioteca estándar, no creo que sea una idea terrible, simplemente no es la mejor idea.

(No estoy hablando por solicitudes, ya que se mueve a un ritmo muy diferente con objetivos diferentes a urllib3).

La mejor idea, en mi opinión, sería que el PSF contratara (o tal vez Kickstart o algo así) 1-3 desarrolladores para construir una nueva biblioteca http sobre asyncio con soporte HTTP / 2 con gran inspiración de urllib3, solicitudes e hiper. Estaría feliz de ver la mayor cantidad de código tomado literalmente como sea posible, pero presentado de una manera consistente, modular y reutilizable. Lo ideal sería apuntar a Python 4 o algo así, y deshacerse de todos los urllibs y httplibs. Espero que esto sea de 6 a 9 meses de trabajo duro, pero posiblemente más.

La peor parte de urllib3, que me encantaría ver reemplazada si alguien intenta reescribirlo según la sugerencia de @ sigmavirus24 , es que depende de httplib. La funcionalidad de urllib3 está sustancialmente limitada con una gran cantidad de código dedicado a solucionar las deficiencias de httplib. Aunque si el soporte HTTP / 2 se tomara en serio en este objetivo, entonces el alcance de volver a implementar HTTP / 1.1 sería una fracción muy reconfortante del trabajo requerido.

Hace muchos PyCons, un grupo de nosotros nos reunimos y hicimos una tabla blanca con un diseño de una nueva biblioteca http que refactoriza todas las piezas en la disposición ideal que podríamos imaginar en ese momento. Estaría feliz de desenterrar estas notas si alguien va a intentar esto.

+1 @shazow

Nuevamente, si alguien se encuentra con el tiempo y las ganas de asumir ese proyecto bastante grande, he esbozado un diseño de API putativo que podría ser un buen punto de partida.

Sí, porque la única forma en que permitiré solicitudes como dependencia es si está en stdlib.

Dicho esto, urllib3 contiene las características que la gente realmente quiere, así que tener eso en stdlib es suficiente para mí

¿No usas ninguna dependencia?

@dstufft esto es en proyectos que generalmente no lo hacen, donde todos no pueden molestarse en descubrir cómo usar urllib. (las personas no lo agregan como un depósito debido a ssl / etc.en general, sino por pereza)

@dstufft también hace que sea difícil usar cosas en bibliotecas. Probablemente desee utilizar solicitudes en su proyecto y, si lo requerimos, existe la posibilidad de un mundo de daño si se producen cambios en la API en las versiones.

Si bien aprecio que algunas personas quieran desarrollar dependencias sin dependencias de otro software que no ha cambiado su API en años, este no es el lugar para la discusión.

@ sigmavirus24 No estoy de acuerdo. solicitudes ha tenido su cambio de API en el pasado. Las API cambian, por eso tenemos versiones, por eso las dependencias son complejas. Este es un caso perfecto para esa discusión porque las solicitudes son una dependencia en muchos proyectos.

Si pasa a stdlib, la API debe ser estable.

@dcramer, la API se rompió exactamente una vez, en 1.0. Las API cambian, pero la API de las solicitudes tampoco planea ningún cambio. El único cambio que hemos tenido es agregar el parámetro json que no rompe nada. Puede seguir intentando acusarnos de romper demasiado la API, pero cuando proyectos como OpenStack han tenido requisitos definidos como >=1.2.3 durante mucho tiempo, creo que eso dice mucho sobre la estabilidad de las solicitudes. La API se ha mantenido estable, precisamente porque después de que cortamos 1.0 rechazamos todas las nuevas adiciones a la API (con la obvia excepción reciente de agregar un parámetro json ) y hemos sido muy estrictos sobre no romper la API. Sin embargo, si no es un consumidor de solicitudes, no lo sabría. Así que no tomo tu ignorancia como algo personal.

Además, si la API stdlib es supuestamente tan estable, explique por qué argparse rompió su API pública entre Python 3.3 y 3.4.

@ sigmavirus24 ahora está convirtiendo esto en un debate de API. Solo estaba señalando que la razón por la que no lo incluyo es porque puede cambiar, y todos lo usan, y todos usan versiones diferentes. Es genial que ustedes nunca cambien su API, pero no tengo ganas ni tiempo de seguirla o asumir que eso es cierto.

Sabes que Python también cambia su API, con bastante frecuencia en realidad, a veces de formas muy importantes, ¿quizás has oído hablar de Python 3?

Bueno, me voy de este debate. Dejé claras mis opiniones. No estoy seguro de qué están quejándose.

Creo que algunas preguntas clave para responder son:

1. ¿Cómo le gustaría que cambiara la documentación estándar (incluido el tutorial)? Las API HTTP de la biblioteca estándar actual datan de una época en la que abstraer los detalles de los protocolos de la competencia (por ejemplo, FTP frente a HTTP) se consideraba un enfoque deseable. En la siguiente década y media, la comunidad de desarrollo web ha convergido en HTTPS + JSON como el enfoque preferido para la interacción cliente / servidor de estilo de solicitud / respuesta para la mayoría de los casos de uso que no sean la ejecución remota de comandos (que usa SSH o Windows RCP). y la API de solicitudes es la implementación de cliente estándar de facto de ese modelo para las aplicaciones modernas de Python.
2. ¿Desea que la API de solicitudes se actualice de un estándar de facto a un estándar de jure, de modo que se incluya automáticamente en todos los canales de redistribución de CPython, cuente con el respaldo de las garantías de soporte a largo plazo de CPython (y nuestros redistribuidores comerciales), así como ¿Todas las actividades educativas "solo biblioteca estándar"? (Estos últimos siguen siendo muy comunes, ya que los criterios para su uso en entornos corporativos a menudo incluyen soporte y garantías de IP, que CPython tiene, pero las solicitudes no. En la situación actual, muchos usuarios simplemente no considerarán las solicitudes como una opción porque es demasiado trabajo para ellos obtener la acreditación para su uso)
3. ¿Qué otros módulos de la biblioteca estándar se podrían mejorar al tener una solicitud como API para construir?
4. ¿Sería mejor mantener las solicitudes sin cambios como una implementación independiente de la versión de la API y, en su lugar, agregar una nueva API inspirada en solicitudes a la biblioteca estándar, similar a la forma en que Guido abordó el trabajo de estandarización de ayncio?

En lo que respecta a la idea del trabajo de desarrollo administrado por PSF, estaría muy en contra de eso, ya que no tenemos la infraestructura de administración para manejar ese tipo de cosas. Una propuesta de subvención que sugiera que el PSF contribuya a un esfuerzo de financiación colectiva en esta área sería una historia diferente (no hay garantías sin una propuesta específica para revisar, pero ciertamente es una idea que estaríamos dispuestos a discutir).

Tenga en cuenta que es posible que algunos proveedores ya redistribuyan las solicitudes, pero "¿también brindan soporte para las solicitudes?" se convierte en una pregunta separada que tenemos que hacer a un proveedor o proveedor de plataforma. Por lo tanto, en un contexto de gestión de riesgos a largo plazo (piense en años y décadas, en lugar de semanas o meses), depender de esto significa que tenemos que asumir el riesgo y la responsabilidad de la autosuficiencia si el upstream se aburre y pasa a otra cosa, o bien aceptar una reducción potencial en el grado de elección que tenemos en los proveedores de plataformas.

Con la biblioteca estándar, generalmente no tenemos esa preocupación: mientras que los redistribuidores ocasionalmente rompen cosas, en un contexto comercial, los proveedores que rompen cosas que funcionan en sentido ascendente le brindan bastante influencia para que el proveedor infractor arregle las cosas.

Oh, otra pregunta clave que debe responder antes de ofrecerse como voluntario para mantener realmente las cosas en la biblioteca estándar: ¿está preparado para aceptar la responsabilidad de enviar software que ayuda a impulsar la mitad de las bolsas de valores del mundo, es uno de los lenguajes más populares para la infraestructura corporativa, uno de los lenguajes más populares para la programación científica (incluido el uso para la planificación de trayectorias en misiones espaciales interplanetarias), uno de los lenguajes más populares para el desarrollo web y uno de los lenguajes clave que se emplean en las nuevas iniciativas de alfabetización informática en las instituciones educativas?

¿También está preparado para hacer eso mientras tiene gente trabajando en servicios no críticos donde los niveles de confiabilidad muy bajos (a menudo menos del 99% de tiempo de actividad) son perfectamente aceptables? ¿No pueden preocuparse por sí mismos?

Además, una suposición errónea que me gustaría corregir: es probable que la gran mayoría de los programadores de Python ni siquiera hayan oído hablar de pip, y mucho menos de las solicitudes. Estas son las personas que ejecutan scripts en el sistema Python en versiones de Linux de soporte a largo plazo, las personas por las que la mayoría de los desarrolladores de código abierto expresan rápidamente un desprecio inefable, sin detenerse a considerar qué circunstancias podrían estar en juego para que su enfoque sea una buena idea.

Los tiempos del ciclo de adopción en esta comunidad se miden inherentemente en años. Es solo una pequeña fracción de la industria que actualmente está ejecutando CI suficientemente riguroso para poder ir más rápido, y la mayoría de las personas en esa fracción no están interesadas en desacelerar el tiempo suficiente para escuchar las preocupaciones de aquellos con grandes franjas de infraestructura que necesitamos gestionar y modernizar.

Esa parte posterior al abismo de la curva de adopción de tecnología es a la que llegamos cuando decimos "sí, este enfoque ahora está lo suficientemente maduro como para que podamos empujarlo, o algo basado en él, a la biblioteca estándar para ayudar a convertirlo en una herramienta verdaderamente universal suposición".

Como ejemplo más concreto de cómo la burbuja del filtro de la "comunidad de código abierto" puede sesgar nuestra perspectiva: Jenkins tiene más del 70% de participación de mercado en implementaciones de CI corporativas.

Sea muy, muy cauteloso al confiar en las intuiciones sobre lo que "todo el mundo sabe", cuando basa esa perspectiva en personas y organizaciones que están muy involucradas en el código abierto. La gran mayoría del desarrollo de software sigue siendo trabajo personalizado para satisfacer las necesidades de una organización en particular, y la gran mayoría de las personas que lo hacen todavía obtienen sus herramientas e información de proveedores comerciales en lugar de la comunidad de código abierto.

@dcramer
No estoy seguro de qué están quejándose.

Lenguaje muy apropiado para este debate. Cuando se hacen contraataques legítimos a su posición, usa un insulto destinado a degradar a las mujeres. Sin embargo, a la par del campo. Hacia adelante,

@ncoghlan

Con respecto al punto 1: Creo que la documentación se simplificaría drásticamente con solicitudes (solicitudes por igual) en stdlib. Una de las primeras cosas que hago al aprender un nuevo idioma es averiguar cómo funciona HTTP. Tener eso destacado es algo de lo que la guía se beneficiaría independientemente.

Con respecto al punto 2: hay una diferencia entre la API y la biblioteca siendo de facto frente a de jure. La API podría ser proporcionada fácilmente por la biblioteca estándar. Creo que su preocupación por el soporte estaría más dirigida a que se incluyan las solicitudes (el código).

Con respecto a los puntos 3 y 4: No estoy seguro de que sea algo que deba discutirse aquí. Quizás las ideas de pitón serían mejores.

En lo que respecta a la idea del trabajo de desarrollo administrado por PSF, estaría muy en contra de eso, ya que no tenemos la infraestructura de administración para manejar ese tipo de cosas.

Eso es interesante. No pensé que fuera una probabilidad, pero sería genial tener algo mejor que http (lib).

Con la biblioteca estándar, generalmente no tenemos esa preocupación: mientras que los redistribuidores ocasionalmente rompen cosas, en un contexto comercial, los proveedores que rompen cosas que funcionan en sentido ascendente le brindan bastante influencia para que el proveedor infractor arregle las cosas.

No estoy seguro de qué apalancamiento estás hablando. He visto asegurarpip, venv y otras cosas rotas por Debian y otros redistribuidores en CPython. Sin embargo, eso es tangencial a esta discusión.

Oh, otra pregunta clave que debe responder antes de ofrecerse como voluntario para mantener realmente las cosas en la biblioteca estándar: ¿está preparado para aceptar la responsabilidad de enviar software que ayuda a impulsar la mitad de las bolsas de valores del mundo, es uno de los lenguajes más populares para la infraestructura corporativa, uno de los lenguajes más populares para la programación científica (incluido el uso para la planificación de trayectorias en misiones espaciales interplanetarias), uno de los lenguajes más populares para el desarrollo web y uno de los lenguajes clave que se emplean en las nuevas iniciativas de alfabetización informática en las instituciones educativas?

Como ya se mencionó, la mayoría de las personas actualmente involucradas no continuarían con el proyecto. Probablemente sería la única persona, pero dado mi historial con el desarrollo de CPython ascendente, no sería productivo dejar esa carga a los desarrolladores centrales existentes (y otros futuros).

Esa parte posterior al abismo de la curva de adopción de tecnología es a la que llegamos cuando decimos "sí, este enfoque ahora está lo suficientemente maduro como para que podamos empujarlo, o algo basado en él, a la biblioteca estándar para ayudar a convertirlo en una herramienta verdaderamente universal suposición".

La realidad es que esas personas nunca se pondrán al día, ¿no? La gente todavía está ejecutando software en Python 2.4 y 2.5. Los balanceadores de carga de F5 todavía solo son compatibles con Python 2.5. 2.7 estará en uso probablemente hasta el final de mi vida natural (que espero sea bastante larga). ¿Son estas realmente las personas a las que esta decisión afectará con más fuerza? Es posible que esas mismas personas que describe nunca den el salto a Python 3. Y actualmente, todavía es un _leap_. Tal vez para cuando hayan decidido considerarlo, Python 3.8, 3.9 o 4.2 estará disponible y será mucho menos complicado para ellos.

Bien, mi punto principal es que el objetivo de la inclusión de bibliotecas estándar es _muy_ diferente al de la tarea más común de proporcionar una biblioteca de código abierto para que la utilicen otros desarrolladores de código abierto. Si el equipo de solicitudes elige continuar proporcionando solo la biblioteca mantenida de forma independiente (un servicio comunitario por el que estoy inmensamente agradecido, ¡ustedes hacen un gran trabajo!), Y no respaldan un impulso para la estandarización de la API, entonces confiaremos en redistribuidores como RHEL / Fedora / CentOS, Debian / Ubuntu, ActiveState, Enthought y Continuum Analytics para recoger el módulo y estandarizarlo _ de todos modos_, de modo que la gente pueda asumir que siempre estará disponible (o al menos con la frecuencia suficiente para que lo estén feliz confiando en la API en scripts de archivo único que no están completamente empaquetados con declaraciones de dependencia apropiadas). Sin embargo, es probable que la mayoría de la documentación introductoria siga orientando a las personas a utilizar HTTP de la forma estándar de la biblioteca, por lo que si a las personas se les enseña "HTTP para Python, edición de 2001" o "HTTP para Python, edición de 2015" dependerá de si lo obtienen de un fuente "solo biblioteca estándar", o una que incluya módulos de terceros recomendados.

Sin embargo, al igual que con virtualenv y PEP 405, o Twisted + Tornado vs asyncio, o ipaddr vs ipaddress, no creo que tenga sentido incluir _requests_ en la biblioteca estándar. Por el contrario, creo que tiene más sentido respaldar la inclusión de una API _inspired_ de solicitudes que omita todo el código de compatibilidad de versiones cruzadas, el paquete de certificados, etc., etc., y simplemente trae las API predeterminadas y la documentación para manejar solicitudes HTTP autenticadas hasta 2015 normas. Luego, en 2030, estaremos quejándonos de lo arcaico que es el diseño de la API _requests_ para los estándares de 2030 ("¿HTTP? ¡¿Quién lo usa más?!?!"), Pero está bien, así es como funcionan estos ciclos (hasta el primer AJAX y luego llegó JSON, XML-RPC era el rey de la colina). Si obtiene 5 años de un diseño de API antes de que la gente comience a quejarse de que está anticuado, lo está haciendo bastante bien, 10 es impresionante y 15 es realmente espectacular.

Lo principal que se necesita para comenzar ese proceso es alguien lo suficientemente motivado por la idea de tener la API de solicitudes disponible en todas partes para defender el esfuerzo de estandarización, hacer el trabajo de implementación y apuntar a comprometerse con al menos los primeros años de mantenimiento de stdlib. La alternativa es seguir confiando en gran medida en los redistribuidores para llegar a los desarrolladores que no están dispuestos o no pueden descargar y ejecutar código arbitrario de Internet (una categoría que incluye a todos en cualquier industria con estrictos requisitos de diligencia debida regulatoria, así como a cualquier persona). trabajando para otras organizaciones con un apetito de riesgo igualmente bajo).

Con respecto a algunos de los otros puntos, nuestro apalancamiento actual con Debian es relativamente débil, mientras que el apalancamiento es mejor con la redistribución con soporte comercial, donde los clientes que pagan pueden quejarse directamente sobre las cosas que se rompen en relación con las expectativas establecidas por nosotros como comunidad de desarrollo ascendente.

En términos de ciclos de actualización, una de las cosas clave que transmite la estandarización ascendente (incluso en Python 3) es el consenso de la comunidad. Además, las bibliotecas que son "versiones posteriores" de las características de Python 3 se vuelven mucho más fáciles de justificar la agrupación con Python 2. Personalmente, todavía me gustaría ver una versión sumo de Python 2 que haga exactamente esa agrupación (unittest2, subprocess32, enum34, contexlib2 , trollius, etc.), pero esa es una batalla política completamente separada por derecho propio, especialmente en términos de persuadir a la gente de que el interés y los recursos para mantener una distribución de sumo independiente de tal redistribuidor hasta 2020 están realmente disponibles.

@dcramer, gracias por brindarnos su tiempo, se lo agradecemos mucho: corazón:

@ sigmavirus24 todo está bien :)

No tengo mucho que agregar en el frente de inclusión stdlib, aparte de eso
Sería bueno mirar algunos PEP o hilos o charlas sobre lo que debería ir
en el stdlib de Python, y tal vez para mirar hacia atrás en el último año más o menos
desarrollo desde la perspectiva de "¿cómo sería el manejo de este problema?
diferente si se tratara de un módulo de la biblioteca estándar ".

Dado que esto puede convertirse en el hilo conductor de facto que la gente mira cuando dice
"¿Qué debemos agregar / cambiar al considerar agregar solicitudes a la biblioteca estándar?",
Me gustaría dar otro grito para actualizar la jerarquía de excepciones. I
Por lo general, tienen dos preguntas cuando falla una solicitud: a) ¿Cuáles son los
¿trascendencia? y b) ¿Puedo volver a intentar la solicitud de forma segura?
Una falla en la búsqueda de DNS y una tubería rota tienen implicaciones muy diferentes,
pero las solicitudes actualmente agrupan a ambos como ConnectionError. He detallado algunos
del trabajo involucrado aquí:
https://gist.github.com/kevinburke/b98e053a4bf9835c67bb

Feliz de discutir más con las personas interesadas.

Kevin Burke
teléfono: 925.271.7005 | twentymilliseconds.com

El domingo, 25 de enero de 2015 a las 8:15 p.m., ncoghlan [email protected] escribió:

Como un ejemplo más concreto de cómo se filtra la "comunidad de código abierto"
La burbuja puede sesgar nuestra perspectiva: Jenkins tiene más del 70% de participación de mercado
en implementaciones de CI corporativas.

Sea muy, muy cauteloso al confiar en las intuiciones sobre lo que "todo el mundo
sabe ", cuando basa esa perspectiva en las personas y
organizaciones que están muy involucradas en el código abierto. La gran mayoría
del desarrollo de software sigue siendo un trabajo personalizado para satisfacer las necesidades de un
organización en particular, y la gran mayoría de las personas que lo hacen son
siguen obteniendo sus herramientas e información de proveedores comerciales en lugar de
que la comunidad de código abierto.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71413074
.

FWIW, creo que la redacción en 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.

puede malinterpretarse. Para mí, suena como una actitud peyorativa hacia la Biblioteca Estándar, que por supuesto no consiste en bibliotecas muertas. Estaba irritado y me abstuve de usar solicitudes, hasta que llegué a esta página, que es una discusión interesante y mucho mejor que la redacción anterior.