I'd like to give a shoutout to a package I wrote called mkinit, which helps autogenerate explicit `__init__.py` files to mitigate some of the issues you mentioned (especially with respect to `from blah import *`).
https://github.com/Erotemic/mkinit On Sat, Apr 10, 2021 at 3:08 PM Guido van Rossum <gu...@python.org> wrote: > On Sun, Mar 14, 2021 at 10:55 PM Ethan Furman <et...@stoneleaf.us> wrote: > >> I completely agree with this. One of the hallmarks of Python is the >> ability to query, introspect, and modify Python code. It helps with >> debugging, with experimenting, with fixing. Indeed, one of the few >> frustrating bits about Python is the inability to work with the C portions >> as easily as the Python portions (note: I am /not/ suggesting we do away >> with the C portions). >> >> What would be the benefits of locking down modules in this way? > > > I owe you an answer here. For large projects with long lifetimes that > expect their API to evolve, experience has taught that any part of the API > that *can* be used *will* be used, even if it was clearly not intended to > be used. And once enough users have code that depends on reaching into some > private part of a package and using a method or attribute that was > available even though it was undocumented or even clearly marked as > "internal" or "private", if an evolution of the package wants to remove > that method or attribute (or rename it or change its type, signature or > semantics/meaning), those users will complain that the package "broke their > code" by making a "backwards incompatible change." For a casually > maintained package that may not be a big deal, but for a package with > serious maintainers this can prevent ordered evolution of the API, > especially since a package's developers may not always be aware of how > their internal attributes/methods are being used or perceived by users. So > experienced package developers who are planning for the long term are > always looking for ways to prevent such situations (because it is > frustrating for both users and maintainers). Being able to lock down the > exported symbols is just one avenue to prevent disappointment in the future. > > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/XDLAAQKWDSPOJ6HKVTBEZEK6KYM5PQGP/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- -Dr. Jon Crall (him)
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TNTM3XCN6VBL3WT7ZT5VFG2QJ6FNJ2LM/ Code of Conduct: http://python.org/psf/codeofconduct/
