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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.