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.
--
Richard Damon
--
https://mail.python.org/mailman3//lists/python-list.python.org
