467,077 Members | 937 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,077 developers. It's quick & easy.

Why do descriptors (and thus properties) only work on attributes.

Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.

So what are the reasons for limiting this feature in such a way?

--
Antoon Pardon
Jul 18 '05 #1
  • viewed: 1393
Share:
14 Replies
Antoon Pardon <ap*****@forel.vub.ac.be> writes:
Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.


How would that work?
Jul 18 '05 #2
Op 2005-02-28, Paul Rubin schreef <http>:
Antoon Pardon <ap*****@forel.vub.ac.be> writes:
Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.


How would that work?


Well AFAIU a descriptor is an object with at least one method out of
__get__, __set__ or __del__. I don see why implicitly calling one
of these methods would be any more difficult when they are autonomous
objects than when they are attributes.

--
Antoon Pardon
Jul 18 '05 #3
Antoon Pardon wrote:
Op 2005-02-28, Paul Rubin schreef <http>:
Antoon Pardon <ap*****@forel.vub.ac.be> writes:
Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.


How would that work?


Well AFAIU a descriptor is an object with at least one method out of
__get__, __set__ or __del__. I don see why implicitly calling one
of these methods would be any more difficult when they are autonomous
objects than when they are attributes.


I still don't see how that is supposed to work for "a lot of interesting
things". Can you provide examples for one of these interesting things?

--
Regards,

Diez B. Roggisch
Jul 18 '05 #4
Antoon Pardon wrote:
Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.


How would that work?

Well AFAIU a descriptor is an object with at least one method out of
__get__, __set__ or __del__. I don see why implicitly calling one
of these methods would be any more difficult when they are autonomous
objects than when they are attributes.


I guess properties are really a feature of the class, not of the
attribute. Certain operations on objects of the class (getattr, setattr,
delattr) have to be intercepted. If you want to have this for general
variable access, you 'd have to intercept all accesses to local and
module name spaces. This slows things down a lot. And many think that
overloading assignment is a bad idea. You probably find some dicussions
when searching for "overloading assignment" in the newsgroup archive.
to an object or class. I think a lot of interesting things one can


As in the chinese curse "May you live in interisting times"?

Daniel
Jul 18 '05 #5
Op 2005-02-28, Diez B. Roggisch schreef <de*********@web.de>:
Antoon Pardon wrote:
Op 2005-02-28, Paul Rubin schreef <http>:
Antoon Pardon <ap*****@forel.vub.ac.be> writes:
Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.

How would that work?


Well AFAIU a descriptor is an object with at least one method out of
__get__, __set__ or __del__. I don see why implicitly calling one
of these methods would be any more difficult when they are autonomous
objects than when they are attributes.


I still don't see how that is supposed to work for "a lot of interesting
things". Can you provide examples for one of these interesting things?


Lazy evaluation where the value of something is calculated the first
time it is needed but accessed from some storage if it is needed again.

--
Antoon Pardon
Jul 18 '05 #6
Op 2005-02-28, Daniel Dittmar schreef <da************@sap.corp>:
Antoon Pardon wrote:
Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.

How would that work?

Well AFAIU a descriptor is an object with at least one method out of
__get__, __set__ or __del__. I don see why implicitly calling one
of these methods would be any more difficult when they are autonomous
objects than when they are attributes.


I guess properties are really a feature of the class, not of the
attribute. Certain operations on objects of the class (getattr, setattr,
delattr) have to be intercepted. If you want to have this for general
variable access, you 'd have to intercept all accesses to local and
module name spaces. This slows things down a lot.


OK, I can understand this.
And many think that
overloading assignment is a bad idea.
But not bad enough to allow it in some cases?
You probably find some dicussions
when searching for "overloading assignment" in the newsgroup archive.


I'll take a look.
to an object or class. I think a lot of interesting things one can


As in the chinese curse "May you live in interisting times"?


Well I think python partly makes the time interesting. So in that
respect we are all cursed.

--
Antoon Pardon
Jul 18 '05 #7
In article <cv**********@news.sap-ag.de>,
Daniel Dittmar <da************@sap.corp> wrote:

As in the chinese curse "May you live in interisting times"?


Not so Chinese:

http://www.noblenet.org/reference/inter.htm
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR
Jul 18 '05 #8
Aahz:
Not so Chinese: http://www.noblenet.org/reference/inter.htm


That page is incredible!
Me too I have a gut feeling that the citation is from the XX century
and from
some Western country (even if till now I had not questioned its
attribution).
I wish I could say more about its origin ...

Michele Simionato

Jul 18 '05 #9
On 2005-02-28, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2005-02-28, Diez B. Roggisch schreef <de*********@web.de>:
I still don't see how that is supposed to work for "a lot of interesting
things". Can you provide examples for one of these interesting things?


Lazy evaluation where the value of something is calculated the first
time it is needed but accessed from some storage if it is needed again.


I do this all the time. It's not very hard and doesn't require any
extra language support, but I would like for there to be an
authoritative list of type slots (autopromise_ops).

import operator

def promise(thunk):
x = []
def promised():
if not x:
x.append(thunk())
return x[0]
return promised

autopromise_ops = [x for x in dir(operator) if x.startswith('__')]
autopromise_ops += ['__getattribute__', '__call__', '__str__', '__repr__']
autopromise_ops += ['__getattr__', '__setattr__', '__delattr__']

def autopromise(thunk):
p = promise(thunk)
d = {}
for op in autopromise_ops:
def bindhack(op=op):
return lambda self, *a, **kw: getattr(p(), op)(*a, **kw)
d[op] = bindhack()
return type('autopromise', (), d)()

def test():

lis = []

def thunk():
lis.append('ran thunk')
return 'value'

s = autopromise(thunk)
p = s * 30
assert p == 'value' * 30
p = s * 10
assert p == 'value' * 10
assert lis == ['ran thunk'] # Just once

print 'autopromise sanity test passed'

An autopromise object is good almost everywhere the real one would be,
and usually the only way to tell the difference is to call id or type
on it. The main exception is when the thunk returns a builtin type
(like a string or int) and you want to pass it to a builtin function
that expects a particular type (this would also apply to Python
functions that break duck typing on purpose, but those would just be
getting the breakage they deserve).
Jul 18 '05 #10
Antoon Pardon wrote:
Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.


Not sure what "stood on itself" really means, but if you just want to be
able to have module-level properties, you can do something like:

py> class Module(object):
.... oldimporter = __builtins__.__import__
.... def __init__(self, *args):
.... mod = self.oldimporter(*args)
.... self.__dict__ = mod.__dict__
.... p = property(lambda self: 42)
....
py> __builtins__.__import__ = Module
py> import __main__
py> __main__.p
42
py> __main__.p = 3
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
AttributeError: can't set attribute

where you replace module objects with a different object. Note that
this is also nasty since properties reside in the class, so all modules
now share the same properties:

py> import sys
py> sys.p
42
py> sys.p = 13
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
AttributeError: can't set attribute

STeVe
Jul 18 '05 #11
Steven Bethard wrote:
Antoon Pardon wrote:
Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.

Not sure what "stood on itself" really means, but if you just want to be
able to have module-level properties, you can do something like:

Think in non-English (stand outside yourself?) for a second, rememberinf
Antoon is Belgian (if you knew that):

"on" => "by"

"stood on itself" => "stood by itself"
=> "standalone"

regards
Steve
Jul 18 '05 #12
Op 2005-02-28, Dima Dorfman schreef <di**@trit.invalid>:
On 2005-02-28, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2005-02-28, Diez B. Roggisch schreef <de*********@web.de>:
I still don't see how that is supposed to work for "a lot of interesting
things". Can you provide examples for one of these interesting things?


Lazy evaluation where the value of something is calculated the first
time it is needed but accessed from some storage if it is needed again.


I do this all the time. It's not very hard and doesn't require any
extra language support, but I would like for there to be an
authoritative list of type slots (autopromise_ops).

import operator

def promise(thunk):
x = []
def promised():
if not x:
x.append(thunk())
return x[0]
return promised

autopromise_ops = [x for x in dir(operator) if x.startswith('__')]
autopromise_ops += ['__getattribute__', '__call__', '__str__', '__repr__']
autopromise_ops += ['__getattr__', '__setattr__', '__delattr__']

def autopromise(thunk):
p = promise(thunk)
d = {}
for op in autopromise_ops:
def bindhack(op=op):
return lambda self, *a, **kw: getattr(p(), op)(*a, **kw)
d[op] = bindhack()
return type('autopromise', (), d)()

def test():

lis = []

def thunk():
lis.append('ran thunk')
return 'value'

s = autopromise(thunk)
p = s * 30
assert p == 'value' * 30
p = s * 10
assert p == 'value' * 10
assert lis == ['ran thunk'] # Just once

print 'autopromise sanity test passed'

An autopromise object is good almost everywhere the real one would be,
and usually the only way to tell the difference is to call id or type
on it. The main exception is when the thunk returns a builtin type
(like a string or int) and you want to pass it to a builtin function
that expects a particular type (this would also apply to Python
functions that break duck typing on purpose, but those would just be
getting the breakage they deserve).


Hmm, I'll have to take your word for it, because for the moment I
don't see what is going on. I'll have to study this some time.

--
Antoon Pardon
Jul 18 '05 #13
Steve Holden wrote:
Steven Bethard wrote:
Antoon Pardon wrote:
Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.


Not sure what "stood on itself" really means, but if you just want to
be able to have module-level properties, you can do something like:

Think in non-English (stand outside yourself?) for a second, rememberinf
Antoon is Belgian (if you knew that):

"on" => "by"

"stood on itself" => "stood by itself"
=> "standalone"


Sorry, I gathered that this meant "standalone". My problem was that I'm
not sure what "standalone" means in the context of descriptors.
Descriptors are invoked when dotted-attribute access is used. When
exactly is he proposing "standalone" descriptors would be invoked?

STeVe
Jul 18 '05 #14
Steven Bethard wrote:
Steve Holden wrote:
Steven Bethard wrote:
Antoon Pardon wrote:

Can anyone explain why descriptors only work when they are an attribute
to an object or class. I think a lot of interesting things one can
do with descriptors would be just as interesting if the object stood
on itself instead of being an attribute to an other object.
Not sure what "stood on itself" really means, but if you just want to
be able to have module-level properties, you can do something like:

Think in non-English (stand outside yourself?) for a second,
rememberinf Antoon is Belgian (if you knew that):

"on" => "by"

"stood on itself" => "stood by itself"
=> "standalone"


Sorry, I gathered that this meant "standalone". My problem was that I'm
not sure what "standalone" means in the context of descriptors.
Descriptors are invoked when dotted-attribute access is used. When
exactly is he proposing "standalone" descriptors would be invoked?


Well, my *guess* was Antoon was referring to module attributes - names
that can be referenced without qualification using a "." operator.

Which, I suppose, is how you read it too. Sorry.

regards
stEvE
--
Meet the Python developers and your c.l.py favorites March 23-25
Come to PyCon DC 2005 http://www.pycon.org/
Steve Holden http://www.holdenweb.com/
Jul 18 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by David S. | last post: by
3 posts views Thread by redefined.horizons@gmail.com | last post: by
7 posts views Thread by mrkafk@gmail.com | last post: by
1 post views Thread by Chris Leary | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.