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

[bjotta via Python-list]

It seem like you are talking about classes and sub-classes. I was talking about 
dependencies in projects.


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.

'''
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.

That was the Idea behind the "private" keyword. Any other suggestion to that 
part?
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

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

[bjotta via Python-list]

I tried explaining it further down in the thread
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

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

[Thomas Passin]

On 11/25/2025 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.


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.

'''
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.

That was the Idea behind the "private" keyword. Any other suggestion to that 
part?


I don't see how a private keyword would help.  But in Python programs, 
you don't get upgraded automatically.  You can use pip freeze to capture 
the current version of all libraries, and then use those versions during 
a new install. So there is a way to keep control of the various versions.


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

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

[Richard Damon]

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

Reminder: CFP for the Python Devroom @ FOSDEM 2026 ends Dec 1st

[Marc-Andre Lemburg]

 Reminder: Call for Participation ends Dec 1st

We are happy to announce that we will again be running a*Python devroom 
at FOSDEM 2026*.


The next edition of FOSDEM will take place on January 31 and February 1 
2026, with the Python devroom currently scheduled for Saturday, January 
31, in the afternoon.


If you haven’t heard about FOSDEM before or are looking for more 
information, you can visit the official website athttps://www.fosdem.org/.


As usual, we are looking for multiple Pythonistas to help us shape the 
devroom schedule. We are now open to receiving your proposals ! With 
over 8500 participants, FOSDEM is the perfect place to share your story 
and meet fellow Python enthusiasts.


Good luck to everyone applying. We’re looking forward to meeting you all 
at FOSDEM 2026 !



   About FOSDEM

 * Official FOSDEM 2026 website 
 * FOSDEM Code of Conduct

   

FOSDEM is a free and non-commercial event organized by the community for 
the community.


The goal is to provide free and open source software developers and 
communities a place to meet to:


 * get in touch with other developers and projects;
 * be informed about the latest developments in the free software world;
 * be informed about the latest developments in the open source world;
 * attend interesting talks and presentations on various topics by
   project leaders and contributors;
 * promote the development and benefits of free software and open
   source solutions.

Participation and attendance is totally free, though the FOSDEM 
organizers gratefully accept donations and sponsorship.



   Essential Information

The Python devroom is currently scheduled to be held on January 31 in 
the afternoon.


 * *Submission deadline: December 1 2025*
 * There will be no extension of the deadline
 * Announcement of the schedule: December 15 2025
 * The reference time is Brussels local lime (CET).
 * Talk format: 25 minutes presentation, including Q&A, if any.
   In-person only.
 * Live streaming of the talks will be available.


   Speaker Guidelines

Please submit your talk proposals using theCFP submission page 
.


 * FOSDEM is using a self-hosted Pretalx installation for managing talk
   submissions. You will need to create an account, if you don’t
   already have one.
 * In the Submission notes field, please also confirm that if your talk
   is accepted, you will be able to attend FOSDEM and deliver your
   presentation. We will not consider proposals from prospective
   speakers who are unsure whether they will be able to secure funds
   for travel and lodging to attend FOSDEM. Sadly, we are not able to
   offer travel funding for prospective speakers.
 * You will need to select the "*Python*" track
 * Keep in mind presentations must be related to Python. All
   presentations will be recorded and made available under the Creative
   Commons licenses CC-BY-SA or CC-BY. Captured footage will later be
   shared online using the FOSDEM archives. By submitting you also
   agree to these terms.


   List of Desirable Topics

We'd like to make the devroom topics as diverse as possible, so we are 
looking to offer a mixture of presentations, short tutorials, demos, 
live coding, etc. This year, the python devroom will focus both on the 
language itself (new developments, tools and best practices) and its 
broader applications in education, data science and emerging fields. 
Examples of these include the following:


 * How to start as a Python developer
 * Code infrastructure & starting new projects, e.g. with
   community-backed tools like uv or pixi
 * Testing/CI best practices; apps or libraries
 * Performant Python code
 * Making use of 3.13t (free-threaded Python with no GIL lock)
 * Sustainable Python code
 * How to do/my cool thing/in Python
 * Python as a tool for education
 * How to contribute to the Python language
 * Python 3.13, 3.14, 3.15: What's new?
 * Python in data analysis & visualization tools
 * Python in AI & machine learning
 * Reproducibility and best-practices (e.g. lockfile usage)
 * The scientific Python ecosystem
 * How to write secure Python code
 * Python governance structure
 * Python success stories
 * Interoperability and cross-language bindings for Python
 * New Python projects


   Volunteers

We will also call for volunteers to help us run the event and help us 
with the devroom operation. Please email the organizers, in case you are 
interested.



   Organizers

You can reach out directly to the organizers, if you have a specific 
request or question:


 * Marc-André Lemburg: mal+fosdem [at] egenix.com
 * Rosie Wood: rwood [at] turing.ac.uk

--
Marc-Andre Lemburg
--
https://mail.python.org/mailman3//lists/python-list.python.org

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

[Michael Torrie via Python-list]

On 11/25/25 1:42 PM, bjotta via Python-list wrote:
> I want to be able to restrict / name mangle the usage.
> To avoid this being possible.
> 
> '''
> from library.math import np.
> '''

Fascinating. I would never have thought to do an import like that and I
have never heard of anyone doing such a thing.  I can't say I have ever
seen it in any python code in the wild either.

Of course Python only imports each module once, so importing np from
library.math would get you the same module as when you import numpy. So
there's no difference as far as dependencies are concerned.

> 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.

I don't see how importing from library.math vs directly from numpy has
any bearing on that policy.  Either way you're importing numpy so that
will have to be installed.  Besides, isn't this really a documentation
issue? Perhaps an automated script can enumerate the dependencies for
you so you can ensure your policy is followed when code is committed.

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