Is a "real" C-Python possible?
Chris Mellon
arkanes at gmail.com
Thu Dec 13 13:16:21 EST 2007
On Dec 13, 2007 12:04 PM, Patrick Mullen <saluk64007 at gmail.com> 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 <george.sakkis at gmail.com> 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.
More information about the Python-list
mailing list