[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

[Steve Dower]

On 3/28/2022 10:44 PM, Jason Ansel via Python-Dev wrote:

The PyTorch team plans to use PEP 523 as a part of PyTorch 2.0, so this 
proposal may break the next major release of PyTorch.

The related project is TorchDynamo, which can be found here:
https://github.com/facebookresearch/torchdynamo

We will likely move this into the core of PyTorch closer to release.

If the changed happens, would PyTorch still be able to use the eval frame API?  
Or would it prevent from being used entirely?


You'd be able to use it, but if we don't nail down the compatibility 
guarantees then you might find PyTorch doesn't work properly against 
3.11.(n+1) while 3.11.n was fine.


Right now, the API is allowed/expected to change between 3.x releases 
(which normally we don't allow without a deprecation period) but it 
still has to remain compatible within a single 3.x release. Making it 
fully internal *without adding a stability guarantee* means it could 
change more frequently, which you wouldn't be able to handle as an 
installable package.


It's *unlikely* that it'll change that often, because there are still 
other public interfaces that cannot. But, the plan behind this is to 
make more stuff internal so that it can be modified more freely, so we 
may see that rate of change increase.


In this world, your best bet is for TorchDynamo to become a full CPython 
fork. And when that's your best bet, it should set off alarms everywhere 
;) But that is what relying on internal APIs implies, and is certainly 
what people would have to do if we were to remove the existing PEP's 
interface. (It's what Pyjion was doing before the PEP was written, and 
it's why Pyjion doesn't have to be a full fork these days.)


So you probably want to state explicit support for either keeping the 
APIs public and slightly-flexible, or making them internal but stable. 
(Public and stable won't work at all for us, and normal internal won't 
work at all for you.)


Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/MU56YBMPWSVMK3HAUJOBRW4KEN2ZLVCG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Damian Shaw]

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  wrote:

> There's also the "Experts index" in the devguide:
> https://devguide.python.org/experts/#experts
>
> Best,
> Alex
>
>  Original message 
> From: Skip Montanaro 
> Date: 29/03/2022 22:36 (GMT+00:00)
> To: "Eric V. Smith" 
> Cc: Python Dev 
> 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-le...@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/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/QYCAECVPQEZ5JX7LTLDA3IWB6CUUUOZ5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Alex Waygood]

There's also the "Experts index" in the devguide: 
https://devguide.python.org/experts/#expertsBest, Alex
 Original message From: Skip Montanaro 
 Date: 29/03/2022  22:36  (GMT+00:00) To: "Eric V. 
Smith"  Cc: Python Dev  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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

[Terry Reedy]

On 3/28/2022 5:44 PM, Jason Ansel via Python-Dev wrote:

The PyTorch team plans to use PEP 523 as a part of PyTorch 2.0, so this 
proposal may break the next major release of PyTorch.

The related project is TorchDynamo, which can be found here:
https://github.com/facebookresearch/torchdynamo

We will likely move this into the core of PyTorch closer to release.

If the changed happens, would PyTorch still be able to use the eval frame API?  
Or would it prevent from being used entirely?


I believe that you will just have to add a new or different #include 
statement.  I recommend that you add a comment to the issue, 
https://bugs.python.org/issue46850,

and even more, that you create a branch with the diffs in

https://github.com/python/cpython/pull/32052
https://github.com/python/cpython/pull/32054

applied so that you can experiment and verify what I believe.


--
Terry Jan Reedy

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/JS7YMJGEWCY5PBF4ATMZPWXVY6PYLPKK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Terry Reedy]

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-le...@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/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Skip Montanaro]

>
> 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-le...@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/PPQ5LVXVPAZJ5OHQX36HYHJQ3TDR76NX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Eric V. Smith]

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-le...@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/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Skip Montanaro]

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-le...@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/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Brett Cannon]

On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren 
wrote:

>
>
> On 29 Mar 2022, at 00:34, Brett Cannon  wrote:
>
>
>
> On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker 
> wrote:
>
>> On Mon, Mar 28, 2022 at 11:29 AM Paul Moore  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-committ...@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
.


> 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-le...@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-le...@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/
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/TCS3VOPVYI254GSC3OXGVB6ISUSMN7W7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancing generic type documentation in the standard library

[Brett Cannon]

On Mon, Mar 28, 2022 at 3:58 PM Luciano Ramalho  wrote:

> On Wed, Mar 23, 2022 at 5:01 PM Brett Cannon  wrote:
> > The SC somewhat agrees!  See
> https://mail.python.org/archives/list/typing-...@python.org/thread/TVMQJXOJFOYFPDMQDFG6G4B6J3MLRYKB/
> where we have asked for at least the specs to get consolidated into proper
> documentation instead of spread out across various PEPs.
>
> That makes me somewhat happy.
>
> Just kidding. I totally agree that the typing PEPs need to be
> consolidated into specs, which then need to be kept up-to-date.
>
> The issue I raised is related but different: we now have dozens of
> generic types in the standard library that are not fully documented in
> PEPs or hardly anywhere else.
>
> For example, PEP 585–Type Hinting Generics In Standard Collections
> merely lists the types which, back then, were changed to accept type
> parameters within [ ]. That PEP does not document the number, meaning,
> or variance of the accepted type parameters.
>
> When Guido and I refactored the `typing` module docs for Python 3.9,
> we marked dozens of types as deprecated. The entries for those
> deprecated types, such as `typing.Generator`, are the only places
> where the parameters accepted by the generic type are
> documented—albeit in a way that's not user-friendly:
>
> class typing.Generator(Iterator[T_co], Generic[T_co, T_contra, V_co])
>
> > My personal hope is this will also lead to better docs overall in a
> central location instead of spread out among modules, tools, etc.
>
> We share that hope and I am willing to help.
>
> Documenting the generic types in the standard library is a much
> smaller task than turning the typing PEPs into specs. It seems like a
> good next step on the way to better typing docs.
>

Since the typing-sig will likely be doing the work and driving such an
effort I would ask over there. I personally would love for a
typing.python.org or equivalent subsection of docs.python.org to exist.

-Brett


>
> Cheers,
>
> Luciano
>
>
>
> >
> > -Brett
> >
> >>
> >>
> >> We now have lots of generic types in the standard library, but their
> >> formal type parameters are poorly documented—or not documented at
> >> all—in the standard library documentation.
> >>
> >> More importantly: the documentation we have about specific
> >> covariant/contravariant types is now in entries in the `typing` module
> >> that are all deprecated since PEP 585 was implemented in Python 3.9.
> >>
> >> Below I present two of many examples where the documentation of a
> >> generic type is not great.
> >>
> >> However, if people agree this is a problem, we need to discuss where
> >> and how to put the documentation in a way that is not too disruptive
> >> to users of Python who don't know or don't care about type hints, for
> >> many reasons that we should not judge.
> >>
> >> For example, where do we document the fact that `dict` accepts two
> >> invariant formal type parameters, and that `frozenset` accepts one
> >> contravariant type parameter?
> >>
> >> What do you think?
> >>
> >> Cheers,
> >>
> >> Luciano
> >>
> >> _
> >> EXAMPLE 1: `Callable` variance is not documented
> >>
> >> For example, in the `Callable` type, the `ReturnType` parameter is
> >> covariant, and the `ParameterType` parameters are all contravariant.
> >>
> >> But there is no mention of variance in this entry:
> >>
> https://docs.python.org/3/library/typing.html?highlight=typing#typing.Callable
> >>
> >> Also, no mention of the fact that `collections.abc.Callable` is generic
> here:
> >>
> https://docs.python.org/3/library/collections.abc.html#collections.abc.Callable
> >>
> >> PEP 483—The Theory of Type Hints—is the only official Python doc where
> >> I found the information about the variance of the formal type
> >> parameters of `Callable`. The explanation there is brilliant [0].
> >>
> >> [0] https://peps.python.org/pep-0483/#covariance-and-contravariance
> >>
> >> Regardless, the intended audience of PEPs is "core developers"—which
> >> is neither a superset nor a subset of "Python devs now using type
> >> hints". We should not rely on PEPs to document features for Python
> >> users in general.
> >>
> >> _
> >> EXAMPLE 2: `Generator` variance could be better documented
> >>
> >> The entry for `typing.Generator` [1] has this heading:
> >>
> >> class typing.Generator(Iterator[T_co], Generic[T_co, T_contra, V_co])
> >>
> >> Answer quickly: how many formal type parameters does `Generator`
> >> require? Which are covariant? Which are contravariant?
> >>
> >> [1]
> https://docs.python.org/3/library/typing.html?highlight=typing#typing.Generator
> >>
> >> Nowhere in that page [1] there's an explanation of the `*_co` and
> >> `*_contra` naming convention, much less their semantics.
> >>
> >> Fortunately, the text of the `typing.Generator` entry says: "A
> >> generator can be annotated by the generic type `Generator[YieldType,
> >> SendType, 

[Python-Dev] Re: Changing unittest verbose output.

[Antoine Pitrou]

On Sun, 27 Mar 2022 00:48:04 -
"Itay Yeshaya"  wrote:
> When running unittest with the -v flag, if a test has errors, and has a 
> docstring, the test name is shown on one line, and the docstring is shown on 
> the next line with the `ERROR` word.
> For example:
> 
> ./python.exe -m unittest -v Lib.test_verbose_error.randomTest
> test_one (Lib.test_verbose_error.randomTest)
> this is a doc string with helpful info ... ERROR
> 
> ==
> ERROR: test_one (Lib.test_verbose_error.randomTest)
> this is a doc string with helpful info
> --
> Traceback (most recent call last):
>   File "/workspaces/cpython/Lib/test_verbose_error.py", line 11, in test_one
> assert l[1]
>   ~^^^
> IndexError: list index out of range
> 
> --
> Ran 1 test in 0.004s
> 
> This cause for some confusion and we would like to fix it, the possible 
> options are:

Which confusion is this about?

Unit tests are not APIs, so the only reason to write a docstring is if
you want it to appear in test output.  If you don't want it to appear
in test output, write a comment instead.

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/WIWR4F3M4RD6CPA5QTN2VGTPRXEQ3VDT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Ronald Oussoren via Python-Dev]

> On 29 Mar 2022, at 00:34, Brett Cannon  wrote:
> 
> 
> 
> On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker  > wrote:
> On Mon, Mar 28, 2022 at 11:29 AM Paul Moore  > 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-committ...@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 
> 
> To unsubscribe send an email to python-dev-le...@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-le...@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/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/XHETPUVT6UYWQ5URQNF6IQBFBZRPGMN6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[lincoln auster [they/them]]

> 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-le...@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/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Sebastian Rittau]

Am 27.03.22 um 18:11 schrieb Christopher Barker:

On Sun, Mar 27, 2022 at 3:08 AM Paul Moore  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

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/RZFGUDPO2DIASHI72GUF2NP3IR3DLQGO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Paul Moore]

On Tue, 29 Mar 2022 at 00:37, Toshio Kuratomi  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-le...@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/