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
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
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
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
> 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
@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
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
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
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
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
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
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
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
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
14 matches
Mail list logo
