Can we create an_object = object() and add attribute like for a class?

[Pierre Rouleau]

Hi all,

Is there any reason that under Python you cannot instantiate the object
class and create any attributes like you would be able for a normal class?

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
.... pass
........ pass
....2

I also tried with Python 2.4.3 with the same results.
Being able to do it would seem a natural way of declaring namespaces.

 

[Alex Martelli]

Hi all,

Is there any reason that under Python you cannot instantiate the object
class and create any attributes like you would be able for a normal class?

Yep: instances of type object do not have a __dict__ and therefore there
is no place to put any attributes. This is necessary to allow ANY
subclass of object, and thus any type whatsoever, to lack a per-instance
__dict__ (and thus to save its per-instance memory costs), since by the
principle of inheritance (known as Liskov substutition, or also as the
"IS-A" rule) a subclass cannot _remove_ superclass attributes, so if the
universal superclass had a __dict__ so would every type in Python.

Being able to do it would seem a natural way of declaring namespaces.

I find that ns = type('somename', (), dict(anattribute=23)) isn't too
bad to make a namespace ns, though it has some undesirable issues (e.g.,
ns is implicitly callable, which may make little sense for a namespace).

At any rate, any natural way of declaring a namespace SHOULD allow
arbitrary named arguments in the instantiation call -- bending
principles to give each instance of object a __dict__ would still not
fix that, so that wouldn't do much. I think it's worth the minor bother
to write out something like

class Namespace(object):
def __init__(self, **kwds): self.__dict__ = kwds

and I generally go further anyway, by defining at least a repr that
shows the attributes' names and values (very useful for debugging...).


Alex

 

[Pierre Rouleau]

Yep: instances of type object do not have a __dict__ and therefore there
is no place to put any attributes. This is necessary to allow ANY
subclass of object, and thus any type whatsoever, to lack a per-instance
__dict__ (and thus to save its per-instance memory costs),

Makes sense. I was under the impresssion that instances of type object
did have a __dict__ but was hidden for some reason. I should have known
.... explicit is better than implicit...

I find that ns = type('somename', (), dict(anattribute=23)) isn't too
bad to make a namespace ns, though it has some undesirable issues (e.g.,
ns is implicitly callable, which may make little sense for a namespace).

At any rate, any natural way of declaring a namespace SHOULD allow
arbitrary named arguments in the instantiation call -- bending
principles to give each instance of object a __dict__ would still not
fix that, so that wouldn't do much. I think it's worth the minor bother
to write out something like

class Namespace(object):
def __init__(self, **kwds): self.__dict__ = kwds

and I generally go further anyway, by defining at least a repr that
shows the attributes' names and values (very useful for debugging...).

That's what I do too, but sometimes i just want to have a quick holder
attribute in a class and am lazy to do it. I could declare one such
class inside a module and import it but again, that means importing,
name space of the module, etc...

I can understand the design decision not to give object a __dict__, but
I wonder if i'd be a good idea to have a class that derives from object
and has a __dict__ to be in the standard library. I posted the original
question because I run into this quite often and I just saw a post a
little before mine ("self modifying code") where the idiom was used.

 

[Alex Martelli]

I can understand the design decision not to give object a __dict__, but
I wonder if i'd be a good idea to have a class that derives from object
and has a __dict__ to be in the standard library. I posted the original
question because I run into this quite often and I just saw a post a
little before mine ("self modifying code") where the idiom was used.

Yes, I do agree it would be a good idea. It's probably too late to add
features to Python 2.5, but I think you should propose a PEP for 2.6.
Standard library module containers seems to be a good place for the
proposed namespace-type, but some discussion might help get some idea of
a consensus about the type's name (is 'namespace' good enough? Is an
__init__ taking arbitrary named arguments, and a __repr__ emitting them,
all the functionality we need -- or should perhaps the type also expose
some other methods delegating to the underlying __dict__, such as
__len__ [[number of attributes]], update, __contains__, __iter__...?).


Alex

 

[Fredrik Lundh]

I can understand the design decision not to give object a __dict__, but
I wonder if i'd be a good idea to have a class that derives from object
and has a __dict__ to be in the standard library.

so you can replace one line of code in some of your programs with
an import statement ?

cute.

</F>

 

[Pierre Rouleau]

Pierre Rouleau wrote:




so you can replace one line of code in some of your programs with
an import statement ?

ok... I should have said "something like the built-in object type"
instead of "standard library"...

 

[Alex Martelli]

ok... I should have said "something like the built-in object type"
instead of "standard library"...

I'm -1 on adding a new built-in for this functionality -- it's just not
important enough to warrant a built-in (there are already too many
built-ins!).

Putting a "namespace type" in the standard library could provide enough
helpful functionality to make an import well warranted, so I'm +1 on
adding such a type to the standard library (in 2.6 -- I think it's too
late for 2.6).


Alex