PEP 842: Module Exports (new revision)

[DavidCEllis (David Ellis)]

Thanks for the examples. At least some of these should probably be in the PEP.

Many of these also fall into the case of people needing to use these internals because we didn’t provide a public API. I don’t think we remove the need to do these things by making it more difficult to do so.

The sysconfig._get_default_scheme example would work as an argument for a way to mark something that isn’t prefixed with an underscore as private - but not to prevent accessing it. The feature was useful, the breakage was in renaming.

@ZeroIntensity

@DavidCEllis

So from my perspective this PEP is trying to remove what I find to be a useful feature .

It’s trying to make it much harder to do it accidentally, and to hopefully encourage people to ask for public APIs upstream instead of just using something private and relying on it. As I’ve said many times, this PEP does not prevent you from accessing private names. If you decide you don’t care, then just del module.__export__ (or module.__export__.remove("name_you_want").

Sometimes you do ask for public APIs upstream^[1] but you’re not the maintainer and you can’t just add the API yourself so you need a way to get what you need done.

From my perspective it’s not that I “don’t care” it’s that the only option to implement the feature I need is to use the internals. Sure I’d love if there was a public method to do so, but there isn’t and getting a public API soon didn’t seem likely.

I don’t really think it’s good practice for a library to mutate global state in other modules. For users yes we’ll probably find recommendations to remove the __export__ name in order to make things work again.

Your second method appears to be the opposite, wouldn’t that make “name_you_want” private?

@ZeroIntensity

@DavidCEllis

Enforcing the ExportError is likely going to end up creating the need for new, more convoluted workarounds in these situations.

No, it just changes when the workarounds have to occur.

You’re envisioning a case where a library has private names, downstream users begin relying on those private names, and then the library uses this PEP to make private names raise an ExportError on access. Downstream users who were already relying on internals would be broken by this, but arguably, that was going to happen anyway when the library inevitably broke the private API. It’s a one-time break, though; once users have migrated (or pinned), they are strongly discouraged from ever making the mistake again.

I guess there would be a disagreement on inevitability. By creating this export feature you’re pretty much forcing that and I don’t think this is necessary or even good.

You give a lot of examples where the only good choice was to make the mistake that you’re now saying users should never make again.

---

1. Note that I don’t think the internals I need to implement this need to be public, and as such I wouldn’t propose making them so. But I do need to access those internals. ↩︎