some useful descriptors + a classtools module (was: Properties for classes possible?)

On Sat, Aug 29, 2015 at 3:21 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
[Just to be clear, I don't have much time to pursue this so it's more food-for-though than anything. Feel free to pick up the baton. <wink>] While we're on the topic, there are other generic descriptors that are worth considering for inclusion in the stdlib. I've written more than my fair share of descriptors in the past, many to meet real needs. [1] Along with "classresolved", here are some non-data descriptors that might be worth adding: * lazy - late bound attr that replaces itself on the class (or instance) * Attr - marks an attr as defined on instances of the class, e.g. to satisfy an ABC or as programmatic "documentation"; like binding a place-holder class attr but supports doc strings * rawattr - basically a synonym for staticmethod * classattr - equivalent to simply binding the wrapped object directly on the class, except that wrapped descriptors always resolve as though called on the class * classonly - like classattr, but lookup for instances results in AttributeError; this is like adding a method to a metaclass without using a metaclass * nondata - turns data descriptors into non-data descriptors * classunresolved - causes descriptors to resolve only against instances; like the inverse of a classonly/classattr combo [note that I already proposed "classonly" to this list a couple years ago [2]] While the implementation of many of these is relatively trivial, understanding of the descriptor protocol (and the attribute lookup machinery) is just outside the understanding of your average Python user. I'm all for changing that but in the meantime I think it's justifiable to provide useful (even if relatively trivial) descriptors in the stdlib. Keep in mind that the implementation of property, classmethod, and staticmethod have about the same level of complexity as the descriptors I've described above. Also, if it makes sense to add any of these (or other) useful descriptors then it might also make sense for them to live in a stdlib module rather than as builtins (as property/classmethod/staticmethod do). There really isn't a good fit for them currently. Consequently, I would advocate for adding a new "classtools" module, inspired by the existing functools and itertools modules. The new module would also be an appropriate place for more than descriptors, as there are likely other things that would fit well there. In fact there are a few things we've stuck in the stdlib (e.g. in inspect and types) that would have gone into a classtools module if it had existed. -eric [1] https://bitbucket.org/ericsnowcurrently/presentations/src/default/utpy-may20... [2] https://mail.python.org/pipermail/python-ideas/2013-March/019848.html
participants (1)
-
Eric Snow