On Dec 13, 2007 12:04 PM, Patrick Mullen <[EMAIL PROTECTED]> wrote: > > > > > Kay Schluehr wrote: > > > > > Python 2.6 and 3.0 have a more Pythonic way for the problem: > > > > > class A(object): > > > > > @property > > > > > def foo(self): > > > > > return self._foo > > > > > @foo.setter > > > > > def foo(self, value) > > > > > self._foo = value > > > > > @foo.deletter > > > > > def foo(self) > > > > > del self._foo > > > > > class B(A): > > > > > # one can even overwrite the getter in a subclass > > > > > @foo.getter > > > > > def foo(self): > > > > > return self._foo * 2 > > > > > Christian > > On Dec 12, 2007 12:57 PM, George Sakkis <[EMAIL PROTECTED]> wrote: > > 1. The property name ('foo') is repeated *5* times for a single class. > > Talk about DRY. > > 2. Total inconsistency: @property for the getter when it is defined > > for the first time, @foo.setter/@foo.deletter for the setter/deletter, > > @foo.getter when the getter is redefined. WTF ?! > > Eww, I agree with George here, with respect to these two points. When > I looked at this my first wtf was the @property and then @foo.getter > business. I really don't mind the current way of doing things: attr = > property(get,set). Other mechanisms can be created with getattr > routines. I don't really like this new syntax at all.
For the record, this is not new syntax. It's implemented this way specifically to avoid the creation of new syntax for properties. >Too many @ > marks, inconsistancies, and too many foos everywhere. Not to mention > how long it reads. For only getters, it's not bad though, and a > little better than property(). > I don't feel that it's especially inconsistent, and I like decorators. Having to write foo everywhere isn't that nice, but it's only mildly worse than C# to me - I find the extra block levels really atrocious. > Decorators really don't feel pythonic to me at all, mostly due to the > @ symbol, but it looks really awful in this instance. > > What about this, somewhat similar but not ugly syntax: > > class A: > foo = property() > def foo.get(): > return self._foo > def foo.delete(): > del self._foo > def foo.set(val): > self._foo = val > > Defining something with a dot is currently a syntax error. Ok, so > it's still too many foos. At least it's consistent. I'm not really > proposing this btw. I'd rather not introduce more specialized syntax. > > How about abusing with: > > class A: > with property("foo"): > def get > def set... > > There's your thunk, and I really like with, but am saddened that it > has such limited use at the moment. Of course this isn't really what > with is for... > > Can anyone tell me what's wrong about the current property() syntax, > besides namespace polution? > Nothing, except that people prefer decorators and they don't like the namespace pollution. foo = property() isn't going away and if you prefer it (I don't) you're free to use it. If you don't like decorators in general it's fairly obvious that you won't be partial to a decorator based feature. It's not that big a deal anyway, of course, the use case for properties in Python has a much smaller scope than in C#, and getter-only properties (which you can create with just @property) are the majority of those. -- http://mail.python.org/mailman/listinfo/python-list