Nicodemus <nicodemus at esss.com.br>:
> Actually, this would introduce a nice feature: allow to easily subclass
> the functions that are part of the property, without the need to
> re-create the property in the subclass.
>
> class C(object):
>
> def get_foo(self):
> return 'C.foo'
>
> c = property('get_foo')
Now *that* would be useful (it's slightly different from the
original proposal, as I understood it).
I wrote a function recently to create properties that work
like that, and I'm finding it very useful. It would be
great to have it as a standard feature, either as a part
of the existing 'property' object, or an alternative one.
> But I don't agree with Edward that property should accept strings. I
> think they should just accept functions as of now, but don't store the
> actual function object, just it's name, and delay the name lookup until
> it is actually needed.
No! If all that's being used is the name, then just pass
the name. Anything else would be pointless and confusing.
Plus it would allow the new behaviour to coexist with the
current one: if it's a function, call it, and if it's a
string, use it as a method name to look up.
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
greg at cosc.canterbury.ac.nz +--------------------------------------+
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