One thought that came to mind as perhaps a way more in line with how other parts of python work, is to extend the “name mangling” aspect of __ to this sort of context. (Just __ at the beginning, not both before and after).
In class members these become _ClassName_, and thus a subclass trying to access them from the base class, needs to explicitly do the mangaling. If at module level __ converted to _module_ using the current module, any module trying to use such a “private” item would need to also explicitly mangle the name, giving a similar level of “protection”. Richard Damon. > On Nov 21, 2025, at 6:28 PM, Alexander Neilson <[email protected]> > wrote: > > Can you articulate where such a “private” flag would be benefiting > developers in a use case? > > From my initial view on reading this you have documented the convention for > marking something as designed for internal use / don’t rely on this being > available. However users of the library can still look at the code and see > the import even if it’s marked private. > > Also the dependency will still exists as the library needs to be present to > function. > > And once it is imported into the name space it exists and is using memory. It > seems unusual to force someone to repeat an import if they are using a > related function from a library rather than just using it alongside the > library function. > > Trying to see what your cases are for the use of this private flag for > importing. > > Regards > Alexander > > Alexander Neilson > Neilson Productions Limited > 021 329 681 > [email protected] > >> On 22 Nov 2025, at 10:25, Bjørnar Remmen via Python-list >> <[email protected]> wrote: >> >> Hi, this is my first time here on the mailing list. >> >> I would like to open up for a discussion on how we can introduce a way to >> hide imports. >> I am proposing the introduction of an optional, non-breaking keyword, >> private, to be used when importing a file. The goal is to allow developer to >> hide internal dependencies and prevent them from leaking into the module's >> public namespace. >> >> Under the current system, any object imported into a module's top-level >> scope becomes an accessible attribute of that module. >> module/math.py >> ''' >> import numpy as np >> >> def calculate_mean(data: np.ndarray) -> float: >> return np.mean(data) >> ''' >> The issue is that when a user imports this module, the import is exposed. >> ''' >> import module.math >> # This is valid, even though 'np' is an internal detail: >> # module.math.np >> ''' >> >> While we have some conventions, we do not have explicit hiding of such >> modules. >> We have one solution, which is more like a convention >> >> ''' >> import numpy as _np >> >> ''' >> This hides it for common usage and signals to the developer that it is >> private. >> >> __all__ works for wildcard imports, but not for standard imports. >> >> I suggest adopting a solution similar to what has been implemented in swift, >> which is to introduce a modifier keyword: >> ''' >> private import numpy as np >> >> def calculate_mean(data: np.ndarray) -> float: >> return np.mean(data) >> >> ''' >> >> Internally in the file np is accesible, but when importing the file it is >> not accesible. >> >> Expected behaviour: >> >> import module.math >> module.math.np >> This raises an AttributeError >> >> from module.math import np raises an ImportError >> >> from module.math import calculate_mean Succeeds >> -- >> https://mail.python.org/mailman3//lists/python-list.python.org > -- > https://mail.python.org/mailman3//lists/python-list.python.org -- https://mail.python.org/mailman3//lists/python-list.python.org
