At 10:16 AM 9/28/2005 -0400, Jim Fulton wrote: >I do this often enough that I think it would be useful to include it >in python, either as a builtin (like property) or in the library. (Or >possibly by adding an option to property to generate a read >descriptor.) I'd be happy to add this for 2.5. > >Thoughts?
You mean something like defaultproperty(func), where func(ob) is called at most once when there is no dictionary entry for the attribute? I started using such properties with PEAK a few years ago, and found some corner cases that made me decide to stick with ones that have both __get__ and __set__. Mostly those cases have to do with creating class-level properties, which can end up being inherited by subclasses if you don't include __set__. Also of course you can't hook the setting of attributes without a __set__. Of course, most people aren't likely to be creating metaclass properties, so it's probably not a big issue for the stdlib. But I thought *you* might want to know about it, in case you hadn't already encountered the issue. :) The other issue I found with such properties is that I really wanted to be able to use functions that didn't rebind the attribute value directly, i.e., I wanted to be able to use lambdas for short computed property descriptions. However, to make this work you have to know what attribute name(s) the property is stored under in the class, which then leads to other interesting complications. So now I use a custom C type that knows its name and takes two functions (a filter for values set, and a function to compute the default). Unfortunately, finding out a descriptor's name is non-trivial; it'd be nice if there were a descriptor hook __bind__(cls,name) that was called by classes during cls.__new__ or assignment to a class attribute, and which you could define to return a replacement descriptor. It seems like one of the first metaclasses I end up writing in any new project is something to do this, and I believe Ian Bicking has encountered the same thing in e.g. SQLObject. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
