[Python-ideas] @classproperty, @abc.abstractclasspropery, etc.

Mike Graham mikegraham at gmail.com
Tue Jan 4 16:31:21 CET 2011

On Mon, Jan 3, 2011 at 7:56 PM, Guido van Rossum <guido at 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.


More information about the Python-ideas mailing list