Builtin "export" decorator/function

[Rosuav (Chris Angelico)]

@jsbueno

As a late arriver to the thread - the o.p. asking for an “export” just looks like some, with no ofense needed, a “javascriptcism”.
Python does not need it because it has module namespaces - while Javascript, without such mechanisms, would have all declared functions, classes, etc…in all modules of a project being in a common global namespace.

That’s not really fair to JavaScript; if you’re using “export” in JS, you’re using modules, and that means you get module namespaces. (Some implementations do this by stuffing all the code together, then having each module execute inside its own nested function, so non-exported names are simply function-local variables.) A quick comparison:

• Python modules export everything by default, unless you define __all__. JavaScript modules must explicitly export everything they want to be made available.
• JavaScript allows you to tag a variable or class declaration for export. Python doesn’t, but that’s what tools like atpublic are for.
• In Python, import foo gives you a module object with all of foo’s exports. In JS, that’s written as import * as foo from "./foo", and is a much less common thing to do.
• JavaScript has a notion of “default exports”, which Python doesn’t have (and IMO doesn’t need).

Features across the two are pretty similar. There aren’t major distinctions, just minor feature differences.

Personally, I’m not really comfortable with the public(foo=1) syntax, but the decorator syntax is handy.