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
