I like the idea of improving the way interfaces are exported in Python. I still don't know what the standard is today.
Some of my favourite projects like Jax have started tucking their source in a _src directory: https://github.com/google/jax/tree/master/jax/_src, and then importing the exported interface in their main project: https://github.com/google/jax/blob/master/jax/scipy/signal.py. As far as I know, this "private source" method is nicest way to control the interface. What I've been doing is importing * from my __init__.py (https://github.com/NeilGirdhar/tjax/blob/master/tjax/__init__.py) and then making sure every module has an __all__. This "init-all" method is problematic if you want to export a symbol with the same name as a folder. It also means that all of your modules and folders are exported names. If I started again, I'd probably go with the way the Jax team did it. I agree that the proposed export keyword is nicer than __all__, and accomplishes what I've been doing more elegantly. However, it suffers from the same extraneous symbol problem. I would still choose the private source method over export. I'm curious if anyone has ideas about how exporting an interface should be done today, or could be done tomorrow. On Monday, March 15, 2021 at 9:48:11 AM UTC-4 Rob Cliffe via Python-ideas wrote: > > > On 15/03/2021 05:54, Ethan Furman wrote: > > On 3/14/21 12:42 PM, Stestagg wrote: > > > >> The value of being able to (in specific cases) reach into third-party > >> code, and customize it to work for your specific situation should not > >> be disregarded. > > > > 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). > An emphatic +1. > Rob Cliffe > > > > > > What would be the benefits of locking down modules in this way? > > > > -- > > ~Ethan~ > > _______________________________________________ > > Python-ideas mailing list -- python...@python.org > > To unsubscribe send an email to python-id...@python.org > > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > > Message archived at > > > https://mail.python.org/archives/list/python...@python.org/message/KIFAVTRMIPCVAX2RZ7NDSTDM46AHSDWK/ > > <https://mail.python.org/archives/list/python-ideas@python.org/message/KIFAVTRMIPCVAX2RZ7NDSTDM46AHSDWK/> > > Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ > Python-ideas mailing list -- python...@python.org > To unsubscribe send an email to python-id...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python...@python.org/message/TFGG5LBGEIH34WJNIKZGBCT67A6KFGKM/ > > <https://mail.python.org/archives/list/python-ideas@python.org/message/TFGG5LBGEIH34WJNIKZGBCT67A6KFGKM/> > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/YDTNI7V2V6L3SEJCHOYZWSXC3QVB4WBS/ Code of Conduct: http://python.org/psf/codeofconduct/
