Is a "real" C-Python possible?

[Kay Schluehr]

On Dec 12, 9:04 am, George Sakkis <george.sak... at gmail.com> wrote:
> On Dec 12, 2:18 am, Kay Schluehr <kay.schlu... at gmx.net> wrote:
>
> > On Dec 12, 7:34 am, sturlamolden <sturlamol... at yahoo.no> wrote:
> > > I am not sure why a new type annotation syntax was needed Python 3:
>
> > Because people care about a feature when there is @syntax.
>
> Good point; the inverse is not true though: time and time again people
> cared about some syntax for properties without any change so far. The
> result is a handful of different ways to spell out properties; python
> 2.6 will add yet another variation (http://mail.python.org/pipermail/
> python-dev/2007-October/075057.html).
>
> George

Yes, I'm aware. Curiously, whenever property syntax is discussed the
discussion loses track and is dragged away by needless side
discussions. Just look at Stephen Bethards withdrawn PEP 359 [1] in
which he finally muses about replacing the class statement by the make
statement. So the PEP ended in "abstract nonsense" instead of
clarifying the point.

[1] http://www.python.org/dev/peps/pep-0359/

I vaguely remember a discussion a few years ago, where someone made
the quite reasonable suggestion of introducing some kind of
thunk_statement:

class A(object):
    foo = property:
        def fget(self):
            return self._foo
        def fset(self, value):
            self._foo = value

which was translated as follows:

class A(object):
    def thunk():
        def fget(self):
            return self._foo
        def fset(self, value):
            self._foo = value
        return vars()
    foo = propery(**thunk())
    del thunk

Now people started to consider using the compound statement within
expressions as well because the equal sign is used within method
signatures and call syntax. This lead to a general discussion about
the expr/statement distinction in Python, about multiline lambdas and
functional style programming. These association graphs are almost
predictable.