On Mon, Jan 3, 2011 at 7:56 PM, Guido van Rossum <guido@python.org> wrote:
That said, I am sure there are use cases for static property and class property -- I've run into them myself.
An example use case for class property: in App Engine, we have a Model class (it's similar to Django's Model class). A model has a "kind" which is a string (it's the equivalent of an SQL table name). The kind is usually the class name but sometimes there's a need to override it. However once the class is defined it should be considered read-only. Currently our choices are to make this an instance property (but there are some situations where we don't have an instance, e.g. when creating a new instance using a class method); or to make it a class attribute (but this isn't read-only); or to make it a class method (which requires the user to write M.kind() instead of M.kind). If I had class properties I'd use one here.
-- --Guido van Rossum (python.org/~guido)
This attitude seems to go against the we're-all-adults-here attitude that Python, for better or worse, really wants us to take. If we want to turn "there's no good reason to do X; it's pointless and you'd have to be insane to try, and I even documented that you can't do it" into "it's programmability enforced that you can't do X", it seems like we should be migrating to a language that enforces this with nicer syntax, more fidelity, and less overhead. Mike