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