Re: [Python-Dev] PEP 479 and asyncio

2014-11-28 Thread Greg Ewing
Guido van Rossum wrote: The issue here is that asyncio only interprets StopIteration as returning from the generator (with a possible value), while a Trollius coroutine must use "raise Return()" to specify a return value; this works as long as Return is a subclass of StopIteration, but PEP 479

Re: [Python-Dev] PEP 479 and asyncio

2014-11-28 Thread Victor Stinner
2014-11-28 10:12 GMT+01:00 Greg Ewing : > I don't understand. If I'm interpreting PEP 479 correctly, in > 'x = yield from foo', a StopIteration raised by foo.__next__() > doesn't get turned into a RuntimeError The Trollius coroutine uses "raise Return(value)" which is basically a "raise StopIterat

Re: [Python-Dev] PEP 479 and asyncio

2014-11-28 Thread Chris Angelico
On Fri, Nov 28, 2014 at 8:18 PM, Victor Stinner wrote: > 2014-11-28 10:12 GMT+01:00 Greg Ewing : >> I don't understand. If I'm interpreting PEP 479 correctly, in >> 'x = yield from foo', a StopIteration raised by foo.__next__() >> doesn't get turned into a RuntimeError > > The Trollius coroutine u

Re: [Python-Dev] PEP 479 and asyncio

2014-11-28 Thread Victor Stinner
2014-11-28 3:49 GMT+01:00 Nick Coghlan : > I think between contextlib and Trollius, the case is starting to be > made for raising an UnhandledStopIteration subclass of RuntimeError, > rather than a generic RuntimeError. I modified Trollius to test such idea: * Return inherits from Exception (not

Re: [Python-Dev] PEP 479 and asyncio

2014-11-28 Thread Olemis Lang
off-topic , not about asyncio but related to the PEP and other things been discussed in this thread On 11/28/14, Victor Stinner wrote: > 2014-11-28 3:49 GMT+01:00 Nick Coghlan : > [...] > > So yes, it may help to have a new specialized exception, even if "it > works" with RuntimeError. > This is

Re: [Python-Dev] PEP 479 and asyncio

2014-11-28 Thread Olemis Lang
correction ... On 11/28/14, Olemis Lang wrote: > > try: >... > except RuntimeError: >return > ... should be {{{#!py # inside generator function body try: ... except StopIteration: return }}} [...] -- Regards, Olemis - @olemislc Apache(tm) Bloodhound contributor http://issue

[Python-Dev] Summary of Python tracker Issues

2014-11-28 Thread Python tracker
ACTIVITY SUMMARY (2014-11-21 - 2014-11-28) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4668 (+10) closed 30056 (+42) total 34724 (+52) Open issues wit

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

2014-11-28 Thread Demian Brecht
On Tue, Nov 25, 2014 at 6:52 AM, Brett Cannon wrote: > > I suspect if we make sure we add Bitbucket and GitHub login support to the > issue tracker then that would help go a fair distance to helping with the > GitHub pull of reach (and if we make it so people can simply paste in their > fork's

Re: [Python-Dev] PEP 479 and asyncio

2014-11-28 Thread Guido van Rossum
@Victor: I'm glad you found a work-around. Maybe you can let your users control it with a flag? It is often true that straddling code pays a performance cost. Hopefully the slight performance dip might be an incentive for people to start thinking about porting to asyncio. @Olemis: You never showed

Re: [Python-Dev] Please reconsider PEP 479.

2014-11-28 Thread Raymond Hettinger
> On Nov 27, 2014, at 8:52 AM, Guido van Rossum wrote: > > I understand that @allow_import_stop represents a compromise, an attempt at > calming the waves that PEP 479 has caused. But I still want to push back > pretty hard on this idea. > > - It means we're forever stuck with two possible se

Re: [Python-Dev] Please reconsider PEP 479.

2014-11-28 Thread Guido van Rossum
Thanks for being a good sport, Raymond! I've probably spent too much time fretting about this, so thanks for the reminder. I want to get back to other things too, in particular the type hinting PEP: there's a draft, but there are many things we --the co-authors-- want to change before we bother the

[Python-Dev] advice needed: best approach to enabling "metamodules"?

2014-11-28 Thread Nathaniel Smith
Hi all, There was some discussion on python-ideas last month about how to make it easier/more reliable for a module to override attribute access. This is useful for things like autoloading submodules (accessing 'foo.bar' triggers the import of 'bar'), or for deprecating module attributes that aren

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

2014-11-28 Thread Chris Angelico
On Sat, Nov 29, 2014 at 12:59 PM, Nathaniel Smith wrote: > Option 4: Add a new function sys.swap_module_internals, which takes > two module objects and swaps their __dict__ and other attributes. By > making the operation a swap instead of an assignment, we avoid the > lifecycle pitfalls from Optio

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

2014-11-28 Thread Guido van Rossum
Are these really all our options? All of them sound like hacks, none of them sound like anything the language (or even the CPython implementation) should sanction. Have I missed the discussion where the use cases and constraints were analyzed and all other approaches were rejected? (I might have so