Namespaces are one honking great idea

[Ethan Furman]

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. 
  Comments below.

> The Zen of Python says:
>
>      Namespaces are one honking great idea -- let's do more of those!

> Proposal
> =========
>
> Add a new "namespace" object to Python.


> Proof of concept
> =================
>
> Here's a proof of concept. I use a class with a custom metaclass like this:
>
>
> # Python 3 version
> class ExampleNS(metaclass=Namespace):
>      x = 1
>      y = []
>
>      def spam(n):
>          return 'spam'*n
>
>      z = spam(3).upper()
>
>      def ham(n):
>          return spam(n).replace('sp', 'H')
>
>      def test():
>          global x
>          x += 1
>          y.append(1)
>          return x, y
>

> 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?

Can a mini-module function access a different mini-module's function?

Can a mini-module function access/interact with the module's global scope?

> 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.

>      @namespace
>      class Example:
>          ...

I believe Python already has a NameSpace type, so a different name is 
probably better.  How about minimodule? ;)


> 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?

> 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?

> The biggest limitation is that I have to abuse the class statement to do
> this. In an ideal world, there would be syntactic support and a keyword:
>
>      namespace Example:
>          x = 0
>          y = []
>          def test(n): ...
>
> although others might argue that *not* needing a dedicated keyword is, in
> fact, better.

Metaclasses for the win!

> Disadvantages
> ==============
>
> Those unfamiliar with the namespace concept may be confused by a class that
> doesn't get instantiated.

A well-named decorator/base-class should help with that.


Did you mean for this to go to -Ideas?

--
~Ethan~