Hi everyone. My first post to the list, even thought I have been reading it for a long time now. 8) Edward Loper wrote: > Guido van Rossum wrote: > > I'm curious about the use case that makes you feel the need for speed. > > I would expect most properties not to simply redirect to another > > attribute, but to add at least *some* checking or other calculation. > > The primary motivation was actually to make the code "easier to read"; > the speed boost was an added bonus. (Though not a trivial one -- I do > have a good number of fairly tight loops that access properties.) The > use case that inspired the idea is defining read-only properties for > immutable objects. But I guess I would be better off going with > wrapper functions that create the read-only properties for me (like > <http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/157768>). 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') class D(object): def get_foo(self): return 'D.foo' In the current behaviour, D would have to recreate the property, which can be cumbersome if you're only interested in overwriting one of the property's methods (which is the common case in my experience). 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. What you guys think? Regards, Nicodemus.
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