PEP 842: Module Exports

[ZeroIntensity (Peter Bierma)]

@pf_moore

this feature sends a message that is contrary to the established policy of openness that Python has had from the start.

I tried to be very clear that this isn’t the purpose of the PEP. I wrote a paragraph about it in the rationale:

Python does not include access modifiers as a language feature for a reason. To quote Eric Smith: “Access to internals of other classes is a feature when you need it”. This PEP does not intend to change this convention, nor should it be interpreted as an indication that Python is tending toward the direction of true access modifiers.

I’m really not trying to add private/public to Python, and I think interpreting this PEP as such completely changes the intention behind the API.

@pf_moore

I’d like to see concrete use cases. And in particular, use cases that assume that the users of a module expect to use it according to its documented interface, and only access notionally private symbols with an understanding that they do so at their own risk.

My own use case (and from the others I have spoken to) is with help() and similar functions at runtime. I find it much quicker to call dir() or help() on a module to find out what it exposes. Here’s an example I just thought of:

1. Imagine I’m interacting with a module to find the digits of pi. Let’s call it pi.
2. pi happens to import the numbers module, without any leading underscore.
3. I call dir(pi), and see pi.numbers. As a user, if I’m looking for digits of pi, pi.numbers sounds like exactly what I want.
4. I try to use it and get a weird exception at runtime. Yes, I should have looked through the docs for pi, but that’s not the point! A Python module comes with tons of runtime features to make this kind of introspection possible. If you want to argue that “users should just read the docs”, then I’m open to hearing it, but keep in mind that you’re also arguing against the existence of help().