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

A

Antoon Pardon

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?
 
P

Paul Rubin

Antoon Pardon said:
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?
 
A

Antoon Pardon

Op 2005-02-28 said:
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.
 
D

Diez B. Roggisch

Antoon said:
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?
 
D

Daniel Dittmar

Antoon said:
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.

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

Daniel
 
A

Antoon Pardon

Op 2005-02-28 said:
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.
 
A

Antoon Pardon

Op 2005-02-28 said:
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.
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.
 
D

Dima Dorfman

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).
 
S

Steven Bethard

Antoon said:
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
 
S

Steve Holden

Steven said:
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
 
A

Antoon Pardon

Op 2005-02-28 said:
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.
 
S

Steven Bethard

Steve said:
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
 
S

Steve Holden

Steven said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top