Add Properties to Instances?

[Martin Miller]

I'm trying to create some read-only instance specific properties, but
the following attempt didn't work:

class Foobar(object):
pass

foobar = Foobar()
foobar.x = property(fget=lambda: 42)

print "foobar.x:", foobar.x

Which results in the following ouput instead of '42':
foobar.x: <property object at 0x00AE57B0>

I also tried this:

foobar.__dict__['x'] = property(fget=lambda: 42)

but get the same behavior.

Can anyone tell me what's wrong with this approach (and perhaps the
correct way to do it, if there is one)?

TIA,
Martin

 

[Steven Bethard]

I'm trying to create some read-only instance specific properties, but
the following attempt didn't work:

class Foobar(object):
pass

foobar = Foobar()
foobar.x = property(fget=lambda: 42)

print "foobar.x:", foobar.x

[snip]

Can anyone tell me what's wrong with this approach (and perhaps the
correct way to do it, if there is one)?

Properties cannot be defined on a per-instance basis. Properties must
be defined at the class level. So you need to do something like:

py> class Foobar(object):
.... x = property(fget=lambda self: 42)
....
py> Foobar().x
42

or

py> class Foobar(object):
.... pass
....
py> Foobar.x = property(fget=lambda self: 42)
py> Foobar().x
42

If you want to have different properties on different instances, you'll
need to make each of the different instances a different subtype of
Foobar, e.g.:

py> class Foobar(object):
.... pass
....
py> foobar = type('FoobarSub', (Foobar,),
.... dict(x=property(fget=lambda self: 42)))()
py> foobar.x
42
py> Foobar().x
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
AttributeError: 'Foobar' object has no attribute 'x'

What's the situation in which you think you want different properties
for different instances of the same class?

STeVe

 

[Jeremy Bowers]

I'm trying to create some read-only instance specific properties, but the
following attempt didn't work:

I'm going to echo Steven's comment: "What's the situation in which you
think you want different properties for different instances of the same
class?"

Another thought would be a custom __setattr__ and a bit of support:

Python 2.3.5 (#1, Mar 3 2005, 17:32:12)
[GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2
Type "help", "copyright", "credits" or "license" for more information..... def __init__(self):
.... self.__dict__['_readOnly'] = sets.Set()
.... def addReadOnly(self, key, value):
.... setattr(self, key, value)
.... self._readOnly.add(key)
.... def __setattr__(self, key, value):
.... if key in self._readOnly:
.... raise AttributeError("can't set attribute")
.... self.__dict__[key] = value
.... Traceback (most recent call last):
File "<stdin>", line 1, in ?
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 5, in addReadOnly

I don't guarantee this completely fits the bill but I'm sure you can adapt
it from here.

Also note that, strictly speaking, you can't make a "true" read-only
attribute, only one that alerts a programmer if they try the simple way.
In a pure-Python object, there is always a way in. This shouldn't worry
you if you're using Python ("We're all consenting adults here"), but you
should also be aware of that. That said, this is certainly useful in the
real world.

 

[Martin Miller]

So far a couple of people have asked:

What's the situation in which you think you want different properties
for different instances of the same class?

Fair enough -- here goes:

Essentially what I'm doing is implementing (yes, yet another ;-)
'enumeration' class using an an approach which involves an instance
factory function which returns a customized version of a predefined
generic '_Enum' class instance.

It does this by first creating an instance of the generic class and
then adds attributes (enumerator ids and corresponding values among
others) to it which are specific to the enumeration being created. This
all works pretty well, but I would like to make the values associated
with the ids immutable -- through normal means, at least.

It's not feature complete, but I would be happy post the current code
if there is interest in more of the details. Meanwhile, I'm going to
study the replies so far and think about the whole issue (and design) a
little more.

Thanks to all who have replied,
Martin

 

[Bengt Richter]

I'm trying to create some read-only instance specific properties, but
the following attempt didn't work:

class Foobar(object):
pass

foobar = Foobar()
foobar.x = property(fget=lambda: 42)

print "foobar.x:", foobar.x

Which results in the following ouput instead of '42':
foobar.x: <property object at 0x00AE57B0>

I also tried this:

foobar.__dict__['x'] = property(fget=lambda: 42)

but get the same behavior.

Can anyone tell me what's wrong with this approach (and perhaps the
correct way to do it, if there is one)?

One way is to doctor the instance attribute access to do what
happens with a property when it is implemented normally as an
attribute of the class. E.g., (using InstProp in place of your Foobar)
... def __getattribute__(self, attr):
... p = object.__getattribute__(self, attr)
... if isinstance(p, property): return p.__get__(self)
... return p
... 'prop2'

If you want robust writeable and/or deleteable properties, you will have
to do a little more work, but it can be done.

Regards,
Bengt Richter

 

[Bengt Richter]

I'm trying to create some read-only instance specific properties, but
the following attempt didn't work:

class Foobar(object):
pass

foobar = Foobar()
foobar.x = property(fget=lambda: 42)

print "foobar.x:", foobar.x

Which results in the following ouput instead of '42':
foobar.x: <property object at 0x00AE57B0>

I also tried this:

foobar.__dict__['x'] = property(fget=lambda: 42)

but get the same behavior.

Can anyone tell me what's wrong with this approach (and perhaps the
correct way to do it, if there is one)?

One way is to doctor the instance attribute access to do what
happens with a property when it is implemented normally as an
attribute of the class. E.g., (using InstProp in place of your Foobar)
... def __getattribute__(self, attr):
... p = object.__getattribute__(self, attr)
... if isinstance(p, property): return p.__get__(self)
... return p
...

Actually, checking for being a property instance is more restrictive than
normal default processing. Checking for __get__ would be better.

This would let you use a function as an instance-specific method as well,
since functions have __get__ methods, and that is how they become bound
methods etc. We'll also pass the type of the instance, to give __get__
everything it needs for a proper bound method.
... def __getattribute__(self, attr):
... p = object.__getattribute__(self, attr)
... if hasattr(p, '__get__'): return p.__get__(self, type(self))
... return p
... 'property p'

Regards,
Bengt Richter

 

[Martin Miller]

In answer to my question about instance properties not working, Bengt
Richter suggest using:
and more generally for any descriptor object:

... def __getattribute__(self, attr):
... p = object.__getattribute__(self, attr)
... if hasattr(p, '__get__'): return p.__get__(self, type(self))
... return p

Both the above makes the '__get__' method of any property attributes of
the instance to be used. However, it does not cause attempts to be made
to access their "__set__' methods when assigning to them (which should
fail in my case because my properties don't have such a method because
they are read-only).

Just overriding '__getattribute__' alone is insufficent to make
instance property/descriptor attributes fully function. To do so also
requires overriding the __setattr__ method so it checks for a '__set__'
method and then uses it if one is found (or delegates it to
object.__setattr__ if not).

Similarily, an override for '__delattr__' would also be need for
complete property functionality, I believe.

For just making instance attributes read-only, it seems to be that the
simplist solution would be to override __setattr__ and make it check to
see if the attribute is write protected or not, which is really all I
need for the specific task I'm trying to accomplish (which is
esstentially what Jeremy Bowers said in his reply).

What still puzzles me, though, is why all the above to make properties
work on instances is necessary in the first place. It's certainly not
clear (to me) from what is said in the How-to at:http://users.rcn.com/python/download/Descriptor.htm#invoking-descriptors
I suspect that it may be simply a performance issue, in other words, it
was considered too slow to check for instance property/discriptors --
although *why* is not clear to me.

Best Regards,
Martin

 

[Bengt Richter]

In answer to my question about instance properties not working, Bengt
Richter suggest using:

and more generally for any descriptor object:


Both the above makes the '__get__' method of any property attributes of
the instance to be used. However, it does not cause attempts to be made
to access their "__set__' methods when assigning to them (which should
fail in my case because my properties don't have such a method because
they are read-only).

Just overriding '__getattribute__' alone is insufficent to make
instance property/descriptor attributes fully function. To do so also
requires overriding the __setattr__ method so it checks for a '__set__'
method and then uses it if one is found (or delegates it to
object.__setattr__ if not).

Similarily, an override for '__delattr__' would also be need for
complete property functionality, I believe.

As I said in my first post,
"""
If you want robust writeable and/or deleteable properties, you will have
to do a little more work, but it can be done.
"""

I'm still leaving it as an exercise ;-)

For just making instance attributes read-only, it seems to be that the
simplist solution would be to override __setattr__ and make it check to
see if the attribute is write protected or not, which is really all I
need for the specific task I'm trying to accomplish (which is
esstentially what Jeremy Bowers said in his reply).

What still puzzles me, though, is why all the above to make properties
work on instances is necessary in the first place. It's certainly not
clear (to me) from what is said in the How-to at:
http://users.rcn.com/python/download/Descriptor.htm#invoking-descriptors
I suspect that it may be simply a performance issue, in other words, it
was considered too slow to check for instance property/discriptors --
although *why* is not clear to me.

I suspect the desired semantics re precedence have evolved to make normal
programs easily implementable, and that probably drove the implementation:
"""
For objects, the machinery is in object.__getattribute__ which transforms
b.x into type(b).__dict__['x'].__get__(b, type(b)).
The implementation works through a precedence chain that gives (my added [1,2,3])

[1] data descriptors priority over instance variables,
[2] instance variables priority over non-data descriptors,
[3] and assigns lowest priority to __getattr__ if provided.

The full C implementation can be found in PyObject_GenericGetAttr() in Objects/object.c.
"""

Regards,
Bengt Richter

 

[Martin Miller]

Bengt Richter wrote, in part:

What still puzzles me, though, is why all the above to make properties
work on instances is necessary in the first place. It's certainly not
clear (to me) from what is said in the How-to at:
http://users.rcn.com/python/download/Descriptor.htm#invoking-descriptors
I suspect that it may be simply a performance issue, in other words, it
was considered too slow to check for instance property/discriptors --
although *why* is not clear to me.

I suspect the desired semantics re precedence have evolved to make normal
programs easily implementable, and that probably drove the implementation:
"""
For objects, the machinery is in object.__getattribute__ which transforms
b.x into type(b).__dict__['x'].__get__(b, type(b)).
The implementation works through a precedence chain that gives (my added
[1,2,3])

[1] data descriptors priority over instance variables,
[2] instance variables priority over non-data descriptors,
[3] and assigns lowest priority to __getattr__ if provided.

The full C implementation can be found in PyObject_GenericGetAttr() in
Objects/object.c.
"""

I haven't examined the C code in Objects/object.c to see *how* the
semantics are implemented because that's not really the point...which
is the descriptions of what's suppose to happen don't seem to match
what actually does. To illustrate, consider:

class Foobar(object):
pass

def myget(self, obj, type=None):
return 42

def myset(self, value):
raise AttributeError("this is a read-only property")

foobar = Foobar()
foobar.x = property(myget, myset)

print "foobar.x:", foobar.x

Which prints:

foobar.x: <property object at 0x00AE5850>

Ignoring "why" issue, my question becomes:

foobar.x is a data descriptor property, however object.__getattribute__
does *not* seem to be treating it as such and handling it the way
described either by you or in what is written in the how-to.
Specifically the statements that:

For objects, the machinery is in object.__getattribute__ which transforms
b.x into type(b).__dict__['x'].__get__(b, type(b)).

This doesn't seem to be occuring. Am I missing something?

Thanks,
Martin

 

[Bengt Richter]

Bengt Richter wrote, in part:

What still puzzles me, though, is why all the above to make properties
work on instances is necessary in the first place. It's certainly not
clear (to me) from what is said in the How-to at:

http://users.rcn.com/python/download/Descriptor.htm#invoking-descriptors
I suspect that it may be simply a performance issue, in other words, it
was considered too slow to check for instance property/discriptors --
although *why* is not clear to me.

I suspect the desired semantics re precedence have evolved to make normal
programs easily implementable, and that probably drove the implementation:
"""
For objects, the machinery is in object.__getattribute__ which transforms
b.x into type(b).__dict__['x'].__get__(b, type(b)).
The implementation works through a precedence chain that gives (my added
[1,2,3])

[1] data descriptors priority over instance variables,
[2] instance variables priority over non-data descriptors,
[3] and assigns lowest priority to __getattr__ if provided.

The full C implementation can be found in PyObject_GenericGetAttr() in
Objects/object.c.
"""

I haven't examined the C code in Objects/object.c to see *how* the
semantics are implemented because that's not really the point...which
is the descriptions of what's suppose to happen don't seem to match
what actually does. To illustrate, consider:

class Foobar(object):
pass

def myget(self, obj, type=None):
return 42

def myset(self, value):
raise AttributeError("this is a read-only property")

foobar = Foobar()
foobar.x = property(myget, myset)

print "foobar.x:", foobar.x

Which prints:

foobar.x: <property object at 0x00AE5850>

Ignoring "why" issue, my question becomes:

foobar.x is a data descriptor property, however object.__getattribute__

It is a property, and it has the requisite methods (__get__ and __set__) to be
a data descriptor, but it is not a data descriptor unless it is visible as
an attribute of type(foobar), which foobar.x is not.

does *not* seem to be treating it as such and handling it the way
described either by you or in what is written in the how-to.
Specifically the statements that:

For objects, the machinery is in object.__getattribute__ which transforms
b.x into type(b).__dict__['x'].__get__(b, type(b)).

This doesn't seem to be occuring. Am I missing something?

I think so. Following your example:
... pass
... ... return 42
... ... raise AttributeError("this is a read-only property")
...

>>> foobar = Foobar()
>>> foobar.x = property(myget, myset)
>>> print "foobar.x:", foobar.x

>>>
>>> type(foobar).__dict__['x']

Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: 'x'

meaning
b.x into type(b).__dict__['x'].__get__(b, type(b)).
does not apply, and the attempt to get foobar.x falls back to
ordinary attribute access. I.e., foobar.x will be whatever

BTW, I'm not sure type(b).__dict__['x'].__get__(b, type(b))
is really fully correct, since that would not find foobar.x in a Foobar base class:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: myget() takes at least 2 arguments (1 given)

(At least it was found, even if the signature is bad ;-)

But:

>>> type(sub).__dict__['x']

Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: 'x'

So the real truth chases down the mro chain before giving up
and falling back to ordinary attribute access, IWT.

Regards,
Bengt Richter

 

[Martin Miller]

Bengt Richter wrote, in part:

On 14 Mar 2005 01:19:23 -0800, "Martin Miller"

wrote, in part:
What still puzzles me, though, is why all the above to make properties
work on instances is necessary in the first place. It's certainly not
clear (to me) from what is said in the How-to at:

http://users.rcn.com/python/download/Descriptor.htm#invoking-descriptors
I suspect that it may be simply a performance issue, in other

words,
it

was considered too slow to check for instance

property/discriptors
--

although *why* is not clear to me.

I suspect the desired semantics re precedence have evolved to make normal
programs easily implementable, and that probably drove the implementation:
"""
For objects, the machinery is in object.__getattribute__ which transforms
b.x into type(b).__dict__['x'].__get__(b, type(b)).
The implementation works through a precedence chain that gives (my added
[1,2,3])

[1] data descriptors priority over instance variables,
[2] instance variables priority over non-data descriptors,
[3] and assigns lowest priority to __getattr__ if provided.

The full C implementation can be found in

PyObject_GenericGetAttr()
in

Objects/object.c.
"""

I haven't examined the C code in Objects/object.c to see *how* the
semantics are implemented because that's not really the point...which
is the descriptions of what's suppose to happen don't seem to match
what actually does. To illustrate, consider:

class Foobar(object):
pass

def myget(self, obj, type=None):
return 42

def myset(self, value):
raise AttributeError("this is a read-only property")

foobar = Foobar()
foobar.x = property(myget, myset)

print "foobar.x:", foobar.x

Which prints:

foobar.x: <property object at 0x00AE5850>

Ignoring "why" issue, my question becomes:

foobar.x is a data descriptor property, however

object.__getattribute__
It is a property, and it has the requisite methods (__get__ and __set__) to be
a data descriptor, but it is not a data descriptor unless it is visible as
an attribute of type(foobar), which foobar.x is not.

does *not* seem to be treating it as such and handling it the way
described either by you or in what is written in the how-to.
Specifically the statements that:

For objects, the machinery is in object.__getattribute__ which transforms
b.x into type(b).__dict__['x'].__get__(b, type(b)).

This doesn't seem to be occuring. Am I missing something?

I think so. Following your example:
... pass
...... return 42
...... raise AttributeError("this is a read-only property")
...

foobar = Foobar()
foobar.x = property(myget, myset)
print "foobar.x:", foobar.x

type(foobar).__dict__['x']

Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: 'x'

meaning
b.x into type(b).__dict__['x'].__get__(b, type(b)).
does not apply, and the attempt to get foobar.x falls back to
ordinary attribute access. I.e., foobar.x will be whatever

BTW, I'm not sure type(b).__dict__['x'].__get__(b, type(b))
is really fully correct, since that would not find foobar.x in a Foobar base class:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: myget() takes at least 2 arguments (1 given)

(At least it was found, even if the signature is bad ;-)

But:

type(sub).__dict__['x']

Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: 'x'

So the real truth chases down the mro chain before giving up
and falling back to ordinary attribute access, IWT.

Regards,
Bengt Richter

Ah, from your comments and explanation I think I finally understand
that the description in the docs *is* in fact accurate -- and
indirectly, the reason for properties on instances not working by
default. Specifically I was not realizing that the "type(b).__dict__"
in the statement:

b.x is tranformed into type(b).__dict__['x'].__get__(b, type(b))

implys that no check for 'x' in made in "b.__dict__".

Now I'm back to wondering "why" because it would be relatively easy to
check for a descriptor in the instance dictionary first -- and would be
more "Pythonic", IMHO, since instances can generally augment (or
override) that which is defined by their class.

Thank you for bearing with me on this somewhat obtuse follow-on
question regarding properties and descriptors (and to the everyone else
for their suggestions for work-arounds).

Best regards,
Martin

P.S. After looking at the implementation of PyObject_GenericGetAttr()
in Objects/object.c, I believe your observation about the
"type(b).__dict__['x'].__get__(b, type(b))" not being fully correct is
true. Instead, there appears to be a search being done through the mro
base classes of type(b). Perhaps that fact could be used to create
"mix-in" style classes with the desired properties...