On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote: > On 07/01/2016 07:13 AM, Steven D'Aprano wrote: > > I like the idea, but I have a couple questions about the design choices.
Thanks! > Comments below. [...] >> Despite the "class" statement (a limitation of Python's lack of dedicated >> syntax for namespaces), the Example namespace behaves like (in fact, >> *is*) a module embedded inside a module. > > So the idea is to have several "mini-modules" inside a single file? That would certainly be possible. > Can a mini-module function access a different mini-module's function? Yes, via the dotted attribute name, just as you might say "math.sin". The only difference is that you don't use import to get access to the (mini-)module. It's just there, defined in your own file. > Can a mini-module function access/interact with the module's global scope? Yes. I'm still experimenting with different implementations, but I have a proof of concept working. >> Especially note that inside the namespace, the global statement makes a >> name refer to the namespace scope. > > Interesting. :) > > >> Unresolved questions >> ===================== >> >> Would a decorator be better than a metaclass? > > I think a decorator may provide more of a clue that something > interesting is happening -- whether a decorator is feasible depends on > whether you need the __prepare__ magic of metaclasses. I don't think __prepare__ is needed. >> @namespace >> class Example: >> ... > > I believe Python already has a NameSpace type, so a different name is > probably better. How about minimodule? ;) I think you are thinking of "SimpleNamespace". In any case, so long as my namespace lives in a different, er, namespace as the other namespace, there's no conflict :-) In the long term, I think my namespace (if accepted into the stdlib) would belong in functools, collections or types. Perhaps even its own module. I don't think this needs to be a built-in. >> Some limitations >> ================= >> >> The simplified implementation shown doesn't allow functions inside the >> namespace to access names outside of the namespace easily. > > How not-easy is it? Not that hard now. I have an implementation working. It actually turned out to be easy. (Thanks Raymond for ChainMap!) >> In practice, the >> user might want the name resolution order inside the namespace to be: >> >> local variables >> nonlocal variables >> namespace globals >> module globals >> builtins > > That would be ideal, I think. How close can we get to that? I now have that working, for some definition of working. Its not extensively tested, so there might be some bugs or issues I haven't thought of, but the basic concept is working: inside the namespace/mini-module object, functions see namespace globals ahead of module globals, which are ahead of builtins. [...] > Did you mean for this to go to -Ideas? Not yet. I wanted some initial feedback to see if anyone else liked the idea before taking it to Bikeshedding Central :-) Besides, I expect Python-Ideas will say it needs to be a package on PpPI first. Although I am kinda considering sneaking this into the std lib as an undocumented internal feature, like simplegeneric in pkgutil. (Don't tell anyone I said that *wink* ) -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
