Right now object() does not accept any args and returns the lightest possible featureless object (i.e., without even a __dict__).

This is great.

However, it is really useful sometimes to be able to create an object to hold some editable state (so not a namedtuple). Right now this can be done with types.SimpleNamespace().

I think it would be a useful enhancement to have object() work as it does now, but to allow it to accept kwargs in which case it would provide identical functionality to types.SimpleNamespace().

This arises from an email I wrote to the python mailinglist:
https://groups.google.com/d/msg/comp.lang.python/9pY7hLp8lDg/voYF8nMO6x8J

But I also think it would be useful more generally.

This will be fragile because the behavior will be depend from the number of keyword argument. Hypothetic example:

>>> kwargs = {'a': 1}
>>> obj = object(**kwargs)
>>> obj.b = 2  # success
>>> kwargs = {}  # empty
>>> obj = object(**kwargs)
>>> obj.b = 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'object' object has no attribute 'b'

For now you need only one or two line of code to declare new class.

>>> class Object: pass
... 
>>> obj = Object()
>>> obj.a = 1
>>> obj.b = 2

As a work around for the originator how about

>>> pyobject = object # keep reference to built-in.
>>> from types import SimpleNamespace as object
>>> help(object)
Help on class SimpleNamespace in module types:
...

???

Making types.SimpleNamespace more easily available might be a good idea. Screwing around with our fundamental base class to do so is not.  Neither is rebinding the builtin name 'object'.  Find a different way to accomplish the goal.

SimpleNamespace *could* have been added to builtins, but was not.  Instead, it was added to types, which is the catchall for types not used enough to be in builtins.  Someone might check the issue or list discussion as to why.

At one time object had the bug of silently ignoring arguments. Years ago, Guido insisted that this be fixed and wrote patches himself. See #1683368. For one thing, raising the exception catches bugs with cooperative multiple inheritance and super calls. I believe having object() return a subclass of object that in not a superclass of other classes would be worse than the previous bug.

I think this idea should have been left on python-list or moved to python-ideas for further development.  I am sure that the proposal as stated should be rejected.

I changed my suggestion but did so on the mailing list instead of here:

This (importing & using types.SimpleNamespace()) is too much for children (& beginners).

But perhaps what I should be asking for is for a new built-in that does what types.SimpleNamespace() does, so that without any import you can write, say,

foo = namespace(a=1, b=2)
# or
bar = namespace()
bar.a = 1

where under the hood namespace has the same behavior as types.SimpleNamespace().

Naturally, I understand that adding a new name is a big deal and may be too much to ask for beginners. 

I've renamed the issue to reflect this (although I don't know if that will work).

Alternatively, I (or someone) could just close the issue as "won't fix"; it was just an idea.

I'm not in favor of changing object() but exposing types.SimpleNamespace as built-in namespace() doesn't seem like such a bad idea, especially given Tim's penultimate Zen aphorism.

+1 for the 'namespace' builtin.  It looks as though whoever wrote `SimpleNamespace.__repr__` anticipated this:

>>> ns = types.SimpleNamespace(a=3, b=4)
>>> ns
namespace(a=3, b=4)

types.SimpleNamespace was added as an implementation detail of the "sys.implementation" PEP. It's not a builtin yet, solely because we get far fewer arguments about the contents of the types module than we do builtins :)

I'd be +1 on a PEP to also expose it as a "namespace" builtin.

On Aug 06, 2014, at 09:43 PM, Nick Coghlan wrote:

>I'd be +1 on a PEP to also expose it as a "namespace" builtin.

Is a PEP necessary?  Seems like a rather isolated and simple enhancement.

It's a new builtin, so I think at least a simple PEP is needed for
traceability. The existence of types.SimpleNamespace should let us duck 99%
of the bikeshedding - it's a new name for an existing type, not a new type.

Agreed that a PEP would be necessary, even if it ends up sweet and simple.

I'd be happy to draft a PEP if it is needed, if no one else has the time/inclination.

> It's not a builtin yet, solely because we get far fewer arguments about the contents of the types module than we do builtins :)

Exactly.  As Mark noted, I did have hopes of it reaching that status though. :) So +1 from me for adding the namespace builtin!

-1 on moving this to builtin status.  For a long time, we've tried to keep a back pressure against adding more builtins (in part because it increases the learning curve for the core language).   The SimpleNamespace() type would need to become *much* more popular to warrant becoming a builtin (even then, other tools such as copy.copy() or collections.OrderedDict() would likely be able to make stronger claims).  AFAICT, the SimpleNamespace() class has been used exactly once is the standard library (in venv) and almost not at all in published code.  IMO, it is *very* far from warranting builtin status.

Five years have passed with no one pushing this forward.  During that time, types.SimpleNamespace() has diminished in popularity and dataclasses have risen as a better general purpose data holder.

Marking this as closed.