> > So decorators couldn't be used to create read-only properties?
>
> Maybe I'm misunderstanding something. I thought that a property
> contains a get descriptor, which makes it a kind of callable.
That's irrelevant; the property itself isn't callable.
> Also, I thought we had explicitly punted on allowing decorators to
> create properties because the syntax wasn't sufficiently flexible
> without contortions.
It would work just fine for read-only descriptors; in fact I believe
that
def foo [property] (self):
return ...calculated value of foo...
would be all you need (it would be nice if property tried to get the
docstring out of the get function).
In any case, *I* would prefer not to let the semantics require
anything, and to make this just a (preferred) shorthand for applying
arbitrary transformations to something that starts out as a function.
Two additional thoughts:
1) I'm not sure I like using the same syntax for classes; the use
cases are so different that using similar syntax only adds
confusion, and I think the use cases for classes are a lot weaker
than for methods.
2) The syntax should also apply to regular functions.
3) It needs to be crystal clear that the list of transformations is
applied at function/method definition time, not at class definition
time (which is later, after all the methods have been collected in
a namespace).
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4