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

On 12/2/25 2:55 PM, Bjørnar Remmen via Python-list wrote:
> Richard Damon wrote:
>> On 11/25/25 3:42 PM, bjotta via Python-list wrote:
>>> It seem like you are talking about classes and sub-classes. I was talking about dependencies in projects.
>>> The technique is currently defined only for class and sub-classes, but
>> could be extended
>>> e..g I create a library that has some dependencies (numpy here)
>>> Inside the library there is a file importing numpy for example.
>>> '''
>>> import numpy as np
>>> def stock_earnings(winnings, losses):
>>>       return winnings - losses
>>> '''
>>> I want to be able to restrict / name mangle the usage.
>>> To avoid this being possible.
>>> And the question is how? (and why?) The problem is that to do what you
>> want means looking up a name in a namespace now becomes context
>> dependent. Some of the names that are defined there are to not be found
>> by some contexts, while other can be. This is complicated, which isn't
>> what python wants to be.
>>> '''
>>> from library.math import np.
>>> '''
>>> There are reasons for this, but for example at work we explicitly install all dependencies we use in our program.
>>> If someone starts to use sub-dependency from a library without explicitly installing it. The next time the library updates and the maintainers decides to update to using numba or something else the code wont work.
>>> And they could have imported np directly and not installed it to, so it
>> doesn't help.
>>
>> And if the library doesn't import that module, your sub-dependency
>> import will FAIL and thus show the problem.
>>> That was the Idea behind the "private" keyword. Any other suggestion to that part?
>>> And proper discipline prevents that.
>> That is EXACTLY the danger of peeking into things marked (by the
>> convention) as internal.
>>
>> Python by its nature doesn't stop you from doing "dumb" things, it just
>> makes it clear when you do it (if you know the language).
>>
>> Letting module globals that begin with __ (and not end with __) be
>> mangled like was suggested just make the operation more obvious.
> Do you have any feedback to my reply? Tried understanding your suggestions.

I gave you my feedback.

Your idea needs to add a keyword, "private" and a concept (names that 
can't be found from some concepts) that just don't exist in python now.

It just isn't the way python works. If you need that feature, you need a 
different language.

The problem you are trying to solve, is people not following the basic 
design guidelines, and that isn't how python works.

You don't break language design to try to keep people from breaking the 
"rules", you teach them to do things right.

There are large number of ways to do something "badly", and trying to 
"outlaw" them is hard.

To implement your idea, requires deep changes in the code to impleent 
the language, and a careful analysis to define it and make sure it 
works, as you want a basic name lookup to change its behavior on the 
somewhat distance context that the lookup is being used in. This is fragile.

-- 
Richard Damon

-- 
https://mail.python.org/mailman3//lists/python-list.python.org