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

K. Richard Pixley rich at noir.com
Tue Jan 4 18:50:42 CET 2011

On 1/4/11 07:31 , Mike Graham wrote:
> 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.
It's not the restriction that I'm looking for - it's the expressive grace.

These concepts are pretty straightforward given the beginnings of them 
that we have now.  Filling out the matrix is a pretty obvious concept.  
The idea that while the concepts are available to anyone, 
straightforward, and recur, but can only be implemented by someone with 
extremely current and advanced knowledge of the interpreter, resulting 
in code which is less transparent rather than more, is the restrictive idea.


More information about the Python-ideas mailing list