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

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

--
Antoon Pardon

[Paul Rubin]

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?

[Antoon Pardon]

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

[Diez B. Roggisch]

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

[Daniel Dittmar]

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

[Antoon Pardon]

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

[Antoon Pardon]

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

[Aahz]

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

[Michele Simionato]

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

[Dima Dorfman]

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

[Steven Bethard]

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

[Steve Holden]

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

[Antoon Pardon]

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

[Steven Bethard]

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

[Steve Holden]

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/