What's going on here?

[Dale Strickland-Clark]

Python 2.4.2 (#1, Oct 13 2006, 17:11:24)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
.... pass
....
What is subclassing adding to the class here? Why can't I assign to
attributes of an instance of object?

 

[Scott David Daniels]

Python 2.4.2 (#1, Oct 13 2006, 17:11:24)
Traceback (most recent call last):


What is subclassing adding to the class here? Why can't I assign to
attributes of an instance of object?

object itself doesn't have a __dict__ slot, so that very small objects
(such as points) can be built without that overhead.

--Scott David Daniels
(e-mail address removed)

 

[Gerald Klix]

Perhaps this piece of code might explain the behaviour:

.... __slots__ = ()
....Traceback (most recent call last):
File "<input>", line 1, in ?
AttributeError: 'C' object has no attribute 'a'


object behaves like having an implict __slots__ attribute.


HTH,
Gerald

Python 2.4.2 (#1, Oct 13 2006, 17:11:24)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

Traceback (most recent call last):

... pass
...


What is subclassing adding to the class here? Why can't I assign to
attributes of an instance of object?

 

[Richie Hindle]

What is subclassing adding to the class here?

A __dict__:
['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__',
'__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__str__']['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__module__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__']

 

[Fredrik Lundh]

Why can't I assign to attributes of an instance of object?

it doesn't have any attribute storage.

</F>

 

[robert]

Python 2.4.2 (#1, Oct 13 2006, 17:11:24)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
... pass
...
What is subclassing adding to the class here? Why can't I assign to
attributes of an instance of object?

Python sooooo dynamic, but it lacks a (builtin) X-class ready for ad-hoc usage just like dict()
I have in almost every app/toolcore-module this one:

------

class X(object):
def __init__(self,_d={},**kwargs):
kwargs.update(_d)
self.__dict__=kwargs
class Y(X):
def __repr__(self):
return '<Y:%s>'%self.__dict__

------

x=X(spam=1)

Maybe X should be renamed to __builtin__.Object ...


Robert

 

[John Machin]

Python 2.4.2 (#1, Oct 13 2006, 17:11:24)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

a = object()
a

a.spam = 1

Traceback (most recent call last):

class b(object):

... pass
...

a = b()
a

a.spam = 1

What is subclassing adding to the class here? Why can't I assign to
attributes of an instance of object?

Python sooooo dynamic, but it lacks a (builtin) X-class ready for ad-hoc usage just like dict()
I have in almost every app/toolcore-module this one:

------

class X(object):
def __init__(self,_d={},**kwargs):
kwargs.update(_d)
self.__dict__=kwargs
class Y(X):
def __repr__(self):
return '<Y:%s>'%self.__dict__

------

x=X(spam=1)

Maybe X should be renamed to __builtin__.Object ...

Have you considered putting it in one file and *importing* it into
"almost every app/toolcore-module"?

Have you considered that others may like to have something a little
more elaborate, like maybe using the pprint module, or that the amount
of data that would spew out might in some cases be so great that they
wouldn't want that every time from repr(), preferring a dump-style
method that wrote to a logfile?

IMHO that's one of the enormous number of good points about Python; you
can easily lash up something like that to suit yourself and inject it
into any class you like; there's no central authority tying your hands
behind your back.

HTH,
John

 

[robert]

Python 2.4.2 (#1, Oct 13 2006, 17:11:24)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
a = object()
a
<object object at 0xb7bbd438>
a.spam = 1
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'object' object has no attribute 'spam'
class b(object):
... pass
...
a = b()
a
<__main__.b object at 0xb7b4dcac>
a.spam = 1

What is subclassing adding to the class here? Why can't I assign to
attributes of an instance of object?

Python sooooo dynamic, but it lacks a (builtin) X-class ready for ad-hoc usage just like dict()
I have in almost every app/toolcore-module this one:

------

class X(object):
def __init__(self,_d={},**kwargs):
kwargs.update(_d)
self.__dict__=kwargs
class Y(X):
def __repr__(self):
return '<Y:%s>'%self.__dict__

------

x=X(spam=1)

Maybe X should be renamed to __builtin__.Object ...

Have you considered putting it in one file and *importing* it into
"almost every app/toolcore-module"?

(yes its in my core python "language extension" module, which I import frequently in apps)

Have you considered that others may like to have something a little
more elaborate, like maybe using the pprint module, or that the amount
of data that would spew out might in some cases be so great that they
wouldn't want that every time from repr(), preferring a dump-style
method that wrote to a logfile?

(in X is no repr so far. of course one could make a default repr with short output. had no frequent needs so far)

IMHO that's one of the enormous number of good points about Python; you
can easily lash up something like that to suit yourself and inject it
into any class you like; there's no central authority tying your hands
behind your back.

its more about the general case, trying things out on the interactive etc. always - thus when I want speed not "suit"

very often I need a dummy object and find me always typing "class Xass" or import above tools.
Think this trivial but needed Object() thing is possibly more than a private sitecustomize-thing. Thats why I wrote here upon seeing others trying object() which doesn't do what one expects at first.
It wouldn't really tie hands or ? but possibly converse

Robert

 

[Dale Strickland-Clark]

Thanks for the answers. I am informed but I don't feel enlightened.

It does strike me as odd that an apparently empty subclass should add extra
function to the base class.

Not at all obvious.

 

[robert]

Thanks for the answers. I am informed but I don't feel enlightened.

It does strike me as odd that an apparently empty subclass should add extra
function to the base class.

Not at all obvious.

Yes. As said, there is missing a __builtin__.Object

object is not an "empty class", but the base builtin-type:
True

built-in type instances are basically read-only because if ...

Traceback (most recent call last):


...would work, that would be very strange.
Maybe in a mud place language like Ruby, where you can jam and scribble everywhere in the system and in builtins, such things are possible.


I'd propose to add something trivial like


class Object(object):
def __init__(self,_d={},**kwargs):
kwargs.update(_d)
self.__dict__=kwargs
...

to Python. I use such empty (common) class since all time I can think of - and frequently.
If there would be a common such Empty class in Python you'd have a lot of advantanges. From ad-hoc instances, "OO-dicts" to reliable pickling of bunches of variables etc.


Robert

 

[Carl Banks]

Thanks for the answers. I am informed but I don't feel enlightened.

It does strike me as odd that an apparently empty subclass should add extra
function to the base class.

Not at all obvious.

Remember that a class definition is syntax sugar for a direct call to
type:

type(name,bases,clsdict)

This constructs and returns the class. It's free to add behaviors even
if the clsdict is empty, and that's exactly what it does in this case.
type considers the absence of __slots__ in clsdict to be a request for
an instance dict, and so it adds one. (Types defined in C aren't
created that way, however. I believe C-defined types request an
instance dict by reserving space for it in the object structure and
setting tp_dictoffset to indicate its offset.)

This is not obvious, but it's really the only reasonable way. You
can't have the base class of all objects creating dicts for its
instances--you wouldn't want every int object to have it's own dict.
And you can't have Python class instances not have a dict by default.


Carl Banks