Greg Ewing wrote:
> BTW, if you *really* want to understand continuations, you
> need to carry out the following exercise: Write a Scheme
> interpreter in Scheme, doing it in a continuation-passing
> style. [1]
>
> You'll find that it's possible to do this using a subset
> of Scheme that doesn't
Thanks for the discussions on the hows-and-whys of futures and
asynchronous approaches in Python... they have been enlightening.
[OT stuff below]
Michael Chermside wrote:
> It is a FUNDAMENTAL PRECONDITION of Py3K that it will BE the existing
> CPython codebase, with a few changes and some cruf
Guido van Rossum wrote:
> Let me just add that Andy is wasting his time. Python 3000 won't have
> continuations.
Huh? Futures are very different from continuations. I still have a
hard time understanding continuations (and am no fan of them), but
futures seem to be a rather simple abstraction t
Josiah Carlson wrote:
> Andy Sy <[EMAIL PROTECTED]> wrote:
>> Does this mean that Py3K intends to reuse major portions of
>> Python 2.x's implementation?
>
> Aahz just answered this.
> From the discussion I've been paying attention to over the last f
Greg Ewing wrote:
> There's a lot more to this than syntax. The oddities
> surrounding Python generators are mostly due to their
> "one-level-deep" nature, i.e. they're not full coroutines.
> And there are deep implementation reasons for that.
Does this mean that Py3K intends to reuse major porti
Josiah Carlson wrote:
> Andy Sy <[EMAIL PROTECTED]> wrote:
>> The Io language has what (on paper) seems to be a very
>> neat, Pythonic mechanism for doing asynchronous concurrency.
>>
>>
>> The mechanism is called futures and is described at:
>>
>&
The Io language has what (on paper) seems to be a very
neat, Pythonic mechanism for doing asynchronous concurrency.
The mechanism is called futures and is described at:
http://iolanguage.com/darcs/Io/_docs/guide.html#TOC17133
Perhaps Python 3000 can incorporate some similar ideas
in its syntax
