On 1/4/11 07:31 , Mike Graham 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
On Mon, Jan 3, 2011 at 7:56 PM, Guido van Rossum<guido@python.org> wrote: 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. --rich