On Thursday, December 19, 2013 6:32:06 PM UTC+1, Guido van Rossum wrote:
>
> On Thu, Dec 19, 2013 at 8:17 AM, Marc Schlaich 
> <[email protected]<javascript:>> 
> wrote: 
> > Hey, 
> > 
> > this is nice :-) I have a few questions/proposals: 
> > 
> > - Would you consider moving to GitHub to attract (more) contributors, 
> > including myself? 
>
> Perhaps you could consider learning a different source control system 
> as a learning opportunity? :-) 
>

I know Mercurial pretty well (actually better than git). However, I find it 
really inconvenient for a reviewed pull request process due to the lack of 
rebase -i for published commits. Plus, GitHub adds some nice features like 
Travis. Maybe there could be an automatically synced mirror?

>
> > - concurrent.futures is already backported: 
> > https://pypi.python.org/pypi/futures. You should completely drop this 
> and 
> > make it an (optional?) dependency. 
>
> Hm, but Python 3 Tulip/asyncio doesn't actually use concurrent.futures 
> (except for a few constants and exceptions). I presume the backport 
> shouldn't either. 
>

Ah yes. Just backporting the constants should be the way to go.
 

>
> > - I would directly wrap coroutines in tasks in the decorator, this 
> should 
> > simplify things. 
>
> Beware, the goal here is to easy forward porting the code to Python 3. 
>

Exactly. I think this is the more obvious place to make these changes 
(instead of hide them in the scheduler). 

>
> > - Using yield instead of yield from offers a nice syntax style to wait 
> for 
> > parallel execution of coroutines/tasks: 
> > 
> >     twitter_data, fb_data = yield ( 
> >         async_http_request('http://twitter.com/...'), 
> >         async_http_request('http://facebook.com./...'), 
> >     ) 
> > 
> >   This needs to be enabled in the scheduler. What do you think? 
>
> I would prefer not to do this, because you can't do that with 
> yield-from in Python 3. 
>

Ok.
 

>
> > I'm going to have a look at the code and failing tests later. 
> > 
> > Marc 
> > 
> > On Wednesday, December 4, 2013 11:15:52 PM UTC+1, Victor Stinner wrote: 
> >> 
> >> Hi, 
> >> 
> >> I spend a few hours to try to backport Tulip on Python 2.7. 
> >> 
> >>    https://bitbucket.org/haypo/tulip_py2 
> >> 
> >> I copied ayncio, selectors and concurrent.futures modules from Python 
> 3.4. 
> >> 
> >> First commits are basic Python 3 => Python 2 fixes: 
> >> 
> >> - Remove keyword-only parameter marker ("*") 
> >> - Remove suppression of exception context ("raise ... from None") 
> >> - Adapt metaclass syntax 
> >> - Fix def func(*args, key=default) syntax 
> >> - Fix print() syntax: use from __future__ import print_function 
> >> - Fix imports for Python 2 (queue => Queue) 
> >> - Fix super() syntax 
> >> - Replace list.clear() with "del list[:]" 
> >> 
> >> Now, the interesting changes: 
> >> 
> >> - Replace "yield from ..." with "yield ..." 
> >> - Replace "return value" with "returnValue(value)" (warning: "return 
> >> x, y" must be replaed with returnValue((x, y)) 
> >> - Backport InterruptedError and BlockingIOError exceptions (add them 
> >> directly into builtins, this hack should be fixed later) 
> >> - Wrap socket operations to replace socket.error(EINPROGRESS) with 
> >> BlockingIOError (at runtime) 
> >> - Modify Task._step() to handle generators: wrap generator into a new 
> Task 
> >> 
> >> I copied returnValue() name from Twisted @inlineCallbacks. Antoine 
> >> noted that the name is not PEP 8 compliant and proposed "yield 
> >> Return(...)" :-) 
> >> 
> >> I ran basic examples (hello world, ping client/server), they work on 
> >> my backport with Python 2.7. 
> >> 
> >> They are maybe real blocker issues in this backport with generators / 
> >> coroutines / Taks / ..., but I'm happy to have a working proof of 
> >> concept after a few hours. 
> >> 
> >> Victor 
>
>
>
> -- 
> --Guido van Rossum (python.org/~guido) 
>

Reply via email to