Re: Proposal: private keyword for import statements to hide module dependencies
Bjørnar Remmen via Python-list <[email protected]>
| Newsgroups | gmane.comp.python.general |
|---|---|
| Message-ID | <[email protected]> |
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.