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 is weakref but there is also a _weakref module.
I for one just had "public" in mind while we were discussing this
_underscore private things are implementation details so long as they do something unfortunate and leak out into things like pickle state. (and if anything does that, it is a bug that should be fixed, but takes deprecation time to drop old support for - i have no examples of this in mind, it is hopefully made up)
Maybe we want to keep tighter control over the top level stdlib modules
(such as _weakref) but I hope that what happens inside a package is
considered internal to the package, e.g. concurrent.futures._base.
If we are discussing these issues, how about refactoring a single file
module to a package, with no change to the API? E.g.
# Before
hovercraft.py
# refactor to
hovercraft/__init__.py
hovercraft/_privatestuff.py
We've done that in the past without incident that I can recall. logging and unittest for example. It's still "import hovercraft" and is where you'd store your eels regardless of module vs package. I don't think that you need a PEP for that unless you can identify significant negative consequences.
--
Steve
_______________________________________________
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-leave@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/GNEUZNE5TLPUCSUGTDVNRU5EGJ2QKYXG/
Code of Conduct: https://www.python.org/psf/codeofconduct/