On Tue, Mar 22, 2022 at 5:02 PM Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Mar 22, 2022 at 04:26:57PM -0700, Brett Cannon wrote:
- Update PEP 2 to say a PEP is necessary to add a module to the stdlib
- 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/G... Code of Conduct: https://www.python.org/psf/codeofconduct/