On 11/21/2025 8:03 PM, Richard Damon wrote:
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.
I don't see the benefit, and it serves to make Python more complicated
and harder to understand and work with. Those are serious negatives.
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
