Sgtm
Sent from my comm
On Mar 22, 2022, at 21:31, Gregory P. Smith wrote:
On Tue, Mar 22, 2022 at 4:36 PM Barry Warsaw
mailto:ba...@python.org>> wrote:
PEP 2 will have to be “un-superseded”, and presumably the devguide (which PEP 2
points to) will also need to be updated.
we discussed
On Tue, Mar 22, 2022 at 4:36 PM Barry Warsaw wrote:
> PEP 2 will have to be “un-superseded”, and presumably the devguide (which
> PEP 2 points to) will also need to be updated.
>
we discussed that a bit. the dev guide makes sense as a "how to do it"
purpose document, useful for constructing
On Tue, Mar 22, 2022 at 5:02 PM Steven D'Aprano wrote:
> On Tue, Mar 22, 2022 at 04:26:57PM -0700, Brett Cannon wrote:
>
> >1. Update PEP 2 to say a PEP is necessary to add a module to the
> stdlib
> >2. Update PEP 4 to say that a PEP is necessary to deprecate/remove a
> >module
>
>
On 3/22/22 16:26, Brett Cannon wrote:
> [...] after discussing things we have three proposals:
>
> 1. Update PEP 2 to say a PEP is necessary to add a module to the stdlib
> 2. Update PEP 4 to say that a PEP is necessary to deprecate/remove a module
> 3. Mark PEP 411 as obsolete and thus
On Tue, Mar 22, 2022 at 04:26:57PM -0700, Brett Cannon wrote:
>1. Update PEP 2 to say a PEP is necessary to add a module to the stdlib
>2. Update PEP 4 to say that a PEP is necessary to deprecate/remove a
>module
Does that include modules flagged as private?
E.g. the public
PEP 2 will have to be “un-superseded”, and presumably the devguide (which PEP 2
points to) will also need to be updated.
I think it’s probably fine to drop the idea of provisional APIs. Aside from
the limit benefit of evolution within the stdlib, code still gets written
against provisional
I had kicked off a discussion a while back at
https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681
about how to manage the stdlib (this has nothing to with *what* the stdlib
is and thus what belongs in it). It finally bubbled up in the SC agenda and
after
