According to the documentation for types.SimpleNamespace, `repr(SimpleNamespace())` should return `"SimpleNamespace()"`, but in actuality returns `"namespace()"`. This is because SimpleNamespace is an alias for the C implemented type `_PyNamespaceObject`. Interestingly, `_PyNamespaceObject` names itself `"types.SimpleNamespace"`. This has the obvious issue of the documentation being wrong, but also the (perhaps less interesting issue) of `eval(repr(SimpleNamespace))` resulting in a NameError.

I propose that `_PyNamespaceObject`'s __repr__ method be changed to return `"SimpleNamespace(<args>)"`. This would require only the change of a constant in one line (currently this is line 75 on namespaceobject.c).

A smaller fix would be to change the documentation to correctly reflect this behavior.

I'm not sure what to think about this.

The type is explicitly exposed to Python code "SimpleNamespace" via the types module.  However, that's the same as how other builtin types are exposed in that module.  For example, the builtin `PyCode_Type` (for `PyCodeObject`) is exposed as `types.CodeType`.  I called it "SimpleNamespace" because "Namespace" (or "NamespaceType") was a little too unclear and I wanted it to say what it was.  In retrospect, "SimpleNamespace" was probably a good choice.

FYI, `tp_name` was originally set to "namespace", rather than "types.SimpleNamespace".  I changed it to "types.SimpleNamespace" to add pickle support (in b5c8f927829a1679c6748df84a6289fb68343e51, for bpo-15022).  IIRC, changing the name was the easiest was to allow pickle to find it.  That said, it would be better to do it properly and set `tp_name` to the correct value.

It would probably help to have a little more context on the name and my intentions. 
 When I added it (for use in the PEP 421 implementation), I thought of the type as one that others would find very useful.  So I imagined we would eventually expose it as one of the builtins.  Basically all the other builtin types have lowercase names, hence I named it "namespace".  I just didn't get around to proposing adding it to the builtins and it fell off my radar.  Note that changing the name to "types.SimpleNamespace", while primarly to benefit pickling, also made the type more discoverable, which becomes less relevant if it is a builtin.

FWIW, I still think it is a good candidate for the builtins, though I'd probably name it "simplenamespace" at this point.  Cementing the name as "types.SimpleNamespace" would probably be a disappointment for me.  Instead it would be better to fix the pickle support, so tp_name could go back to the correct name, and make it a builtin.  This isn't a priority for me, though, and I don't have a huge sense of ownership here, so I don't feel like I am in much of a position to champion my preferences on this.  (I'd be glad to mentor someone on this though.)

Thus I'm not sure what to think about this. :)

> According to the documentation for types.SimpleNamespace, `repr(SimpleNamespace())`
> should return `"SimpleNamespace()"`, but in actuality returns `"namespace()"`.

Note that I purposefully wrote "roughly" in the docs ("The type is roughly equivalent to the following code:").  That code was meant to illustrate the functionality rather than be proscriptive of the implementation.  That said, it certainly would be good for the documentation to match. :)

> but also the (perhaps less interesting issue) of `eval(repr(SimpleNamespace))` resulting in a NameError.

This is true of many of the types exposed by the types module (e.g. types.CodeType).

> I propose that `_PyNamespaceObject`'s __repr__ method be changed to return `"SimpleNamespace(<args>)"`.

My preference would be as outlined in my previous comment: make it a builtin.  However, I'm not in a position to make that happen at the moment.

Given how long this object has been its current state, the OP's request seems reasonable to me and it is an easy change to make.  I don't think there is any downside.  Also, if this ever becomes a builtin, I think we would leave the current implementation in place and deprecate it over the course of a couple of releases.  So making any improvements now probably wouldn't get in the way of a proposal to have a builtin namespace object.