On 4 January 2011 15:31, Mike Graham <mikegraham@gmail.com> wrote:

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.
>

I'm not entirely sure what you're referring to here - but if you're referring to the desire to make an attribute read-only then there is a different principle at work. If setting something is a programmer error, then it is better that the error become an exception at the point the error is made rather than become a different exception somewhere else later on.

Michael Foord

> --
> --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

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
http://mail.python.org/mailman/listinfo/python-ideas