So for simplicity let's assume that the content of 'bar' is 3, and let's assume that the module is __main__


>>> vars(sys.modules[__name__])[""]

And it can be accessed in the usual way like:


Likewise for the namespace objects that are created during the namespace block:

>>> vars(sys.modules[__name__])["A"]
<namespace object <A> of <module '__main__' (built-in)>>

>>> A.B
<namespace object <A.B> of  <module '__main__' (built-in)>>

The key point here is that if you dynamically iterate over the contents of the module you will get all the objects that were set within any namespace blocks. Unlike nesting class blocks and using class attributes, you won't have to recursively descend into the namespaces. The namespace objects are left behind as a convenience to enable classic attribute access, but they don't 'own' the attributes that were set within their scope. The (in this case) module does. The only reference the namespace has is (in this case) to the module.

Note that namespaces within modules aren't the most interesting case. Namespaces within class blocks and for class instance attributes are much more likely to be where this feature would offer big wins in code clarity.

For a class block:

class Example:
    namespace foo:
        def bar(self):
            ...  # implementation goes here


>>> vars(Example)[""]

Which should generally be accessed like:


Likewise, the namespace object:

<namespace object <foo> of  <class '__main__. Example'>>

And from an instance the function becomes a method as normal:

>>> Example()
<bound method of <__main__.Example object at {memory_address}>>

There are code examples in here that hopefully give a better feel for the benefits of grouping methods of classes into namespaces:

On Mon, May 3, 2021 at 1:25 PM Calvin Spealman <> wrote:
OK, tell me what this does.

namespace A:
    namespace B:
        foo = bar

On Sat, May 1, 2021 at 7:55 PM Matt del Valle <> wrote:
Hi all!

So this is a proposal for a new soft language keyword:


I started writing this up a few hours ago and then realized as it was starting to get away from me that there was no way this was going to be even remotely readable in email format, so I created a repo for it instead and will just link to it here. The content of the post is the, which github will render for you at the following link:

I'll give the TLDR form here, but I would ask that before you reply please read the full thing first, since I don't think a few bullet-points give the necessary context. You might end up bringing up points I've already addressed. It will also be very hard to see the potential benefits without seeing some actual code examples.


- In a single sentence: this proposal aims to add syntactic sugar for setting and accessing module/class/local attributes with dots in their name

- the syntax for the namespace keyword is similar to the simplest form of a class definition statement (one that implicitly inherits from object), so:

namespace some_name:
   ...  # code goes here

- any name bound within the namespace block is bound in exactly the same way it would be bound if the namespace block were not there, except that the namespace's name and a dot are prepended to the key when being inserted into the module/class/locals dict.

- a namespace block leaves behind an object that serves to process attribute lookups on it by prepending its name plus a dot to the lookup and then delegating it to whatever object it is in scope of (module/class/locals)

- This would allow for small performance wins by replacing the use of class declarations that is currently common in python for namespacing, as well as making the writer's intent explicit

- Crucially, it allows for namespacing the content of classes, by grouping together related methods. This improves code clarity and is useful for library authors who design their libraries with IDE autocompletion in mind. This cannot currently be done by nesting classes.

I live in the UK so I'm going to bed now (after working on this for like the last 6 hours). I'll be alive again in maybe 8 hours or so and will be able to reply to any posts here then.

Cheers everyone :)
Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: