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 dis
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 API
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 interface
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 droppi
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
>
> D
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 PRs
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 tha
