Mailing List Archive

On Tue, 29 Mar 2022 at 00:37, Toshio Kuratomi <a.badger@gmail.com> wrote:

> One thing about talking about "make urllib more like requests" that is different than any of the other libs, though, is that requests aims to be easier to use than anything else (which I note Chris Barker called out as why he wanted urllib to be more like it). I think that's important to think about because i think ease of use is also the number one thing that the audience you talk about is also looking for.

Agreed, but one thing that I would note is that the more people ask
for changes of this sort of scope, the more this fuels the argument
that maintaining the stdlib is a lot of work. It's fairly obvious that
none of the core developers have the time or energy to invest in the
sort of urllib API change you're suggesting here, so realistically
this simply gives the impression "people don't want urllib, they want
requests". The net result is not that urllib becomes more like
requests, but rather that there's extra pressure to *drop* urllib, and
point people to requests.

Personally, I want *both* urllib and requests. I want urllib for when
I don't want a 3rd party dependency, and requests (or httpx, or
urllib3, ...) for when I can afford one. And if the cost of having
that is that urllib has a less user-friendly API, then I'm willing to
live with that.

Paul
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/77D3WHKPB2FS2JKAC3EPTPDH6UDQIAFD/
Code of Conduct: http://python.org/psf/codeofconduct/

Am 27.03.22 um 18:11 schrieb Christopher Barker:
> On Sun, Mar 27, 2022 at 3:08 AM Paul Moore <p.f.moore@gmail.com> wrote:
>
> > > 3. Overall, I think the days where "battery included" was a
> positive argument are over
> >
> > I strongly disagree.  Being able to download something and
> immediately get something to work and see results is hugely
> > rewarding; on the other hand, having to research, find, compare
> & contrast available third-party modules (especially for
> > new-comers) can be extremely discouraging.
>
>
> exactly - let's say someone needs to write some JSON for the first time.

I think the truth is somewhere in the middle. Python should include
support for commonly needed functionality. This includes all kinds of
language support (functools, collections, asyncio, wsgiref, re etc.),
common file formats like XML, JSON, tar, zip etc., OS support (os, sys,
stat etc.), basic networking (TCP/IP, making HTTP requests, sending
mail), but also basic math modules like decimal, fractions, or
statistics. I don't think it should support esoteric, niche, or long
obsolete file formats or networking protocols like FTP, sunau etc. I
also don't think that Python should come with "basic" servers that can't
be used for anything useful. The same is true for domain-specific
applications. For example, I wouldn't want a complex numerics package as
part of Python (although having some more basic data types would make
sense).

Another problem are "optional" modules like sqlite or tk/tcl. Because
they are optional, you can't depend on them being present, but you also
can't ensure their presence by "pip install"ing them.

> In fact, this is an example, I think, of where we should put some
> effort into making the included batteries better -- it's great to have
> a JSON lib built in, but it's too bad that it's not best-of-bread by
> pretty much any definition (speed, memory performance, flexibility) --
> there are quite a few feature requests open for it -- it would be nice
> to actually implement some of those. (but yes, that's a lot of work
> that someone(s) would have to do)
>
> Back to the topic at hand, rather than remove urllib, maybe it could
> be made better -- an as-easy-to-use-as-requests package in the stdlib
> would be really great.

I agree 100%. On the one hand the stdlib is missing some functionality I
would consider "basic" (for example, async file and HTTP fetching
support), on the other hand some of the existing modules would benefit
from a more modern API that makes the common case easy and the uncommon
case possible.

 - Sebastian

> email doesn't fix bugs; maintainers fix bugs. Please let us
> know *publicly* if you want to become the maintainer for a stdlib
> module and then we can support them, but if nobody is
> willing/able/ready to care for them it's irresponsible for us to keep
> shipping them to users.

At the moment, I don't have the time, experience, skill, nor involvement
with the Python project to volunteer to maintain urllib, but I would
like to take a more active role in its maintenance as a contributor such
that we continue to see it in the stdlib. This may be the second time
I've mentioned this on this thread, but please see PR#30520 on the
CPython repo (BPO-46337), which attempts to patch up a rough edge in
urlparse's scheme-based API. Feedback/review/etc on that would be
greatly appreciated, and so would some pointers on what next needs the
most work with regards to urllib as a whole. Thanks so much!

--
Lincoln Auster
they/them
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HD46JG3JT525KEGYXETX2OCR63MWIPXU/
Code of Conduct: http://python.org/psf/codeofconduct/

> On 29 Mar 2022, at 00:34, Brett Cannon <brett@python.org> wrote:
>
>
>
> On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker <pythonchb@gmail.com <mailto:pythonchb@gmail.com>> wrote:
> On Mon, Mar 28, 2022 at 11:29 AM Paul Moore <p.f.moore@gmail.com <mailto:p.f.moore@gmail.com>> wrote:
> To be honest, I feel like I'm just reiterating stuff I've said before
> here, and I think the same is true of the points I'm responding to
> ...
> (I'm not *against* going over the debate again,
> it helps make sure people haven't changed their minds, but it's
> important to be clear that none of the practical facts have changed,
> if that is the case).
>
> Maybe there's a way to make this discussion (it feels more like a discussion than debate at the moment) more productive by writing some things down. I'm not sure it's a PEP, but some kind of:
>
> "policy for the stdlib" document in which we could capture the primary points of view, places where there's consensus, etc. would be helpful to keep us retreading this over and over again.
>
> I suggest this without the bandwidth to actually shepherd the project, but if someone wants to, I think it would be a great idea.
>
> Once https://mail.python.org/archives/list/python-committers@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/ <https://mail.python.org/archives/list/python-committers@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/> is considered resolved, the next part of my "what is the stdlib" plan is to finally try to suss all of this out and more-or-less write a stdlib policy PEP so we stop talking about this. My guess it will be more of guidance about what we want the stdlib to be and thus guide what things belong in it. No ETA on that work since I also have four other big Python projects on the go right now whose work I am constantly alternating between.

Having such a policy is a good thing and helps in evolving the stdlib, but I wonder if the lack of such a document is the real problem. IMHO the main problem is that the CPython team is very small and therefore has little bandwidth for maintaining, let alone evolving, large parts of the stdlib. In that it doesn’t help that some parts of the stdlib have APIs that make it hard to make modifications (such as distutils where effectively everything is part of the public API). Shrinking the stdlib helps in the maintenance burden, but feels as a partial solution.

That said, I have no ideas on how a better stdlib development proces would look like, let alone on how to get there.

Ronald

>
> -Brett
>
>
> -CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org <mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-leave@python.org <mailto:python-dev-leave@python.org>
> https://mail.python.org/mailman3/lists/python-dev.python.org/ <https://mail.python.org/mailman3/lists/python-dev.python.org/>
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GAZAFRFVJVQZMEIHTQUJASP7VRAKA5RR/ <https://mail.python.org/archives/list/python-dev@python.org/message/GAZAFRFVJVQZMEIHTQUJASP7VRAKA5RR/>
> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org <mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-leave@python.org <mailto:python-dev-leave@python.org>
> https://mail.python.org/mailman3/lists/python-dev.python.org/ <https://mail.python.org/mailman3/lists/python-dev.python.org/>
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PC67DOLDEQXIAGXEB2QXCGS3C4B6PTCY/ <https://mail.python.org/archives/list/python-dev@python.org/message/PC67DOLDEQXIAGXEB2QXCGS3C4B6PTCY/>
> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren <ronaldoussoren@mac.com>
wrote:

>
>
> On 29 Mar 2022, at 00:34, Brett Cannon <brett@python.org> wrote:
>
>
>
> On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker <pythonchb@gmail.com>
> wrote:
>
>> On Mon, Mar 28, 2022 at 11:29 AM Paul Moore <p.f.moore@gmail.com> wrote:
>>
>>> To be honest, I feel like I'm just reiterating stuff I've said before
>>> here, and I think the same is true of the points I'm responding to
>>
>> ...
>>
>>> (I'm not *against* going over the debate again,
>>> it helps make sure people haven't changed their minds, but it's
>>> important to be clear that none of the practical facts have changed,
>>> if that is the case).
>>>
>>
>> Maybe there's a way to make this discussion (it feels more like a
>> discussion than debate at the moment) more productive by writing some
>> things down. I'm not sure it's a PEP, but some kind of:
>>
>> "policy for the stdlib" document in which we could capture the primary
>> points of view, places where there's consensus, etc. would be helpful to
>> keep us retreading this over and over again.
>>
>> I suggest this without the bandwidth to actually shepherd the project,
>> but if someone wants to, I think it would be a great idea.
>>
>
> Once
> https://mail.python.org/archives/list/python-committers@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/
> is considered resolved, the next part of my "what *is* the stdlib" plan
> is to finally try to suss all of this out and more-or-less write a stdlib
> policy PEP so we stop talking about this. My guess it will be more of
> guidance about what we want the stdlib to be and thus guide what things
> belong in it. No ETA on that work since I also have four other big Python
> projects on the go right now whose work I am constantly alternating between.
>
>
> Having such a policy is a good thing and helps in evolving the stdlib, but
> I wonder if the lack of such a document is the real problem. IMHO the
> main problem is that the CPython team is very small and therefore has
> little bandwidth for maintaining, let alone evolving, large parts of the
> stdlib. In that it doesn’t help that some parts of the stdlib have APIs
> that make it hard to make modifications (such as distutils where
> effectively everything is part of the public API). Shrinking the stdlib
> helps in the maintenance burden, but feels as a partial solution.
>

You're right that is the fundamental problem. But for me this somewhat
stems from the fact that we don't have a shared understanding of what the
stdlib *is*, and so the stdlib is a bit unbounded in its size and scope.
That leads to a stdlib which is hard to maintain. It's just like dealing
with any scarce resource: you try to cut back on your overall use as best
as you can and then become more efficient with what you must still consume;
I personally think we don't have an answer to the "must consume" part of
that sentence that leads us to "cut back" to a size we can actually keep
maintained so we don't have 1.6K open PRs
<https://github.com/python/cpython/pulls>.


> That said, I have no ideas on how a better stdlib development proces
> would look like, let alone on how to get there.
>

I did what I could when I helped get us over to GitHub and what Mariatta
helped bring to our workflow.


>
> Ronald
>
>
> -Brett
>
>
>>
>> -CHB
>>
>> --
>> Christopher Barker, PhD (Chris)
>>
>> Python Language Consulting
>> - Teaching
>> - Scientific Software Development
>> - Desktop GUI and Web Development
>> - wxPython, numpy, scipy, Cython
>> _______________________________________________
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-leave@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/GAZAFRFVJVQZMEIHTQUJASP7VRAKA5RR/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/PC67DOLDEQXIAGXEB2QXCGS3C4B6PTCY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> —
>
> Twitter / micro.blog: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
>
>

I was trying to think through how a "remote" stdlib might work. In the
process, I got to wondering if there are known "specialists" for
various current modules. Every now and then I still get assigned (or
at least made nosy) about something to do with the csv module. Is
there an official module-by-module list of maintainers?

I was thinking about this in the context of the urllib discussion.
Whether or not it might be a candidate to keep long term (as one of
the handful of modules required to build and test CPython), if there
are known maintainers of specific modules or packages, I think it
might be worthwhile to give them the chance to chime in.

Skip
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NHUDBM2NBUIRSQOYSPBCOJIW45FCY2TY/
Code of Conduct: http://python.org/psf/codeofconduct/

On 3/29/2022 4:55 PM, Skip Montanaro wrote:
> I was trying to think through how a "remote" stdlib might work. In the
> process, I got to wondering if there are known "specialists" for
> various current modules. Every now and then I still get assigned (or
> at least made nosy) about something to do with the csv module. Is
> there an official module-by-module list of maintainers?
There's the CODEOWNERS file:
https://github.com/python/cpython/blob/main/.github/CODEOWNERS

Eric

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EKNOIU54LPVM3HZJN6WZCTVQIZHOLSYL/
Code of Conduct: http://python.org/psf/codeofconduct/

>
> There's the CODEOWNERS file:
> https://github.com/python/cpython/blob/main/.github/CODEOWNERS


Thanks. Never would have thought there was such a thing. I was looking for
files with "maintain" in them. Skimming it, it would seem that most of the
stuff in Lib or Modules isn't really associated with a particular person or
small group.

Skip

On 3/29/2022 4:55 PM, Skip Montanaro wrote:
> I was trying to think through how a "remote" stdlib might work. In the
> process, I got to wondering if there are known "specialists" for
> various current modules. Every now and then I still get assigned (or
> at least made nosy) about something to do with the csv module. Is
> there an official module-by-module list of maintainers?

https://devguide.python.org/experts/

> I was thinking about this in the context of the urllib discussion.
> Whether or not it might be a candidate to keep long term (as one of
> the handful of modules required to build and test CPython), if there
> are known maintainers of specific modules or packages, I think it
> might be worthwhile to give them the chance to chime in.

I believe someone can be listed without being a coredev with merge
privileges.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NZXZMEX3RTJBYITYFQLDPDUTCS3EXQC6/
Code of Conduct: http://python.org/psf/codeofconduct/

There's also the "Experts index" in the devguide: https://devguide.python.org/experts/#expertsBest, Alex
-------- Original message --------From: Skip Montanaro <skip.montanaro@gmail.com> Date: 29/03/2022 22:36 (GMT+00:00) To: "Eric V. Smith" <eric@trueblade.com> Cc: Python Dev <python-dev@python.org> Subject: [Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module] There's the CODEOWNERS file:
https://github.com/python/cpython/blob/main/.github/CODEOWNERSThanks. Never would have thought there was such a thing. I was looking for files with "maintain" in them. Skimming it, it would seem that most of the stuff in Lib or Modules isn't really associated with a particular person or small group.Skip

I'm probably overly stressing a well understood point here that
urllib.parse is incredibly widely used and critical to many foundational
libraries in Python. But I just came across this today that:

conda is migrating from urllib3 for parsing to urllib.parse:
https://github.com/conda/conda/pull/11373

And not to mention urllib3 itself somewhat depends on urllib.parse:
https://github.com/urllib3/urllib3/search?q=urllib.parse

Damian (he/him)

On Tue, Mar 29, 2022 at 6:59 PM Alex Waygood <alex.waygood@gmail.com> wrote:

> There's also the "Experts index" in the devguide:
> https://devguide.python.org/experts/#experts
>
> Best,
> Alex
>
> -------- Original message --------
> From: Skip Montanaro <skip.montanaro@gmail.com>
> Date: 29/03/2022 22:36 (GMT+00:00)
> To: "Eric V. Smith" <eric@trueblade.com>
> Cc: Python Dev <python-dev@python.org>
> Subject: [Python-Dev] Re: Are "Batteries Included" still a Good Thing?
> [was: It's now time to deprecate the stdlib urllib module]
>
> There's the CODEOWNERS file:
>> https://github.com/python/cpython/blob/main/.github/CODEOWNERS
>
>
> Thanks. Never would have thought there was such a thing. I was looking for
> files with "maintain" in them. Skimming it, it would seem that most of the
> stuff in Lib or Modules isn't really associated with a particular person or
> small group.
>
> Skip
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/CN7SXNP2D4ML4U2OBIUC4DGQOKEYNSKE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

On Mon, 28 Mar 2022 at 20:37, Steve Dower <steve.dower@python.org> wrote:

> email doesn't fix bugs; maintainers fix bugs. Please let us know
> *publicly* if you want to become the maintainer for a stdlib module and
> then we can support them, but if nobody is willing/able/ready to care
> for them it's irresponsible for us to keep shipping them to users.


I'd like to become a maintainer for the pathlib module, if possible. I know
the code and tests inside-out, and I've been wrestling the internals for
past few Python releases. I check the bugs/PRs at least every week and help
wherever I can.

I can also look after urllib if it would help. I have much less experience
with that module vs pathlib, so I'll need to spend some time familiarizing
myself with the code and the outstanding bug reports. But I do have plenty
of experience with networking, HTTP, URLs, etc :-). I'll spend some time
reading the bug tracker to start.

Le 28/03/2022 à 18:44, Steve Dower a écrit :
> I think to most people "batteries included" doesn't necessarily mean
> "standard library," with all that implies. It just means "it came with
> the first thing that I installed" (or alternatively, "at no additional
> charge").

A point I have not seen made, is that some uses really need *standard*
batteries.

In scientific research, you'll sometimes share a data-processing script
among a large group of non-computer-specialists, who hopefully all have
*some* Python+NumPy installed: it may be a full up-to-date Conda, or it
may be "a very old version that a former colleague installed for me
years ago and now I won't update it for fear I break it". You have to
cater to all versions.

It may be more glamorous to compete with Rust and JS for "best modern
language", than with Excel for "lowest common denominator for
calculation". Still, that's a use case where Python has historically
been strong, and it's one of the reasons it works so well in the
research world.

Hopefully this use case is not forgotten, even if those
non-computer-specialists users are less likely to be involved here in
core development.

Cheers,
Baptiste
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/V4QX4ZSHSUUMVQR3CRAEMBBR6N3WGVLM/
Code of Conduct: http://python.org/psf/codeofconduct/

On 30Mar2022 1124, Barney Gale wrote:
> I'd like to become a maintainer for the pathlib module, if possible. I
> know the code and tests inside-out, and I've been wrestling the
> internals for past few Python releases. I check the bugs/PRs at least
> every week and help wherever I can.

Antoine is still active, so if he's fine with that, I'm also supportive.
You're certainly familiar enough with that module.

> I can also look after urllib if it would help. I have much less
> experience with that module vs pathlib, so I'll need to spend some time
> familiarizing myself with the code and the outstanding bug reports. But
> I do have plenty of experience with networking, HTTP, URLs, etc :-).
> I'll spend some time reading the bug tracker to start.

Please! I skim the open issues occasionally, but definitely feel out of
my depth to decide on issues (e.g. should
urlparse("http://[::1]spam:80") raise? - I have literally no idea :) ),
but feel free to nosy me on issues you think you've figured out and I
can help confirm your logic and do merges. Or if another core dev has
been helping you, keep nosying them.

Cheers,
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DRHN22EUHGYCEUHJ3GSMEYMM2BQCS3QR/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, 30 Mar 2022 12:03:58 +0100
Steve Dower <steve.dower@python.org> wrote:
> On 30Mar2022 1124, Barney Gale wrote:
> > I'd like to become a maintainer for the pathlib module, if possible. I
> > know the code and tests inside-out, and I've been wrestling the
> > internals for past few Python releases. I check the bugs/PRs at least
> > every week and help wherever I can.
>
> Antoine is still active, so if he's fine with that, I'm also supportive.
> You're certainly familiar enough with that module.

I'm entirely supportive. Huge thank you for working on pathlib!

Regards

Antoine.


_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6N7YKZVCV6TLFIMWIUVRKFMJY34JUHYJ/
Code of Conduct: http://python.org/psf/codeofconduct/

On 30Mar2022 1132, Baptiste Carvello wrote:
> Le 28/03/2022 à 18:44, Steve Dower a écrit :
>> I think to most people "batteries included" doesn't necessarily mean
>> "standard library," with all that implies. It just means "it came with
>> the first thing that I installed" (or alternatively, "at no additional
>> charge").
>
> A point I have not seen made, is that some uses really need *standard*
> batteries.

I've certainly not forgotten it, it's just every time I try to make the
point it doesn't seem to help. So until I find a clear way to argue
that, yes, a standard "datetime" value makes sense, but no, a standard
"HTTP headers dictionary" is unnecessary, I'm avoiding bringing it up
again ;)

Cheers,
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/OCY7VGDIXJAQ55XAHOCYFZOBF6O4P4I4/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, 30 Mar 2022 at 12:20, Antoine Pitrou <antoine@python.org> wrote:

> On Wed, 30 Mar 2022 12:03:58 +0100
> Steve Dower <steve.dower@python.org> wrote:
> > On 30Mar2022 1124, Barney Gale wrote:
> > > I'd like to become a maintainer for the pathlib module, if possible. I
> > > know the code and tests inside-out, and I've been wrestling the
> > > internals for past few Python releases. I check the bugs/PRs at least
> > > every week and help wherever I can.
> >
> > Antoine is still active, so if he's fine with that, I'm also supportive.
> > You're certainly familiar enough with that module.
>
> I'm entirely supportive. Huge thank you for working on pathlib!
>

Thank you Antoine, Steve. It's humbling to stand on your shoulders and
thrilling to give back to Python. If I'm successful in my application I'll
do my best to take good care of pathlib and hopefully urllib too.

These batteries ain't dead yet! :D

Best,

Barney

On Wed, 30 Mar 2022 at 12:28, Steve Dower <steve.dower@python.org> wrote:
>
> On 30Mar2022 1132, Baptiste Carvello wrote:
> > Le 28/03/2022 à 18:44, Steve Dower a écrit :
> >> I think to most people "batteries included" doesn't necessarily mean
> >> "standard library," with all that implies. It just means "it came with
> >> the first thing that I installed" (or alternatively, "at no additional
> >> charge").
> >
> > A point I have not seen made, is that some uses really need *standard*
> > batteries.
>
> I've certainly not forgotten it, it's just every time I try to make the
> point it doesn't seem to help. So until I find a clear way to argue
> that, yes, a standard "datetime" value makes sense, but no, a standard
> "HTTP headers dictionary" is unnecessary, I'm avoiding bringing it up
> again ;)

I also strongly agree with this position, and do my best to argue it.
But as you say, it is hard to draw the line.

Here's some examples, which while not exhaustive, might give a flavour
of my views:

"Obviously" things that should be in the stdlib (basic data types or
algorithms):
re, datetime, collections, enum, dataclasses, decimal, fractions
(maybe borderline), statistics, itertools, functools, pathlib

Obvious stuff that's OS related:
os, io, threading, multiprocessing, concurrent.futures,
subprocess, asyncio, urllib.request

Core services:
sys, venv, sysconfig, warnings, atexit, gc, zipimport, runpy,
importlib, marshal, pickle

Standard development tools:
argparse, pdb, cprofile, typing (arguable in some ways)

Handling of key file and data formats:
struct, csv, json, tomllib, zlib, gzip, bz2 (borderline), zipfile,
tarfile, base64

Arguable cases of file formats, but with important use cases
xml (you may not like it, but it's still used a lot)
configparser (similarly, ini-style files are used a lot, for
better or worse)
email (this is an outlier, but the packaging metadata file format
uses it, so there's a bootstrapping issue if it's not in the stdlib)

I've missed a lot out, and I'm sure people will argue most of these,
but that's sort of the point - it's *hard* to come up with a blanket
statement on how we should approach "the stdlib", because there's so
much diversity in there. That's why my starting position is that we
should retain the stdlib - sure, we can remove (and add!) stuff, but
we should do so on a case by case basis, not based on some blanket
"minimise it because we don't have the manpower or we don't want to
support it" basis.

If writing and sharing small, one-off scripts that depended on
non-stdlib packages were *significantly* easier, I might revise my
position on some of the arguable cases. PEP 582 (Python local packages
directory) might make a big difference here. But at the moment, adding
a 3rd party dependency effectively alters what you're doing from
"writing a script I can share" to "developing an application" - and
that's a *big* step for many people. Quoting Nathaniel Smith from
https://mail.python.org/archives/list/distutils-sig@python.org/message/YFJITQB37MZOPOFJJF3OAQOY4TOAFXYM/
(albeit in a slightly different context):

"""
This last point is important: as projects grow in complexity, and are
used by a wider audience, they often end up with fairly complex tool
specifications that have to be shared among a team.
"""

My argument is that relying only on the stdlib allows people putting
off the need to take that step up in complexity, and we shouldn't
dismiss how significant that is.

Paul
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LYKBB6YVZYQTJHPVRR5YMWE5D6YNSENY/
Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, 29 Mar 2022, 9:44 am Toshio Kuratomi, <a.badger@gmail.com> wrote:

> One thing about talking about "make urllib more like requests" that is
> different than any of the other libs, though, is that requests aims to be
> easier to use than anything else (which I note Chris Barker called out as
> why he wanted urllib to be more like it). I think that's important to
> think about because i think ease of use is also the number one thing that
> the audience you talk about is also looking for.
>
> Of course, figuring out whether an api like request's is actually easier
> to use than urllib or merely more featureful is open to debate.
>

There's a concrete scope difference between the two:

* requests was written as a way to make HTTP(S) requests from Python,
including authenticated JSON based API requests
* urllib was designed to work with a variety of URL schemas which may or
may not support authentication and encryption (before the rise of the web
and restrictive corporate firewalls helped HTTP become the de facto
standard for data exchange over the public internet)


I wrote more on that topic back in 2016 [1], and the gist of that article
still holds true: urllib is OK for the basic HTTP GET use case, but having
to tell urllib that you want to use HTTP-only features exposes a lot of low
level plumbing that end users ideally wouldn't have to care about.

Unfortunately, it isn't clear where a useful subset of a full-fledged HTTP
client library lies. "Make it easy to send a TLS protected JSON API POST
request with Basic authentication and check the status code of the
response" *might* qualify, but even that isn't particularly easy to define
or maintain (What about proxies? What about redirects? What about other
authentication methods?).

Thus the status quo persists - adding a fully featured HTTP client library
to the existing stdlib maintenance burden doesn't (or at least shouldn't)
strike *anyone* as a good idea, but it also isn't clear how much of the
ease of use of the existing 3rd party libraries comes from the sheer amount
of functionality they have built-in so users don't have to worry about it
themselves, which means defining something "lighter and easier to maintain
than a fully featured HTTP client library, but still easier to use than
calling in to urllib directly" isn't a viable option either.

At least with urllib present in the stdlib, it's *possible* to share "No
dependency" recipes for crafting particular HTTP requests, even though the
default recommendation remains to grab a higher level 3rd party library
instead of rolling your own solution.

Cheers,
Nick.


[1]
https://www.curiousefficiency.org/posts/2016/08/what-problem-does-it-solve.html






> -toshio
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4ZQC4H7HD3UXFT3CONU64YPOQBSPUTVY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

On 3/30/2022 12:32 PM, Baptiste Carvello wrote:
> Le 28/03/2022 à 18:44, Steve Dower a écrit :
>> I think to most people "batteries included" doesn't necessarily mean
>> "standard library," with all that implies. It just means "it came with
>> the first thing that I installed" (or alternatively, "at no additional
>> charge").
>
> A point I have not seen made, is that some uses really need *standard*
> batteries.
>
> In scientific research, you'll sometimes share a data-processing script
> among a large group of non-computer-specialists, who hopefully all have
> *some* Python+NumPy installed: it may be a full up-to-date Conda, or it
> may be "a very old version that a former colleague installed for me
> years ago and now I won't update it for fear I break it". You have to
> cater to all versions.
>
> It may be more glamorous to compete with Rust and JS for "best modern
> language", than with Excel for "lowest common denominator for
> calculation". Still, that's a use case where Python has historically
> been strong, and it's one of the reasons it works so well in the
> research world.
>
> Hopefully this use case is not forgotten, even if those
> non-computer-specialists users are less likely to be involved here in
> core development.
>
> Cheers,
> Baptiste


This is a use case in which I am very interested. Reproducibility is
extremely important in my field as well. However, I don't think that any
solution offered by the standard python distribution will serve this
need, while still allowing the language to evolve.
The conda virtual environment mechanism, with carefully specified
package versions is a useful approach, but does not cover differences in
results owing to the user's OS, architecture, libraries, etc.
Among the alternatives, solutions based on containers are probably the
best bet when reproducibility is essential.

-gyro
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2DGEWKHKKSHSYYFJBRJUO7VLUMOW456Z/
Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Mar 29, 2022, 10:55 AM Brett Cannon <brett@python.org> wrote:

>
>
> On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren <ronaldoussoren@mac.com>
> wrote:
>
>>
>>
>> On 29 Mar 2022, at 00:34, Brett Cannon <brett@python.org> wrote:
>>
>>
>>
>> On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker <pythonchb@gmail.com>
>> wrote:
>>
>>> On Mon, Mar 28, 2022 at 11:29 AM Paul Moore <p.f.moore@gmail.com> wrote:
>>>
>>>>
>>>>
>> Having such a policy is a good thing and helps in evolving the stdlib,
>> but I wonder if the lack of such a document is the real problem. IMHO the
>> main problem is that the CPython team is very small and therefore has
>> little bandwidth for maintaining, let alone evolving, large parts of the
>> stdlib. In that it doesn’t help that some parts of the stdlib have APIs
>> that make it hard to make modifications (such as distutils where
>> effectively everything is part of the public API). Shrinking the stdlib
>> helps in the maintenance burden, but feels as a partial solution.
>>
>
> You're right that is the fundamental problem. But for me this somewhat
> stems from the fact that we don't have a shared understanding of what the
> stdlib *is*, and so the stdlib is a bit unbounded in its size and scope.
> That leads to a stdlib which is hard to maintain. It's just like dealing
> with any scarce resource: you try to cut back on your overall use as best
> as you can and then become more efficient with what you must still consume;
> I personally think we don't have an answer to the "must consume" part of
> that sentence that leads us to "cut back" to a size we can actually keep
> maintained so we don't have 1.6K open PRs
> <https://github.com/python/cpython/pulls>.
>

One of the things that's often missed in discussions is that a *good*
policy document can also help grow the number of maintainers.

As just one example, i found two interesting items in the discussion
started by Skip about determining what modules don't have maintainers just
downstream if this. (1) There's a file which matches maintainers to modules
in the stdlib (this is documented but i only found out about it a few years
ago and Skip, who's been around even longer than me didn't know about it
either... So this means something about how our policy docs are currently
structured could be improved). (2) Terry brought up that you don't have to
be a core maintainer in order to take up ownership of something in the
stdlib. That's awesome! But this is definitely something i didn't know.
I've been "focusing"[1] on becoming a core maintainer because i thought
that was a prerequisite to getting anything done in the stdlib. Knowing
that getting involved with stdlib maintenance is different could be vastly
helpful.

[1] focusing is the wrong word... It expresses the feeling of "directed
action" correctly but doesn't convey the lack of activity that sprinkles my
attempts. Nor does it account for discouragement, helplessness, and
imposter-y feelings which are the reasons for that lack.

-toshio

On Wed, Mar 30, 2022 at 4:53 AM Barney Gale <barney.gale@gmail.com> wrote:

> On Wed, 30 Mar 2022 at 12:20, Antoine Pitrou <antoine@python.org> wrote:
>
>> On Wed, 30 Mar 2022 12:03:58 +0100
>> Steve Dower <steve.dower@python.org> wrote:
>> > On 30Mar2022 1124, Barney Gale wrote:
>> > > I'd like to become a maintainer for the pathlib module, if possible.
>> I
>> > > know the code and tests inside-out, and I've been wrestling the
>> > > internals for past few Python releases. I check the bugs/PRs at least
>> > > every week and help wherever I can.
>> >
>> > Antoine is still active, so if he's fine with that, I'm also
>> supportive.
>> > You're certainly familiar enough with that module.
>>
>> I'm entirely supportive. Huge thank you for working on pathlib!
>>
>
> Thank you Antoine, Steve. It's humbling to stand on your shoulders and
> thrilling to give back to Python. If I'm successful in my application I'll
> do my best to take good care of pathlib and hopefully urllib too.
>

The first step is to get triage permissions:
https://devguide.python.org/triaging/?highlight=triage#python-triage-team .
We can't add anyone to the CODEOWNERS file unless you have write
permissions, which means becoming a core dev. I have added myself to
CODEOWNERS for pathlib and I will try to remember to @ mention you on
things, Barney (https://github.com/python/cpython/pull/32202).

Antoine, I left you out of my PR for CODEOWNERS just because I thought it
was presumptuous to add anyone to more GitHub notifications without their
permission.


>
> These batteries ain't dead yet! :D
>

Definitely not all of them. ????

-Brett


>
> Best,
>
> Barney
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RWVLBPUYNCLCJUYKFR2GWU3V5IT55UCG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

On Wed, Mar 30, 2022, 12:02 PM Toshio Kuratomi <a.badger@gmail.com> wrote:

>
> As just one example, i found two interesting items in the discussion
> started by Skip about determining what modules don't have maintainers just
> downstream if this.
>

Age in snake years doesn't necessarily correlate well with one's desire to
take a deep dive into the documentation. Just sayin'... <wink> These
answers might have been there waiting for a more diligent search on my part.

Skip

>

On Tue, Mar 29, 2022 at 11:55 AM Brett Cannon <brett@python.org> wrote:
> You're right that is the fundamental problem. But for me this somewhat stems from the fact that we don't have a shared understanding of what the stdlib is, and so the stdlib is a bit unbounded in its size and scope. That leads to a stdlib which is hard to maintain. It's just like dealing with any scarce resource: you try to cut back on your overall use as best as you can and then become more efficient with what you must still consume; I personally think we don't have an answer to the "must consume" part of that sentence that leads us to "cut back" to a size we can actually keep maintained so we don't have 1.6K open PRs.

This sent me down a rabbit hole of trying to analyze the PRs to see
where things are failing. Using a couple libraries from PyPI
(pygithub and gitignore_parser) I've mined out some interesting
things. Some of the lines in CODEOWNERS are not matching what people
think they are matching so notifications are being missed. The
"partial matches" are PRs which have at least one matching file in
CODEOWNERS so I think that those people should have been notified as
well as those where the entire changeset matches via CODEOWNERS.

I'm still fine tuning the script, so if more detail is desired (or
some other ignorable entries like /Misc/NEWS.d/ or /**/clinic/*.h)
please give feedback.

So with that, here are some results:

== PR Totals ========
core developers: 281
triage team: 89
draft PRs: 37
CODEOWNERS: 139
partial matches: 653
orphans: 396
-----
Total PRs: 1595

Of the files changed in all of the PRs, the following that do not
match via CODEOWNERS:
-- Core (/Grammar/, /Include/, /Objects/, /Python/) that should always
be maintained
Include/Python.h
Include/bltinmodule.h
Include/boolobject.h
Include/buffer.h
Include/bytes_methods.h
Include/ceval.h
Include/cpython/code.h
Include/cpython/dictobject.h
Include/cpython/fileutils.h
Include/cpython/object.h
Include/cpython/pyerrors.h
Include/cpython/pystate.h
Include/cpython/pythonrun.h
Include/cpython/sysmodule.h
Include/descrobject.h
Include/exports.h
Include/internal/pycore_atomic.h
Include/internal/pycore_bitutils.h
Include/internal/pycore_dict.h
Include/internal/pycore_format.h
Include/internal/pycore_global_strings.h
Include/internal/pycore_interp.h
Include/internal/pycore_object.h
Include/internal/pycore_pathconfig.h
Include/internal/pycore_pylifecycle.h
Include/internal/pycore_runtime.h
Include/internal/pycore_runtime_init.h
Include/internal/pycore_sysmodule.h
Include/methodobject.h
Include/modsupport.h
Include/moduleobject.h
Include/object.h
Include/obmalloc.h
Include/opcode.h
Include/opcode_names.h
Include/py_curses.h
Include/pydtrace.h
Include/pyerrors.h
Include/pymath.h
Include/pyport.h
Include/pyportosf.h
Include/pystate.h
Include/pystrtod.h
Include/pythread.h
Include/structmember.h
Objects/abstract.c
Objects/boolobject.c
Objects/bytearrayobject.c
Objects/bytes_methods.c
Objects/bytesobject.c
Objects/classobject.c
Objects/complexobject.c
Objects/descrobject.c
Objects/fileobject.c
Objects/funcobject.c
Objects/genericaliasobject.c
Objects/listobject.c
Objects/longobject.c
Objects/memoryobject.c
Objects/methodobject.c
Objects/moduleobject.c
Objects/namespaceobject.c
Objects/object.c
Objects/obmalloc.c
Objects/picklebufobject.c
Objects/rangeobject.c
Objects/sliceobject.c
Objects/stringlib/split.h
Objects/structseq.c
Objects/tupleobject.c
Objects/unicodectype.c
Objects/unicodeobject.c
Objects/unicodetype_db.h
Objects/unionobject.c
Objects/weakrefobject.c
Python/Python-ast.c
Python/_warnings.c
Python/bltinmodule.c
Python/ceval_gil.h
Python/codecs.c
Python/condvar.h
Python/dtoa.c
Python/errors.c
Python/fileutils.c
Python/formatter_unicode.c
Python/getargs.c
Python/hashtable.c
Python/importlib.h
Python/importlib_external.h
Python/initconfig.c
Python/makeopcodetargets.py
Python/modsupport.c
Python/opcode_targets.h
Python/pathconfig.c
Python/preconfig.c
Python/pylifecycle.c
Python/pystate.c
Python/pystrtod.c
Python/structmember.c
Python/symtable.c
Python/sysmodule.c
Python/thread_nt.h
Python/thread_pthread.h

-- Truly Orphaned
.azure-pipelines/ci.yml
.azure-pipelines/libffi-build.yml
.azure-pipelines/pr
.azure-pipelines/pr.yml
.azure-pipelines/windows-steps.yml
.github/workflows/build.yml
.github/workflows/build_msi.yml
.github/workflows/deploy-previews.yml
.github/workflows/doc.yml
.github/workflows/verify-bundled-wheels.yml
Doc/c-api/arg.rst
Doc/c-api/dict.rst
Doc/c-api/init.rst
Doc/c-api/intro.rst
Doc/c-api/long.rst
Doc/c-api/object.rst
Doc/c-api/structures.rst
Doc/c-api/type.rst
Doc/c-api/typeobj.rst
Doc/c-api/unicode.rst
Doc/conf.py
Doc/data/refcounts.dat
Doc/extending/embedding.rst
Doc/extending/extending.rst
Doc/extending/newtypes.rst
Doc/extending/newtypes_tutorial.rst
Doc/extending/windows.rst
Doc/glossary.rst
Doc/howto/functional.rst
Doc/includes/custom.c
Doc/includes/custom2.c
Doc/includes/custom3.c
Doc/includes/custom4.c
Doc/includes/sqlite3/blob.py
Doc/includes/sqlite3/blob_with.py
Doc/includes/sublist.c
Doc/library/2to3.rst
Doc/library/__main__.rst
Doc/library/abc.rst
Doc/library/aifc.rst
Doc/library/argparse.rst
Doc/library/array.rst
Doc/library/asyncio-tutorial/async-functions.rst
Doc/library/asyncio-tutorial/case-study-chat-client-cli.rst
Doc/library/asyncio-tutorial/case-study-chat-server.rst
Doc/library/asyncio-tutorial/client05.py
Doc/library/asyncio-tutorial/index.rst
Doc/library/asyncio-tutorial/pttest.py
Doc/library/asyncio-tutorial/running-async-functions.rst
Doc/library/asyncio-tutorial/server01.py
Doc/library/asyncio-tutorial/server02.py
Doc/library/asyncio-tutorial/server03.py
Doc/library/asyncio-tutorial/server04.py
Doc/library/asyncio-tutorial/server05.py
Doc/library/asyncio-tutorial/server20.py
Doc/library/asyncio-tutorial/utils01.py
Doc/library/asyncio-tutorial/utils20.py
Doc/library/base64.rst
Doc/library/bdb.rst
Doc/library/cmd.rst
Doc/library/code.rst
Doc/library/codecs.rst
Doc/library/concurrent.futures.rst
Doc/library/configparser.rst
Doc/library/crypt.rst
Doc/library/csv.rst
Doc/library/ctypes.rst
Doc/library/curses.ascii.rst
Doc/library/curses.panel.rst
Doc/library/curses.rst
Doc/library/difflib.rst
Doc/library/dis.rst
Doc/library/distutils.rst
Doc/library/doctest.rst
Doc/library/ensurepip.rst
Doc/library/errno.rst
Doc/library/exceptions.rst
Doc/library/fileinput.rst
Doc/library/formatter.rst
Doc/library/fractions.rst
Doc/library/ftplib.rst
Doc/library/functions.rst
Doc/library/getpass.rst
Doc/library/gettext.rst
Doc/library/gzip.rst
Doc/library/http.client.rst
Doc/library/http.cookiejar.rst
Doc/library/http.cookies.rst
Doc/library/http.rst
Doc/library/http.server.rst
Doc/library/idle.rst
Doc/library/importlib.metadata.rst
Doc/library/importlib.rst
Doc/library/inspect.rst
Doc/library/io.rst
Doc/library/ipaddress.rst
Doc/library/locale.rst
Doc/library/math.rst
Doc/library/mmap.rst
Doc/library/multiprocessing.rst
Doc/library/netrc.rst
Doc/library/numbers.rst
Doc/library/operator.rst
Doc/library/os.path.rst
Doc/library/os.rst
Doc/library/pathlib.rst
Doc/library/pdb.rst
Doc/library/pickle.rst
Doc/library/pkgutil.rst
Doc/library/platform.rst
Doc/library/plistlib.rst
Doc/library/profile.rst
Doc/library/pyexpat.rst
Doc/library/re.rst
Doc/library/reprlib.rst
Doc/library/rlcompleter.rst
Doc/library/runpy.rst
Doc/library/sched.rst
Doc/library/secrets.rst
Doc/library/selectors.rst
Doc/library/shlex.rst
Doc/library/shutil.rst
Doc/library/signal.rst
Doc/library/site.rst
Doc/library/socket.rst
Doc/library/socketserver.rst
Doc/library/ssl.rst
Doc/library/stat.rst
Doc/library/stdtypes.rst
Doc/library/string.rst
Doc/library/struct.rst
Doc/library/subprocess.rst
Doc/library/sunau.rst
Doc/library/sys.rst
Doc/library/telnetlib.rst
Doc/library/tempfile.rst
Doc/library/test.rst
Doc/library/textwrap.rst
Doc/library/timeit.rst
Doc/library/tkinter.dnd.rst
Doc/library/tkinter.font.rst
Doc/library/tkinter.rst
Doc/library/trace.rst
Doc/library/traceback.rst
Doc/library/tty.rst
Doc/library/unicodedata.rst
Doc/library/unittest.mock-examples.rst
Doc/library/unittest.mock.rst
Doc/library/unittest.rst
Doc/library/urllib.parse.rst
Doc/library/urllib.request.rst
Doc/library/warnings.rst
Doc/library/wave.rst
Doc/library/weakref.rst
Doc/library/winreg.rst
Doc/library/wsgiref.rst
Doc/library/xml.dom.pulldom.rst
Doc/library/xml.etree.elementtree.rst
Doc/library/xml.sax.handler.rst
Doc/library/zipfile.rst
Doc/library/zlib.rst
Doc/license.rst
Doc/reference/compound_stmts.rst
Doc/reference/datamodel.rst
Doc/reference/executionmodel.rst
Doc/reference/expressions.rst
Doc/reference/import.rst
Doc/reference/lexical_analysis.rst
Doc/reference/simple_stmts.rst
Doc/requirements.txt
Doc/tools/extensions/pyspecific.py
Doc/tools/extensions/unidata_version.py
Doc/tutorial/appendix.rst
Doc/tutorial/errors.rst
Doc/tutorial/inputoutput.rst
Doc/tutorial/interactive.rst
Doc/tutorial/modules.rst
Doc/tutorial/stdlib.rst
Doc/using/cmdline.rst
Doc/using/windows.rst
Lib/__init__.py
Lib/_dummy_thread.py
Lib/_py_abc.py
Lib/_pyio.py
Lib/_weakrefset.py
Lib/abc.py
Lib/aifc.py
Lib/argparse.py
Lib/asyncio/__main__.py
Lib/asyncio/base_events.py
Lib/asyncio/base_subprocess.py
Lib/asyncio/events.py
Lib/asyncio/futures.py
Lib/asyncio/locks.py
Lib/asyncio/proactor_events.py
Lib/asyncio/runners.py
Lib/asyncio/selector_events.py
Lib/asyncio/sslproto.py
Lib/asyncio/streams.py
Lib/asyncio/subprocess.py
Lib/asyncio/tasks.py
Lib/asyncio/unix_events.py
Lib/asyncio/windows_events.py
Lib/asyncore.py
Lib/base64.py
Lib/bdb.py
Lib/cProfile.py
Lib/cmd.py
Lib/collections/__init__.py
Lib/compileall.py
Lib/concurrent/futures/_base.py
Lib/concurrent/futures/process.py
Lib/concurrent/futures/thread.py
Lib/configparser.py
Lib/crypt.py
Lib/csv.py
Lib/ctypes/__init__.py
Lib/ctypes/_aix.py
Lib/ctypes/macholib/dyld.py
Lib/ctypes/macholib/dylib.py
Lib/ctypes/macholib/framework.py
Lib/ctypes/test/test_callbacks.py
Lib/ctypes/test/test_find.py
Lib/ctypes/test/test_functions.py
Lib/ctypes/test/test_loading.py
Lib/ctypes/test/test_macholib.py
Lib/ctypes/test/test_pep3118.py
Lib/ctypes/test/test_python_api.py
Lib/ctypes/test/test_refcounts.py
Lib/ctypes/test/test_structures.py
Lib/ctypes/test/test_win32.py
Lib/ctypes/util.py
Lib/curses/textpad.py
Lib/difflib.py
Lib/dis.py
Lib/distutils/_msvccompiler.py
Lib/distutils/ccompiler.py
Lib/distutils/command/build_ext.py
Lib/distutils/tests/test_build_ext.py
Lib/distutils/tests/test_check.py
Lib/distutils/tests/test_dist.py
Lib/distutils/tests/test_sdist.py
Lib/distutils/tests/test_sysconfig.py
Lib/distutils/version.py
Lib/doctest.py
Lib/email/_header_value_parser.py
Lib/email/contentmanager.py
Lib/email/feedparser.py
Lib/email/generator.py
Lib/email/header.py
Lib/email/message.py
Lib/email/mime/signed.py
Lib/email/mime/text.py
Lib/email/parser.py
Lib/email/policy.py
Lib/email/utils.py
Lib/encodings/aliases.py
Lib/encodings/cp1250.py
Lib/encodings/cp1251.py
Lib/encodings/cp1252.py
Lib/encodings/cp1253.py
Lib/encodings/cp1254.py
Lib/encodings/cp1255.py
Lib/encodings/cp1256.py
Lib/encodings/cp1257.py
Lib/encodings/cp1258.py
Lib/encodings/cp874.py
Lib/encodings/idna.py
Lib/encodings/punycode.py
Lib/encodings/undefined.py
Lib/encodings/utf_16.py
Lib/encodings/utf_32.py
Lib/ensurepip/__init__.py
Lib/ensurepip/_bundled/.gitignore
Lib/ensurepip/_bundled/pip-19.0.3-py2.py3-none-any.whl
Lib/ensurepip/_bundled/setuptools-40.8.0-py2.py3-none-any.whl
Lib/ensurepip/_bundler.py
Lib/ensurepip/bundle.py
Lib/fileinput.py
Lib/fnmatch.py
Lib/fractions.py
Lib/ftplib.py
Lib/genericpath.py
Lib/getpass.py
Lib/gettext.py
Lib/gzip.py
Lib/http/__init__.py
Lib/http/client.py
Lib/http/cookiejar.py
Lib/http/cookies.py
Lib/http/server.py
Lib/idlelib/Icons/debug_current.gif
Lib/idlelib/Icons/debug_go.gif
Lib/idlelib/Icons/debug_go_disabled.gif
Lib/idlelib/Icons/debug_line.gif
Lib/idlelib/Icons/debug_out.gif
Lib/idlelib/Icons/debug_out_disabled.gif
Lib/idlelib/Icons/debug_over.gif
Lib/idlelib/Icons/debug_over_disabled.gif
Lib/idlelib/Icons/debug_prefs.gif
Lib/idlelib/Icons/debug_prefs_disabled.gif
Lib/idlelib/Icons/debug_step.gif
Lib/idlelib/Icons/debug_step_disabled.gif
Lib/idlelib/Icons/debug_stop.gif
Lib/idlelib/Icons/debug_stop_disabled.gif
Lib/idlelib/ParenClose.py
Lib/idlelib/README.txt
Lib/idlelib/config-extensions.def
Lib/idlelib/config-keys.def
Lib/idlelib/config-main.def
Lib/idlelib/config.py
Lib/idlelib/configdialog.py
Lib/idlelib/debugger.py
Lib/idlelib/debugger_r.py
Lib/idlelib/dynoption.py
Lib/idlelib/editor.py
Lib/idlelib/filelist.py
Lib/idlelib/help.html
Lib/idlelib/idle_test/htest.py
Lib/idlelib/idle_test/test_calltip.py
Lib/idlelib/idle_test/test_config.py
Lib/idlelib/idle_test/test_configdialog.py
Lib/idlelib/idle_test/test_debugger.py
Lib/idlelib/idle_test/test_editor.py
Lib/idlelib/idle_test/test_parenclose.py
Lib/idlelib/idle_test/test_query.py
Lib/idlelib/idle_test/test_scrolledlist.py
Lib/idlelib/idle_test/test_textview.py
Lib/idlelib/iomenu.py
Lib/idlelib/mainmenu.py
Lib/idlelib/navigatebar.py
Lib/idlelib/pyshell.py
Lib/idlelib/query.py
Lib/idlelib/replace.py
Lib/idlelib/run.py
Lib/idlelib/scrolledlist.py
Lib/idlelib/search.py
Lib/idlelib/textview.py
Lib/imghdr.py
Lib/importlib/_bootstrap_external.py
Lib/importlib/abc.py
Lib/inspect.py
Lib/ipaddress.py
Lib/json/__init__.py
Lib/json/decoder.py
Lib/json/encoder.py
Lib/json/scanner.py
Lib/json/tool.py
Lib/lib2to3/tests/support.py
Lib/lib2to3/tests/test_parser.py
Lib/linecache.py
Lib/locale.py
Lib/logging/__init__.py
Lib/logging/config.py
Lib/logging/handlers.py
Lib/modulefinder.py
Lib/multiprocessing/__init__.py
Lib/multiprocessing/connection.py
Lib/multiprocessing/dummy/__init__.py
Lib/multiprocessing/forkserver.py
Lib/multiprocessing/heap.py
Lib/multiprocessing/managers.py
Lib/multiprocessing/pool.py
Lib/multiprocessing/popen_fork.py
Lib/multiprocessing/popen_forkserver.py
Lib/multiprocessing/popen_spawn_posix.py
Lib/multiprocessing/popen_spawn_win32.py
Lib/multiprocessing/process.py
Lib/multiprocessing/reduction.py
Lib/multiprocessing/resource_tracker.py
Lib/multiprocessing/spawn.py
Lib/multiprocessing/synchronize.py
Lib/multiprocessing/util.py
Lib/netrc.py
Lib/ntpath.py
Lib/numbers.py
Lib/opcode.py
Lib/os.py
Lib/pathlib.py
Lib/pdb.py
Lib/pickle.py
Lib/pickletools.py
Lib/pkgutil.py
Lib/platform.py
Lib/plistlib.py
Lib/pprint.py
Lib/profile.py
Lib/pstats.py
Lib/pty.py
Lib/pyclbr.py
Lib/pydoc.py
Lib/pydoc_data/topics.py
Lib/quopri.py
Lib/re.py
Lib/reprlib.py
Lib/rlcompleter.py
Lib/runpy.py
Lib/sched.py
Lib/selectors.py
Lib/shelve.py
Lib/shlex.py
Lib/shutil.py
Lib/site.py
Lib/sndhdr.py
Lib/socket.py
Lib/socketserver.py
Lib/sqlite3/dbapi2.py
Lib/sqlite3/dump.py
Lib/sqlite3/test/dbapi.py
Lib/sqlite3/test/regression.py
Lib/sqlite3/test/test_dump.py
Lib/sqlite3/test/test_namedrow.py
Lib/sre_compile.py
Lib/sre_constants.py
Lib/ssl.py
Lib/stat.py
Lib/string.py
Lib/sunau.py
Lib/sysconfig.py
Lib/tabnanny.py
Lib/telnetlib.py
Lib/tempfile.py
Lib/test/_test_multiprocessing.py
Lib/test/_typed_dict_helper.py
Lib/test/ann_module.py
Lib/test/audiodata/pluck-pcm24-ext.wav
Lib/test/audiotests.py
Lib/test/audit-tests.py
Lib/test/clinic.test
Lib/test/dataclass_forward_ref.py
Lib/test/dataclass_forward_ref_child.py
Lib/test/dataclass_forward_ref_str.py
Lib/test/final_a.py
Lib/test/final_b.py
Lib/test/imghdrdata/python.jpg
Lib/test/imghdrdata/python2.jpeg
Lib/test/inspect_fodder.py
Lib/test/libregrtest/refleak.py
Lib/test/libregrtest/runtest.py
Lib/test/libregrtest/win_utils.py
Lib/test/list_tests.py
Lib/test/mod_generics_cache.py
Lib/test/pickletester.py
Lib/test/sndhdrdata/input1.bad
Lib/test/sndhdrdata/input2.bad
Lib/test/string_tests.py
Lib/test/support/__init__.py
Lib/test/test__opcode.py
Lib/test/test__xxsubinterpreters.py
Lib/test/test_abc.py
Lib/test/test_aifc.py
Lib/test/test_argparse.py
Lib/test/test_array.py
Lib/test/test_ast.py
Lib/test/test_asyncgen.py
Lib/test/test_asyncio/test_base_events.py
Lib/test/test_asyncio/test_events.py
Lib/test/test_asyncio/test_futures.py
Lib/test/test_asyncio/test_futures2.py
Lib/test/test_asyncio/test_proactor_events.py
Lib/test/test_asyncio/test_selector_events.py
Lib/test/test_asyncio/test_sslproto.py
Lib/test/test_asyncio/test_streams.py
Lib/test/test_asyncio/test_subprocess.py
Lib/test/test_asyncio/test_tasks.py
Lib/test/test_asyncio/test_unix_events.py
Lib/test/test_asyncio/test_unix_pipes.py
Lib/test/test_asyncio/utils.py
Lib/test/test_audioop.py
Lib/test/test_audit.py
Lib/test/test_base64.py
Lib/test/test_bdb.py
Lib/test/test_buffer.py
Lib/test/test_builtin.py
Lib/test/test_bytes.py
Lib/test/test_bz2.py
Lib/test/test_c_locale_coercion.py
Lib/test/test_calendar.py
Lib/test/test_capi.py
Lib/test/test_cmd.py
Lib/test/test_cmd_line.py
Lib/test/test_cmd_line_script.py
Lib/test/test_codecs.py
Lib/test/test_compileall.py
Lib/test/test_concurrent_futures.py
Lib/test/test_configparser.py
Lib/test/test_coroutines.py
Lib/test/test_cprofile.py
Lib/test/test_crypt.py
Lib/test/test_csv.py
Lib/test/test_curses.py
Lib/test/test_decorators.py
Lib/test/test_descr.py
Lib/test/test_dis.py
Lib/test/test_doctest.py
Lib/test/test_dynamicclassattribute.py
Lib/test/test_email/test__header_value_parser.py
Lib/test/test_email/test_contentmanager.py
Lib/test/test_email/test_defect_handling.py
Lib/test/test_email/test_generator.py
Lib/test/test_email/test_headerregistry.py
Lib/test/test_email/test_message.py
Lib/test/test_email/test_multipart_signed.py
Lib/test/test_email/test_parser.py
Lib/test/test_email/test_pickleable.py
Lib/test/test_email/test_policy.py
Lib/test/test_embed.py
Lib/test/test_ensurepip.py
Lib/test/test_faulthandler.py
Lib/test/test_fileinput.py
Lib/test/test_fileio.py
Lib/test/test_float.py
Lib/test/test_fnmatch.py
Lib/test/test_format.py
Lib/test/test_fractions.py
Lib/test/test_future.py
Lib/test/test_gc.py
Lib/test/test_gdb.py
Lib/test/test_genericalias.py
Lib/test/test_genericpath.py
Lib/test/test_getargs2.py
Lib/test/test_getpass.py
Lib/test/test_gettext.py
Lib/test/test_grp.py
Lib/test/test_gzip.py
Lib/test/test_hmac.py
Lib/test/test_http/test_http.py
Lib/test/test_http_cookiejar.py
Lib/test/test_http_cookies.py
Lib/test/test_httplib.py
Lib/test/test_httpservers.py
Lib/test/test_imghdr.py
Lib/test/test_import/__init__.py
Lib/test/test_importlib/extension/test_loader.py
Lib/test/test_importlib/fixtures.py
Lib/test/test_importlib/import_/test_path.py
Lib/test/test_importlib/test_abc.py
Lib/test/test_importlib/test_main.py
Lib/test/test_importlib/test_metadata_api.py
Lib/test/test_importlib/test_util.py
Lib/test/test_inspect.py
Lib/test/test_io.py
Lib/test/test_ipaddress.py
Lib/test/test_json/test_decode.py
Lib/test/test_json/test_dump.py
Lib/test/test_json/test_indent.py
Lib/test/test_json/test_separators.py
Lib/test/test_json/test_speedups.py
Lib/test/test_json/test_tool.py
Lib/test/test_linecache.py
Lib/test/test_list.py
Lib/test/test_lltrace.py
Lib/test/test_locale.py
Lib/test/test_lzma.py
Lib/test/test_memoryio.py
Lib/test/test_memoryview.py
Lib/test/test_minidom.py
Lib/test/test_mmap.py
Lib/test/test_module.py
Lib/test/test_modulefinder.py
Lib/test/test_multiprocessing_dummy.py
Lib/test/test_netrc.py
Lib/test/test_nntplib.py
Lib/test/test_ntpath.py
Lib/test/test_numeric_tower.py
Lib/test/test_os.py
Lib/test/test_pathlib.py
Lib/test/test_pdb.py
Lib/test/test_peg_parser.py
Lib/test/test_pkg.py
Lib/test/test_pkgutil.py
Lib/test/test_plistlib.py
Lib/test/test_posix.py
Lib/test/test_pprint.py
Lib/test/test_profile.py
Lib/test/test_property.py
Lib/test/test_pstats.py
Lib/test/test_pulldom.py
Lib/test/test_pyclbr.py
Lib/test/test_pydoc.py
Lib/test/test_pyexpat.py
Lib/test/test_range.py
Lib/test/test_re.py
Lib/test/test_regrtest.py
Lib/test/test_repl.py
Lib/test/test_reprlib.py
Lib/test/test_rlcompleter.py
Lib/test/test_selectors.py
Lib/test/test_set.py
Lib/test/test_shlex.py
Lib/test/test_shutil.py
Lib/test/test_signal.py
Lib/test/test_site.py
Lib/test/test_sndhdr.py
Lib/test/test_socket.py
Lib/test/test_socketserver.py
Lib/test/test_source_encoding.py
Lib/test/test_ssl.py
Lib/test/test_stat.py
Lib/test/test_str.py
Lib/test/test_string.py
Lib/test/test_struct.py
Lib/test/test_sunau.py
Lib/test/test_super.py
Lib/test/test_support.py
Lib/test/test_syntax.py
Lib/test/test_sys.py
Lib/test/test_sysconfig.py
Lib/test/test_tabnanny.py
Lib/test/test_telnetlib.py
Lib/test/test_tempfile.py
Lib/test/test_textwrap.py
Lib/test/test_thread.py
Lib/test/test_threading.py
Lib/test/test_timeit.py
Lib/test/test_tk.py
Lib/test/test_tokenize.py
Lib/test/test_tools/test_c_analyzer/test_cpython/test_supported.py
Lib/test/test_tools/test_c_analyzer/test_parser/test_declarations.py
Lib/test/test_tools/test_c_analyzer/test_parser/test_preprocessor.py
Lib/test/test_tools/test_c_analyzer/test_variables/test_known.py
Lib/test/test_tools/test_i18n.py
Lib/test/test_tools/test_pindent.py
Lib/test/test_trace.py
Lib/test/test_ttk_guionly.py
Lib/test/test_ttk_textonly.py
Lib/test/test_tuple.py
Lib/test/test_types.py
Lib/test/test_unicode.py
Lib/test/test_unicodedata.py
Lib/test/test_unparse.py
Lib/test/test_urllib.py
Lib/test/test_urllib2.py
Lib/test/test_urllib2net.py
Lib/test/test_urlparse.py
Lib/test/test_userstring.py
Lib/test/test_utf8_mode.py
Lib/test/test_warnings/__init__.py
Lib/test/test_wave.py
Lib/test/test_weakref.py
Lib/test/test_winconsoleio.py
Lib/test/test_winreg.py
Lib/test/test_wsgiref.py
Lib/test/test_xml_etree.py
Lib/test/test_zipapp.py
Lib/test/test_zipfile.py
Lib/test/test_zlib.py
Lib/test/test_zoneinfo/test_zoneinfo.py
Lib/test/tkinter_test/README
Lib/test/tkinter_test/__init__.py
Lib/test/tkinter_test/runtktests.py
Lib/test/tkinter_test/support.py
Lib/test/tkinter_test/test_tkinter/__init__.py
Lib/test/tkinter_test/test_tkinter/test_font.py
Lib/test/tkinter_test/test_tkinter/test_geometry_managers.py
Lib/test/tkinter_test/test_tkinter/test_images.py
Lib/test/tkinter_test/test_tkinter/test_loadtk.py
Lib/test/tkinter_test/test_tkinter/test_misc.py
Lib/test/tkinter_test/test_tkinter/test_text.py
Lib/test/tkinter_test/test_tkinter/test_variables.py
Lib/test/tkinter_test/test_tkinter/test_widgets.py
Lib/test/tkinter_test/test_ttk/__init__.py
Lib/test/tkinter_test/test_ttk/test_extensions.py
Lib/test/tkinter_test/test_ttk/test_functions.py
Lib/test/tkinter_test/test_ttk/test_style.py
Lib/test/tkinter_test/test_ttk/test_widgets.py
Lib/test/tkinter_test/widget_tests.py
Lib/textwrap.py
Lib/threading.py
Lib/timeit.py
Lib/tkinter/__init__.py
Lib/tkinter/constants.py
Lib/tkinter/dnd.py
Lib/tkinter/simpledialog.py
Lib/tkinter/test/test_tkinter/test_event.py
Lib/tkinter/test/test_tkinter/test_misc.py
Lib/tkinter/test/test_tkinter/test_threads.py
Lib/tkinter/test/test_tkinter/test_tkdnd.py
Lib/tokenize.py
Lib/trace.py
Lib/tty.py
Lib/turtle.py
Lib/types.py
Lib/unittest/case.py
Lib/unittest/loader.py
Lib/unittest/main.py
Lib/unittest/result.py
Lib/unittest/runner.py
Lib/unittest/signals.py
Lib/unittest/suite.py
Lib/unittest/test/support.py
Lib/unittest/test/test_assertions.py
Lib/unittest/test/test_break.py
Lib/unittest/test/test_case.py
Lib/unittest/test/test_discovery.py
Lib/unittest/test/test_loader.py
Lib/unittest/test/test_program.py
Lib/unittest/test/test_result.py
Lib/unittest/test/test_runner.py
Lib/unittest/test/test_setups.py
Lib/unittest/test/test_suite.py
Lib/urllib/parse.py
Lib/urllib/request.py
Lib/uuid.py
Lib/venv/__init__.py
Lib/venv/scripts/common/Activate.ps1
Lib/venv/scripts/common/activate
Lib/venv/scripts/posix/activate.csh
Lib/venv/scripts/posix/activate.fish
Lib/warnings.py
Lib/wave.py
Lib/weakref.py
Lib/webbrowser.py
Lib/wsgiref/handlers.py
Lib/wsgiref/headers.py
Lib/wsgiref/simple_server.py
Lib/wsgiref/validate.py
Lib/xdrlib.py
Lib/xml/dom/expatbuilder.py
Lib/xml/dom/minidom.py
Lib/xml/dom/pulldom.py
Lib/xml/etree/ElementPath.py
Lib/xml/etree/ElementTree.py
Lib/xml/sax/xmlreader.py
Lib/xmlrpc/client.py
Lib/xmlrpc/server.py
Lib/zipapp.py
Lib/zipfile.py
Lib/zoneinfo/_common.py
Makefile.pre.in
Misc/ACKS
Misc/NEWS
Misc/README.valgrind
Misc/python-config.in
Misc/python-config.sh.in
Misc/python.man
Misc/python.pc.in
Misc/valgrind-python.supp
Misc/verify-bundled-wheels.sh
Modules/Makefile
Modules/Setup
Modules/_abc.c
Modules/_bz2module.c
Modules/_csv.c
Modules/_ctypes/_ctypes.c
Modules/_ctypes/_ctypes_test.c
Modules/_ctypes/callbacks.c
Modules/_ctypes/callproc.c
Modules/_ctypes/cfield.c
Modules/_ctypes/ctypes.h
Modules/_ctypes/stgdict.c
Modules/_cursesmodule.c
Modules/_decimal/libmpdec/io.c
Modules/_decimal/tests/formathelper.py
Modules/_elementtree.c
Modules/_hashopenssl.c
Modules/_io/_iomodule.c
Modules/_io/bufferedio.c
Modules/_io/bytesio.c
Modules/_io/fileio.c
Modules/_io/iobase.c
Modules/_io/textio.c
Modules/_io/winconsoleio.c
Modules/_json.c
Modules/_localemodule.c
Modules/_lsprof.c
Modules/_lzmamodule.c
Modules/_multiprocessing/clinic/posixshmem.c.h
Modules/_multiprocessing/multiprocessing.h
Modules/_multiprocessing/posixshmem.c
Modules/_multiprocessing/semaphore.c
Modules/_operator.c
Modules/_pickle.c
Modules/_sqlite/blob.c
Modules/_sqlite/blob.h
Modules/_sqlite/connection.c
Modules/_sqlite/connection.h
Modules/_sqlite/cursor.c
Modules/_sqlite/module.c
Modules/_sqlite/named_row.c
Modules/_sqlite/named_row.h
Modules/_sre.c
Modules/_ssl.c
Modules/_ssl_data.h
Modules/_stat.c
Modules/_struct.c
Modules/_testcapimodule.c
Modules/_threadmodule.c
Modules/_tkinter.c
Modules/_tracemalloc.c
Modules/_uuidmodule.c
Modules/_winapi.c
Modules/_xxsubinterpretersmodule.c
Modules/_zoneinfo.c
Modules/arraymodule.c
Modules/audioop.c
Modules/cjkcodecs/clinic/multibytecodec.c.h
Modules/cjkcodecs/multibytecodec.c
Modules/errnomodule.c
Modules/fcntlmodule.c
Modules/getpath.c
Modules/grapheme_cluster_break_automaton.h
Modules/main.c
Modules/makesetup
Modules/mmapmodule.c
Modules/nismodule.c
Modules/ossaudiodev.c
Modules/overlapped.c
Modules/posixmodule.c
Modules/pyexpat.c
Modules/selectmodule.c
Modules/signalmodule.c
Modules/socketmodule.c
Modules/socketmodule.h
Modules/sre.h
Modules/sre_constants.h
Modules/sre_lib.h
Modules/unicodedata.c
Modules/unicodedata_db.h
Modules/unicodename_db.h
Modules/xxsubtype.c
Modules/zlibmodule.c
Programs/_testembed.c
Tools/c-analyzer/c_parser/_state_machine.py
Tools/c-analyzer/c_parser/preprocessor/__init__.py
Tools/c-analyzer/cpython/_parser.py
Tools/ccbench/ccbench.py
Tools/clinic/clinic.py
Tools/gdb/libpython.py
Tools/i18n/msgfmt.py
Tools/scripts/README
Tools/scripts/deepfreeze.py
Tools/scripts/eptags.py
Tools/scripts/generate_global_objects.py
Tools/scripts/generate_opcode_h.py
Tools/scripts/ptags.py
Tools/scripts/win_add2path.py
Tools/ssl/multissltests.py
Tools/unicode/Makefile
Tools/unicode/makeunicodedata.py
abc_bench.py
aclocal.m4
configure
configure.ac
m4/ax_pthread.m4
pyconfig.h.in
setup.py
test.py

--
Jeremy Kloth
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GIJ4SWF6ATKPZ6VOAOPKPKS7SMAONBCU/
Code of Conduct: http://python.org/psf/codeofconduct/

> On 29 Mar 2022, at 19:51, Brett Cannon <brett@python.org> wrote:
>
>
>
> On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren <ronaldoussoren@mac.com <mailto:ronaldoussoren@mac.com>> wrote:
>
>
>> On 29 Mar 2022, at 00:34, Brett Cannon <brett@python.org <mailto:brett@python.org>> wrote:
>>
>>
>>
>> Once https://mail.python.org/archives/list/python-committers@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/ <https://mail.python.org/archives/list/python-committers@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/> is considered resolved, the next part of my "what is the stdlib" plan is to finally try to suss all of this out and more-or-less write a stdlib policy PEP so we stop talking about this. My guess it will be more of guidance about what we want the stdlib to be and thus guide what things belong in it. No ETA on that work since I also have four other big Python projects on the go right now whose work I am constantly alternating between.
>
> Having such a policy is a good thing and helps in evolving the stdlib, but I wonder if the lack of such a document is the real problem. IMHO the main problem is that the CPython team is very small and therefore has little bandwidth for maintaining, let alone evolving, large parts of the stdlib. In that it doesn’t help that some parts of the stdlib have APIs that make it hard to make modifications (such as distutils where effectively everything is part of the public API). Shrinking the stdlib helps in the maintenance burden, but feels as a partial solution.
>
> You're right that is the fundamental problem. But for me this somewhat stems from the fact that we don't have a shared understanding of what the stdlib is, and so the stdlib is a bit unbounded in its size and scope. That leads to a stdlib which is hard to maintain.

That (the hard to maintain part) is not necessarily true, if we had enough resources…. In theory the stdlib could be split into logical parts with teams that feel responsible for those parts (similar to having maintainers sign up for various platforms). That doesn’t work because of the small team, and partially also due to necessarily having very strict rules w.r.t. backward compatibility.


> It's just like dealing with any scarce resource: you try to cut back on your overall use as best as you can and then become more efficient with what you must still consume; I personally think we don't have an answer to the "must consume" part of that sentence that leads us to "cut back" to a size we can actually keep maintained so we don't have 1.6K open PRs <https://github.com/python/cpython/pulls>.

I agree, but this is something to state explicitly when describing what should and should not be in scope for the stdlib. I’m a fan of a batteries included stdlib, but with our current resources we cannot afford to have some bits in the stdlib that would “obviously” be a candidate for a modern batteries included stdlib, such as a decent HTTP stack with support for HTTP/1, /2 and /3.

Ronald

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/