On Fri, Apr 21, 2006 at 08:10:07PM +1200, Greg Ewing wrote:
> Aurélien Campéas wrote:
> > On Thu, Apr 20, 2006 at 07:59:43PM +1200, Greg Ewing wrote:
> > > Andy Sy wrote:
> > > > Does this mean that Py3K intends to reuse major portions of
> > > > Python 2.x's implementation?
> > > I expect that alm
Andy Sy wrote:
> > It is a FUNDAMENTAL PRECONDITION of Py3K that it will BE the existing
> > CPython codebase, with a few changes and some cruft removed. We are
> > NOT going to re-write from the ground up. If you don't know why, go
> > read "http://www.joelonsoftware.com/articles/fog69.ht
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
Jim Jewett wrote:
> There, a Future is a proxy object, whose actual characteristics will
> (or may) be filled in later. If you need it, you wait for it, but if
> you don't need it yet, it can be created in the background.
>
> How to make this cleaner than the existing concrete implementations
> (
On 4/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Andy Sy wrote:
> > 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 to comprehend.
> Isn't a future jus
Michael Chermside wrote:
>
> Andy writes:
>
> > I still have a hard time understanding continuations
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 fi
Tim Peters wrote:
> Asynch programming wasn't at all a goal of generators, and Twisted is
> well worth looking into for those who want slicker asynch programming
> tools.
There might possibly be room for an alternative way of
presenting the generator machinery that makes it look
like less of an a
Andy Sy wrote:
> 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 to comprehend.
Isn't a future just a coroutine, or something equivalent?
Sometimes there's a
Aurélien Campéas wrote:
> On Thu, Apr 20, 2006 at 07:59:43PM +1200, Greg Ewing wrote:
> > Andy Sy wrote:
> > > Does this mean that Py3K intends to reuse major portions of
> > > Python 2.x's implementation?
> > I expect that almost all of it will be reused.
>
> Couldn't PyPy be considered an interes
Guido writes
> Let me just add that Andy is wasting his time. Python 3000 won't have
> continuations.
Andy writes:
> 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 abstra
[Guido, to Andy Sy]
> ...
> If you want to contribute a pure Python module that implements some
> useful form of futures, you don't have to wait for Python 3.0. But
> before you contribute this to Python 2.6 (it's too late for 2.5), you
> should probably have released it successfully as a separate
On 4/20/06, Andy Sy <[EMAIL PROTECTED]> wrote:
> 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
Andy Sy writes:
> Does this mean that Py3K intends to reuse major portions of
> Python 2.x's implementation?
Aahz already answered this, but I'd like to restate more forcefully:
It is a FUNDAMENTAL PRECONDITION of Py3K that it will BE the existing
CPython codebase, with a few changes and some cru
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
Let me just add that Andy is wasting his time. Python 3000 won't have
continuations.
On 4/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Andy Sy <[EMAIL PROTECTED]> wrote:
> > Err... thank you once again for being redundant, reiterating what is
> > already pretty much dead clear to everyone
Andy Sy <[EMAIL PROTECTED]> wrote:
> Err... thank you once again for being redundant, reiterating what is
> already pretty much dead clear to everyone and saying nothing new
> in general.
And yet, here I notice that you've still not described a syntax or its
execution semantics. Instead you've c
On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> The difficulty with improving on the current generator
> model is that the only way to do any better is to use
> full coroutines. That means either using threads (which
> you can do now if you want), or turning the whole
> implementation inside-ou
On Thu, Apr 20, 2006 at 07:59:43PM +1200, Greg Ewing wrote:
> Andy Sy wrote:
>
> > Does this mean that Py3K intends to reuse major portions of
> > Python 2.x's implementation?
>
> I expect that almost all of it will be reused.
>
Couldn't PyPy be considered an interesting contender ?
> The diff
Andy Sy wrote:
> Does this mean that Py3K intends to reuse major portions of
> Python 2.x's implementation?
I expect that almost all of it will be reused.
The difficulty with improving on the current generator
model is that the only way to do any better is to use
full coroutines. That means eith
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 few
> years, *some* parts of Py3k will be backwa
Andy Sy <[EMAIL PROTECTED]> wrote:
> 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
On Thu, Apr 20, 2006, Andy Sy wrote:
> 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.
>
> Doe
On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> If syntax is all you're concerned about, you could translate
> that into Python as something like
>f = url(future(fetch))
Are you sure it wouldn't be
f = Future(fetch, url)
a bit like
result = ActiveObject(function, args)
> Now,
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
On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Andy Sy wrote:
>
> > I don't know about you, but with the addition of send() to deal with
> > the problem outlined in PEP 342, generators are starting to look more
> > and more like a Rube Goldberg contraption. Could anything be more
> > Pythonic
Andy Sy wrote:
> I don't know about you, but with the addition of send() to deal with
> the problem outlined in PEP 342, generators are starting to look more
> and more like a Rube Goldberg contraption. Could anything be more
> Pythonic than Io's:
>
> f := url @fetch // f is a future that will
27 matches
Mail list logo
