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

Reply via email to