You write about auto-populating `__all__`. I am not aware of it ever auto-populating. What are you referring to here? (The behavior that in the absence of `__all__`, everything not starting with `_` is exported, is not auto-population -- it's a default behavior implemented by `import *`, not by the exporting module.)
That was a misconception on my part -- always thought it worked the other way around! Not sure why I thought that. I'm open to the idea of not using __all__, if there's the possibility to have a better interface by breaking away from it. My worries with creating a new, more strict interface would be: 1, breaking compatibility with old tools that look for __all__ specifically-- though I'm not sure how big the set of "tools that dynamically introspect __all__" is. It's probably pretty small. 2, I do like that Python gives you the ability to import everything, even if the library author didn't intend for it. There's benefits to encapsulation of course, but I like having the option to fiddle with some library internals if I really need to. I wonder if there's a way to keep this ability but make it a little "louder", so it's clear you're doing something abnormal -- like the underscore-prefixed private member convention or dangerouslySetInnerHTML in React. As for `export x: int = 1` vs ``` x: int = 1 export x ``` , I like both syntaxes pretty equally. My choice in the original post was mostly because I was unsure about exactly how flexible the soft keywords in the new parser are, and if it would be tricky to insert them before an arbitrary assignment like that instead of making them be their own statement. If that's not an issue, I'm in favor of either syntax :)