Requests: Python 3.5의 표준 라이브러리에 요청 포함 고려

예, 전체 프로세스를 단순화하고 성능을 희생하지 않기 때문입니다. 그래서 그렇습니다.

• 이것이 진화하고 성장하는 Requests의 능력에 어떤 영향을 미칠까요?
• Requests의 릴리스 빈도가 Python의 릴리스 빈도와 일치합니까? 여기서 큰 차이점은 stdlib가 요청에 적합한 홈이 아니라는 좋은 표시일 수 있습니다.

우리가 중요하게 생각하는 의견을 가진 사람들을 참조합시다.

@shazow @kevinburke @dstufft @ 알렉스 @ sigmavirus24

"표준 라이브러리는 모든 것이 죽는 곳"은 어떻게 되었습니까?

릴리스 케이던스 질문은 좋은 질문입니다. 자유롭게 진화할 수 있는 리퀘스트의 능력을 잃어버릴까 걱정된다. 즉, 아마도 requests 핵심 라이브러리가 적합할 것입니다.

내 2달러의 가치:

나는 그것을하기를 꺼려 할 것입니다. 표준 라이브러리 외부에 있다는 것은 버전 지원 및 릴리스에 대한 핵심 개발자 정책에 얽매이지 않고 사용자에게 도움이 되는 선택을 할 수 있는 자유를 주었다고 생각합니다. 이를 통해 우리는 핵심 개발의 우선 순위에 정중하게 동의하지 않을 수 있습니다. 그리고 그것은 우리가 3년 이상 동안 이 프로젝트의 생명선이었던 이데올로기적인 결정을 내릴 수 있게 해줍니다.

이 모듈이 표준 라이브러리에 들어가면 현재 핵심 팀이 표준 라이브러리로 이동하는 것이 현실이라고 생각합니다. 나는 확실히 핵심 개발인 수렁에 그것을 따라가는 데 거의 관심이 없습니다. stdlib에서 요청을 관리할 가능성이 가장 높은 사람은 @sigmavirus24 이며 그는 한 사람일 뿐입니다. 그 방향 상실은 필연적으로 시간이 지남에 따라 라이브러리 인터페이스의 침식으로 이어질 것이며, 그것은 비극적인 일이 될 것이라고 생각합니다.

표준 라이브러리에 있다는 것이 우리에게 주는 유일한 것은 우리의 시간입니다. 그것이 당신이 그것이 필요하다고 생각한다면 그것을 거기에 넣어야 하는 좋은 이유이지만, 나는 그것이 라이브러리나 파이썬 생태계를 더 좋게 만들 것이라고 우리가 가장해서는 안된다고 생각합니다.

먼저 chardet 및 urllib3을 추가하거나 종속성을 제거하지 않고 stdlib에 요청을 실제로 추가할 수 있다고 생각하지 않습니다. Python이 CA 번들을 제공하지 않으려는 경우도 있으므로 Python이 자연스럽게 이제 시스템 플랫폼 번들을 사용하도록 수정해야 합니다.

그 외에도 잘 모르겠습니다. 확실히 요청을 받는 것이 더 쉬울 것이지만 pip에 대한 내 작업의 일부는 기본적으로 stdlib에 추가할 필요 없이 요청과 같은 것을 쉽게 얻을 수 있도록 만드는 것입니다. 게다가 파이썬 stdlib에서 HTTP 요청을 하는 여러 가지 방법이 있다는 것도 다소 혼란스럽습니다. urllib와 urllib2의 통합은 Python stdlib에서 좋은 일이었고 urllib.request 및 "requests"로 이를 다시 추가하는 것도 좋은 생각이라고 생각하지 않습니다. 마지막으로 나는 그것이 실제로 많은 사람들에게 도움이 될 것이라고 생각하지 않습니다. 이것은 3.5+에만 들어갈 것이므로 요청을 사용하려는 사람은 PyPI에 있는 버전을 사용하거나 3.5를 최소 지원 Python 버전으로 만들어야 합니다. 가까운 장래에 일어날 현실적인 일이라고 생각합니다.

표준 라이브러리에 요청이 있으면 새로운 사용자에게 도움이 될 것이라고 생각하지만 전체 Python 커뮤니티에 도움이 될지는 모르겠습니다. 숙련된 사용자는 요청을 사용하고 설치하는 방법을 알고 있습니다.

다른 사람들이 쉽게 사용할 수 있는 릴리스에서 기여한 변경 사항을 오랫동안 볼 수 없다는 것을 알고 있는 다른 사람들이 기여하기를 꺼려하기 때문에 새로운 개발에 미칠 냉각 효과에 특히 관심이 있습니다.

기본적으로 설치된 Python 배포판을 만드는 중간 지점은 어떻습니까?

아니요.

요청은 나보다 앞서 언급한 여러 가지 이유로 stdlib 포함에 절대적으로 적합하지 않습니다. urllib3 종속성만으로도 완벽한 쇼스토퍼입니다. 우리는 그것이 stdlib에서 죽는 것을 원하지 않습니다.

유용한 _무엇은_ 사용자가 혈마법을 연습하지 않고도 https에 대한 간단한 get/post 요청을 수행할 수 있도록 하는 stdlib의 현재 http 리소스 위에 구축된 요청과 유사한 _basic_을 추가하는 것입니다.

또한 Python 3에만 추가될 것임을 알려드립니다. :) (그리고 Python 3.6 이전은 아님).

Kenneth 유지 관리가 지겹습니까? ;)

나는 우리가 httplib, urllib, 그리고 친구가 어떻게 되는지 말하지 않고는 이 질문에 대해 논의를 시작할 수 없다고 생각합니다. 선택의 복잡성을 해결하지 않고 요청을 추가하는 것은 "표준 라이브러리를 무시하고 요청을 사용하십시오"라는 대답보다 더 나쁘다고 생각합니다. urllib, urllib2의 시대로 회귀한 것입니다.

이 모듈이 표준 라이브러리에 들어가면 현재 핵심 팀이 표준 라이브러리로 이동하는 것이 현실이라고 생각합니다. 나는 확실히 핵심 개발인 수렁에 그것을 따라가는 데 거의 관심이 없습니다. stdlib에서 요청을 관리할 가능성이 가장 높은 사람은 @sigmavirus24 이며 그는 한 사람일 뿐입니다. 그 방향 상실은 필연적으로 시간이 지남에 따라 라이브러리 인터페이스의 침식으로 이어질 것이며, 그것은 비극적인 일이 될 것이라고 생각합니다.

나는 도움을 주기 위해 stdlib를 헤매고 싶지만, 내가 제출한 이전 패치 세트가 얼마나 많은지 알지 못하고 다른 하나는 _검토된_ 사실을 감안할 때 그 프로세스를 귀찮게 하고 싶지 않다는 사실을 감안할 때 조심스럽습니다. 나는 핵심 개발자들이 더 중요한 것들에 완전히 빠져 있다는 것을 알고 있습니다. 나는 또한 다른 누군가가 무작위로 httplib/http를 유지하기로 결정했지만 (아직) 작업에 적합하지 않다는 것을 알고 있으며 @Lukasa 와 내가 앉아 있는 패치가 있을 때 httplib에서 작업할 인내심이 없습니다. 주변에 있고, 검토되지 않고, 관심이 없습니다(라이브러리에서 긴급한 문제를 해결할 때).

아마도 계속 사용하라는 요청을 분기하는 것으로 끝날 것입니다.

요청은 나보다 앞서 언급한 여러 가지 이유로 stdlib 포함에 절대적으로 적합하지 않습니다. urllib3 종속성만으로도 완벽한 쇼스토퍼입니다. 우리는 그것이 stdlib에서 죽는 것을 원하지 않습니다.

urllib3이 구현 세부 사항이라는 것은 항상 @kennethreitz (따라서 전체 프로젝트)의 논쟁이었습니다. 요청의 가장 큰 기능 중 많은 부분이 urllib3에 의해 완전히 처리되지만 이것이 진정으로 종속성이 없는 라이브러리로 신중하게 다시 구현할 수 없다는 것을 의미하지는 않습니다.

샤르데 의존성과 관련하여: 그것은 우리(그리고 특히 저에게)에게는 그저 골치 아픈 일이었습니다. 단일 코드베이스 라이브러리에 넣을 때까지 py2와 py3에 대해 별도의 코드베이스를 사용했습니다(지난 몇 개월 동안에만 chardet으로 다시 병합됨). 라이브러리는 느리고 메모리 사용량이 많습니다. 그것은 완전히 정확하지 않으며 모델이 되는 Mozilla의 보편적인 차트는 Mozilla에 의해 거의 폐기되었습니다. 따라서 chardet을 제거하는 것은 어쨌든 순 긍정적일 것입니다.

이걸 해야 하나 말아야 하나 솔직히 걱정이 됩니다. stdlib에 있는 것은 모두 API에서만 요청이 됩니다. Python 3 채택률은 사람들이 앞으로 N년 동안 의미 있는 영향을 받을 것이라고 생각하지 않을 만큼 충분히 느립니다.

그리고 내가 말했듯이 나는 아마도 요청을 분기하거나 그 시점에서 urllib3를 직접 사용하게 될 것입니다.

나는 요전에 Guido와 이에 대해 길게 논의했습니다. 샤르데가 먼저 포함되어야 합니다. urllib3와 요청이 함께 http 패키지에 포함될 수 있다고 생각합니다.

그러나 저는 @hynek 및 @dstufft에 동의하는 경향이 있습니다. 아마도 요청은 있는 그대로일 것입니다 :)

어느 쪽이든, 공유하고 싶은 의견이 있으면 여기에서(또는 실제로는 언제든지) 공유할 수 있습니다.

:반짝이::케이크::반짝:

또한 asyncio-story가 없는 stdlib에 새 http 모듈을 추가하는 것 같습니다.
나에게 멍청이.

2015년 1월 25일 일요일 오후 1:15:51 Kenneth Reitz [email protected]
썼다:

어느 쪽이든, 공유하고 싶은 의견이 있으시면
여기에서(또는 언제든지) 공유할 수 있습니다.

[이미지: :빛나는:] [이미지: :케이크:] [이미지: :빛나는:]

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71384152
.

나는 우리가 httplib, urllib, 그리고 친구들이 어떻게 되는지 말하지 않고는 이 질문에 대해 논의를 시작할 수 있다고 생각하지 않습니다.

이것은 내 문제입니다. 현재의 혼란스러운 상황을 먼저 정리해야 한다고 생각합니다.

:+1: :금속:

분명히 하자면, stdlib에 포함하기 위해 urllib3을 다시 구현하는 것에 대한 제 위의 의견을 가볍게 여겨서는 안 됩니다. urllib3는 (아마도 10년 이상) 개발자 작업의 산물이기 때문에 그렇게 하는 데 필요한 작업량은 엄청날 것입니다.

나도 몇 년 전에 Guido와 stdlib에 urllib3를 던지는 것은 좋은 생각이 아니라는 결론을 내렸지만 이 시점에서 나는 그것에 대해 상당히 중립적입니다.

urllib3의 API는 몇 년 동안 대부분 안정적이었고 거의 완벽하게 하위 호환이 가능했습니다. 그 속도는 오늘날 stdlib의 속도보다 훨씬 느릴 수 있으며, 대부분의 변경 사항은 사소한 수정 또는 보안 개선입니다(세밀한 시간 초과/재시도와 같은 때때로 이전 버전과 호환되는 기능 추가 포함). 누군가가 정말로 urllib3를 표준 라이브러리로 가져오기를 원했다면, 나는 그것이 끔찍한 생각이라고 생각하지 않습니다. 그것은 단지 _best_ 아이디어가 아닙니다.

(urllib3와 다른 목표로 매우 다른 속도로 움직이기 때문에 요청을 말하는 것이 아닙니다.)

내 생각에 가장 좋은 아이디어는 PSF가 1-3명의 개발자를 고용하여 urllib3에서 많은 영감을 받아 HTTP/2를 지원하는 asyncio 위에 새로운 http 라이브러리를 구축하는 것입니다. , 하이퍼. 가능한 한 많은 코드를 그대로 사용하지만 일관되고 모듈식이며 재사용 가능한 방식으로 배치되는 것을 보고 싶습니다. 이상적으로는 Python 4 또는 그 이상을 대상으로 하고 모든 urllibs 및 httplibs를 제거하십시오. 나는 이것이 6-9개월의 힘든 작업이 될 것으로 예상하지만 아마도 그 이상일 것입니다.

@sigmavirus24 의 제안에 따라 누군가가 다시 작성하려고 하면 교체되었으면 하는 urllib3의 가장 나쁜 부분은 httplib에 의존한다는 것입니다. urllib3의 기능은 httplib의 단점을 해결하는 데 사용되는 많은 코드로 인해 실질적으로 제한됩니다. 이 목표에서 HTTP/2 지원이 진지하게 고려된다면 HTTP/1.1을 다시 구현하는 범위는 필요한 작업의 매우 위안이 되는 부분이 될 것입니다.

많은 파이콘(PyCons) 전에 우리 중 한 무리가 만나 당시 우리가 상상할 수 있는 이상적인 배열로 모든 조각을 리팩토링하는 완전히 새로운 http 라이브러리의 레이아웃을 화이트보드했습니다. 누군가가 이것을 시도하려고한다면 나는이 메모를 파헤 치게되어 기쁩니다.

+1 @shazow

다시 말하지만, 상당한 규모의 프로젝트를 수행할 시간과 의향이 있는 사람이 있으면 좋은 출발점이 될 수 있는 API 디자인을 스케치했습니다.

예, 요청을 종속성으로 허용하는 유일한 방법은 stdlib에 있는 경우입니다.

즉, urllib3에는 사람들이 정말로 원하는 기능이 포함되어 있으므로 stdlib에 있으면 충분합니다.

종속성을 사용하지 않습니까?

@dstufft 이것은 일반적으로 모든 사람이 urllib를 사용하는 방법을 알아내기 위해 귀찮게 할 수 없는 프로젝트에 있습니다. (사람들은 일반적으로 ssl/etc 때문에 dep로 추가하지 않지만 게으름 때문에)

@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를 중단하지 않는 것에 대해 매우 엄격했기 때문입니다. 당신이 요청의 소비자가 아니라면, 당신은 이것을 알지 못할 것입니다. 그래서 나는 당신의 무지를 개인적으로 받아들이지 않습니다.

또한 stdlib API가 매우 안정적이라고 가정하면 argparse가 Python 3.3과 3.4 사이에서 공개 API를 중단한 이유를 설명하십시오.

@sigmavirus24 당신은 이제 이것을 순수하게 API 논쟁으로 바꾸고 있습니다. 내가 포함하지 않은 이유는 변경될 수 있고 모든 사람이 사용하고 모든 사람이 다른 버전을 사용하기 때문입니다. 여러분이 API를 절대 변경하지 않는 것은 좋지만 저는 그것을 따르거나 그것이 사실이라고 가정할 의향이나 시간이 없습니다.

Python이 API도 변경한다는 사실을 알고 있습니다. 실제로 아주 자주, 때로는 매우 중요한 방식으로, 아마도 Python 3에 대해 들어본 적이 있습니까?

글쎄, 나는이 토론을 떠날거야. 제 의견을 분명히 했습니다. 무슨 소리를 하는지 잘 모르겠습니다.

대답해야 할 몇 가지 핵심 질문은 다음과 같습니다.

1. 표준 문서(튜토리얼 포함)가 어떻게 변경되기를 원하십니까? 현재 표준 라이브러리 HTTP API는 경쟁 프로토콜(예: FTP 대 HTTP)의 세부 사항을 생략하는 것이 바람직한 접근 방식으로 간주되던 시대부터 시작되었습니다. 이후 10년 반 동안 웹 개발 커뮤니티는 원격 명령 실행(SSH 또는 Windows RCP 사용) 이외의 대부분의 사용 사례에서 요청/응답 스타일 클라이언트/서버 상호 작용에 대한 선호 접근 방식으로 HTTPS+JSON에 수렴했습니다. 요청 API는 최신 Python 애플리케이션을 위한 해당 모델의 사실상 표준 클라이언트 구현입니다.
2. 요청 API가 모든 CPython 재배포 채널에 자동으로 포함되도록 사실상 표준에서 법적 표준으로 업그레이드되기를 원하십니까? 모든 "표준 도서관 전용" 교육 활동? (후자는 기업 환경에서 사용하기 위한 기준이 종종 지원 및 IP 보장을 포함하기 때문에 여전히 매우 일반적입니다. CPython에는 있지만 요청에는 그렇지 않습니다. 현재 상황에서 많은 사용자는 단순히 요청을 옵션으로 고려하지 않습니다. 사용 승인을 받기에는 너무 많은 작업이 필요합니다.)
3. API와 같은 요청을 기반으로 하여 표준 라이브러리의 어떤 다른 모듈을 개선할 수 있습니까?
4. API의 버전 독립적 구현으로 요청 자체를 변경하지 않고 유지하는 대신 Guido가 ayncio 표준화 작업에 접근한 방식과 유사하게 표준 라이브러리에 API에서 영감을 받은 새 요청을 추가하는 것이 더 낫습니까?

PSF 관리 개발 작업에 대한 아이디어가 있는 한, 저는 그런 종류의 일을 처리할 관리 인프라가 없기 때문에 그것에 대해 크게 반대합니다. PSF가 이 분야의 크라우드 펀딩 노력에 기여할 것을 제안하는 보조금 제안은 다른 이야기가 될 것입니다(검토할 특정 제안이 없으면 보장할 수 없지만 논의할 수 있는 아이디어임은 확실합니다).

일부 공급업체는 이미 요청을 재배포할 수 있지만 "요청에 대한 지원도 제공합니까?" 벤더나 플랫폼 제공자에게 물어야 하는 별도의 질문이 됩니다. 따라서 장기적인 위험 관리 맥락에서(몇 주 또는 몇 달이 아닌 몇 년과 수십 년을 생각하십시오) 이에 따라 업스트림이 지루해져서 다른 것으로 이동하는 경우 자체 지원의 위험과 책임을 감수해야 합니다. 플랫폼 제공자에서 우리가 선택할 수 있는 정도의 잠재적 감소를 받아들입니다.

표준 라이브러리를 사용하면 일반적으로 그런 걱정을 하지 않습니다. 재배포자는 때때로 문제를 해결하지만 상업적인 맥락에서 업스트림에서 작동하는 항목을 중단하는 공급업체는 문제가 되는 공급업체가 문제를 수정하도록 하는 데 상당한 레버리지를 제공합니다.

아, 표준 라이브러리에 있는 자료를 실제로 유지 관리하기 위해 자원하기 전에 대답해야 할 또 다른 핵심 질문입니다. 전 세계 증권 거래소의 절반에 전력을 공급하는 데 도움이 되는 소프트웨어를 제공하는 책임을 받아들일 준비가 되었습니까? 이 소프트웨어는 기업 인프라에서 가장 인기 있는 언어 중 하나입니다. 과학 프로그래밍에 가장 많이 사용되는 언어(행성 간 우주 임무에 대한 궤적 계획에 사용 포함), 웹 개발에 가장 널리 사용되는 언어 및 교육 기관에서 새로운 컴퓨터 활용 능력 이니셔티브에 사용되는 핵심 언어 중 하나는 무엇입니까?

매우 낮은 신뢰성 수준(종종 가동 시간 99% 미만)이 완벽하게 수용 가능한 중요하지 않은 서비스에서 일하는 사람들이 당신의 깊은 신뢰 문제가 정당하지 않으며 단지 어리석은 은폐 정치의 문제라고 불평하는 동안 그렇게 할 준비가 되어 있습니까? 그들은 스스로에 대해 신경 쓸 수 없습니까?

또한 수정하고 싶은 잘못된 가정: 대다수의 Python 프로그래머는 요청은 고사하고 pip에 대해서도 들어본 적이 없을 것입니다. 이들은 장기 지원 Linux 릴리스에서 시스템 Python에서 스크립트를 실행하는 사람들입니다. 대부분의 오픈 소스 개발자는 자신의 접근 방식을 좋은 아이디어로 만들기 위해 어떤 상황이 작용할 수 있는지 고려하지 않고 말할 수 없는 경멸을 재빨리 표현합니다.

이 커뮤니티의 채택 주기는 본질적으로 몇 년 단위로 측정됩니다. 더 빠르게 진행할 수 있을 만큼 충분히 엄격한 CI를 현재 실행하고 있는 산업은 아주 작은 부분에 불과하며, 그 부분에 있는 대부분의 사람들은 기존의 큰 폭을 가진 사람들의 우려를 들을 만큼 충분히 오랫동안 속도를 늦추는 데 관심이 없습니다. 관리하고 현대화해야 하는 인프라입니다.

기술 채택 곡선의 캐즘 이후 부분은 "예, 이 접근 방식은 이제 충분히 성숙하여 표준 라이브러리에 밀어넣거나 이를 기반으로 하는 것을 진정으로 보편적으로 만들 수 있습니다. 추정".

"오픈 소스 커뮤니티" 필터 거품이 어떻게 우리의 관점을 왜곡할 수 있는지에 대한 보다 구체적인 예로서 Jenkins는 기업 CI 배포에서 70% 이상의 시장 점유율을 보유하고 있습니다.

오픈 소스에 크게 관여하는 개인과 조직에 대한 관점을 기반으로 하는 경우 "모두가 알고 있는" 것에 대한 직관에 의존하는 데는 매우, 매우 신중해야 합니다. 대다수의 소프트웨어 개발은 ​​여전히 ​​특정 조직의 요구 사항을 충족하기 위한 맞춤형 작업이며, 그렇게 하는 대다수의 사람들은 여전히 ​​오픈 소스 커뮤니티가 아닌 상용 공급업체로부터 도구와 정보를 얻고 있습니다.

@dcramer
무슨 소리를 하는지 잘 모르겠습니다.

이 토론에 매우 적합한 언어입니다. 당신의 입장에 대해 정당한 반론을 제기할 때, 당신은 여성을 비하하기 위한 비방을 사용합니다. 코스에 대한 파. 계속해서,

@ncoghlan

Re point 1: 문서는 stdlib의 요청(유사한 요청)으로 대폭 간소화될 것이라고 생각합니다. 새로운 언어를 배울 때 내가 가장 먼저 하는 일 중 하나는 HTTP를 어떻게 하는지 알아내는 것입니다. 그 기능을 갖추면 가이드가 관계없이 혜택을 볼 수 있습니다.

Re point 2: API와 라이브러리는 사실상 대 법적으로 차이가 있습니다. API는 표준 라이브러리에서 쉽게 제공할 수 있습니다. 지원에 대한 귀하의 관심은 포함되는 요청(코드)에 더 중점을 둘 것이라고 생각합니다.

Re 포인트 3 & 4: 여기서 논의할 내용이 확실하지 않습니다. 아마도 파이썬 아이디어가 더 나을 것입니다.

PSF 관리 개발 작업에 대한 아이디어가 있는 한, 저는 그런 종류의 일을 처리할 관리 인프라가 없기 때문에 그것에 대해 크게 반대합니다.

그 흥미 롭군요. 확률이라고는 생각하지 않았지만 http(lib)보다 더 좋은 것이 있으면 좋을 것입니다.

표준 라이브러리를 사용하면 일반적으로 그런 걱정을 하지 않습니다. 재배포자는 때때로 문제를 해결하지만 상업적인 맥락에서 업스트림에서 작동하는 항목을 중단하는 공급업체는 문제가 되는 공급업체가 문제를 수정하도록 하는 데 상당한 레버리지를 제공합니다.

어떤 레버리지를 말씀하시는지 잘 모르겠습니다. 나는 CPython에서 Debian과 다른 재배포자들에 의해 파손된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, 2001년판" 또는 "파이썬용 HTTP, 2015년판"을 배웠는지 여부는 "표준 라이브러리 전용" 소스 또는 권장되는 타사 모듈을 포함하는 소스.

virtualenv 및 PEP 405, Twisted+Tornado 대 asyncio 또는 ipaddr 대 ipaddress와 마찬가지로 표준 라이브러리에 _요청 자체_를 포함하는 것이 합리적이지 않다고 생각합니다. 오히려 모든 교차 버전 호환성 코드, 인증서 번들 등을 생략하고 인증된 HTTP 요청을 처리하기 위한 기본 API 및 문서를 2015년까지 가져오는 요청 _영감_ API를 포함하는 것이 더 합리적이라고 생각합니다. 표준. 그런 다음 2030년에는 _requests_ API 디자인이 2030년 표준에 따라 얼마나 구식인지("HTTP? 누가 더 이상 사용합니까?!?!") 불평할 것입니다. 하지만 괜찮습니다. 이 주기가 작동하는 방식입니다(첫 번째 AJAX까지 그런 다음 JSON이 등장했고 XML-RPC는 언덕의 왕이었습니다). 사람들이 구식이라고 불평하기 전에 API 디자인에서 5년을 보낸다면 당신은 꽤 잘하고 있는 것이고 10년은 인상적이고 15년은 정말 장관입니다.

그 프로세스를 시작하는 데 필요한 가장 중요한 것은 표준화 노력을 지지하고 구현 작업을 수행하고 최소한 stdlib 유지 관리의 처음 몇 년에 전념하는 것을 목표로 하는 요청 API를 모든 곳에서 사용할 수 있다는 아이디어에 충분히 동기를 부여받은 사람입니다. 대안은 인터넷에서 임의의 코드를 다운로드 및 실행할 수 없는 개발자에게 도달하기 위해 재배포업체에 계속 크게 의존하는 것입니다(엄격한 규제 실사 요구 사항이 있는 모든 산업 분야의 모든 사람을 포함하는 범주는 물론 마찬가지로 위험에 대한 선호도가 낮은 다른 조직에서 일함).

다른 몇 가지 사항과 관련하여 현재 데비안의 영향력은 상대적으로 약하지만, 유료 고객이 업스트림 개발 커뮤니티로서 우리가 설정한 기대치에 비해 문제가 발생하는 것에 대해 직접 불평할 수 있는 상업적으로 지원되는 재배포의 경우 레버리지가 더 좋습니다.

업데이트 주기 측면에서 업스트림 표준화(Python 3에서도)가 전달하는 핵심 중 하나는 커뮤니티 합의입니다. 그러면 Python 3 기능의 "백포트"인 라이브러리가 Python 2와의 번들링을 정당화하기가 훨씬 쉬워집니다. 개인적으로 여전히 해당 번들링(unittest2, subprocess32, enum34, contexlib2)을 수행하는 Python 2의 스모 릴리스를 보고 싶습니다. , trollius 등), 그러나 그것은 그 자체로 완전히 별개의 정치적 싸움입니다. 특히 2020년까지 그러한 재배포자 독립 스모 유통을 유지하기 위한 관심과 자원이 실제로 이용 가능하다는 점에서 사람들을 설득하는 측면에서 그렇습니다.

@dcramer 시간을 내주셔서 감사합니다 — 정말 감사합니다 :heart:

@sigmavirus24 모두 잘

나는 stdlib 포함 전면에 추가할 것이 별로 없습니다.
일부 PEP 또는 스레드를 보거나 진행해야 할 사항에 대해 이야기하는 것이 좋습니다.
Python stdlib에서, 그리고 아마도 작년 정도를 되돌아보기 위해
"이 문제를 어떻게 처리할 것인가의 관점에서 개발
이것이 표준 라이브러리의 모듈이라면 다릅니다."

이것이 사람들이 말할 때 보는 사실상의 스레드가 될 수 있기 때문에
"stdlib에 요청을 추가할 때 무엇을 추가/변경해야 하나요?",
예외 계층을 업데이트한 것에 대해 한 번 더 외치고 싶습니다. NS
일반적으로 요청이 실패하면 두 가지 질문이 있습니다.
의미? b) 요청을 안전하게 재시도할 수 있습니까?
DNS 조회 실패와 깨진 파이프는 매우 다른 의미를 갖습니다.
그러나 요청은 현재 둘 다 ConnectionError로 그룹화합니다. 나는 몇 가지를 자세히 설명했다
여기에 관련된 작업:
https://gist.github.com/kevinburke/b98e053a4bf9835c67bb

관심있는 분들과 더 많은 토론을 하게 되어 기쁩니다.

케빈 버크
전화: 925.271.7005 | 20밀리초.com

2015년 1월 25일 일요일 오후 8시 15분에 ncoghlan [email protected]에서 다음과 같이 썼습니다.

"오픈 소스 커뮤니티"가 필터링하는 방법에 대한 보다 구체적인 예
거품은 우리의 관점을 왜곡할 수 있습니다: Jenkins는 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.

잘못 해석될 수 있습니다. 나에게 그것은 표준 라이브러리에 대한 경멸적인 태도처럼 들립니다. 물론 죽은 라이브러리로 구성되지는 않습니다. 나는 이 페이지를 방문할 때까지 짜증이 났고 요청을 사용하지 않았습니다. 이 페이지는 흥미로운 토론이며 위의 문구보다 훨씬 좋습니다.