Python 1.6 The balanced language

[Alex Martelli]

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:pPJxiEA$bMt5EwRH at jessikat.demon.co.uk...
> In article <8p0gda$d7l$1 at panix3.panix.com>, Aahz Maruch <aahz at panix.com>
> writes
> ...
> >Note that Tim said nothing about coroutines or threads above.  We were
> >talking strictly about generators, which are pretty easy to do -- we
> >just need to agree on an implementation and interface for integrating
> >them into the langauge.
> I would still be interested in seeing how one goes from an enumerative
> routine to a generator in current python. I 'claim' that this is easy
> with 'suspend', but don't grok Structure and Interpretation of Computer
> Programs by Abelson and Sussman too well so I find the other approaches
> quite hard. Perhaps programming all those matrix algorithms in Fortran
> has left me brain damaged.

I'm not sure a generator can be made in Python by just 'wrapping' an
"enumerative routine" -- you'd need to rework the latter to add
explicit state/resumption, I think.  But it seems to me that Aahz
was not talking of Python, the language, as it stands today -- he
is, after all, taking of 'agreeing on implementation and interface'
to have this _addition_ to the language.  E.g., a new hypothetical
Python might have a new keyword, similar to return, that returns
a pair -- the result being returned, and an 'internal state' needed
for resumption at the Python instruction just after the newreturn;
the latter could be a callable-object (to be called without args).

That might let generators be implemented without, however, allowing
the full generality of coroutines.  I dunno, I have not looked at
the current Python sources, but I imagine this is the sort of thing
they may be mooting...?


Alex