Re: Proposal: private keyword for import statements to hide module dependencies

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