Namespaces are one honking great idea
Steven D'Aprano
steve at pearwood.info
Fri Jul 1 13:10:05 EDT 2016
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.
More information about the Python-list
mailing list