Can we create an_object = object() and add attribute like for a class?
Pierre Rouleau
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.
>>> a = object()
>>> a.data = 1
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'object' object has no attribute 'data'
>>>
>>> class Object:
... pass
...
>>> a = Object()
>>> a.data = 1
>>> print "a.data = ", a.data
a.data = 1
>>>
>>> class Object2(object):
... pass
...
>>> b = Object2()
>>> b.data = 2
>>> b.data
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.
--
Pierre Rouleau
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
> Pierre Rouleau <prou...@impathnetworks.com> wrote:
>
>
>>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),
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...
>
>
>>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...).
>
>
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.
--
Pierre Rouleau
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
ok... I should have said "something like the built-in object type"
instead of "standard library"...
--
Pierre Rouleau
Alex Martelli
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