On 2/22/07, Christian Zagrodnick <[EMAIL PROTECTED]> wrote:
the cachedescriptors package is quite aged as it seems. It hasn't been
updated for decorator use.
Actually there are only three descriptors:
CachedProperty – Needs to be updated to be used as decorator. But I
guess we need a deprecation period.
Lazy – Works like charm as property decorator.
readproperty –can go away i think. The property builtin is find. I'd
add a 12 month deprecation warning.
As long as `Lazy` doesn't go away, I don't mind. CachedProperty is a
little overwhelming.. I guess I haven't had a need for it. I use Lazy
a lot in views and other objects that exist only during the
request/response cycle. It's super handy in those situations.
I wouldn't mind seeing `Lazy` renamed or aliased as `lazyproperty` or
I use `readproperty`, but I have my own copy of it. I didn't realize
it was in cachedescriptors. As I understand it, `readproperty` is
different from the built-in basic `property` descriptor: you can write
to a readproperty. You can't write to a basic `property` that is used
only as a decorator around a getter method.
>>> class Foo(object):
... def bar(self):
... return 42
>>> f = Foo()
>>> f.bar = 33
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: can't set attribute
With `readproperty`, you can still have the simple
getter-method-wrapper property, with the ability to replace the value
on instances. So no, the builtin 'property' descriptor is not fine.
`property` came into being when Python got descriptors, but before it
got decorators. By grand design or divine accident, the fact that the
first argument for `property` is the getter function makes it a useful
decorator. But it wasn't written with decorators in mind. It was
written for ``x = property(getX, setX, delX)``, or some combination
Zope3-dev mailing list