off-topic , not about asyncio but related to the PEP and other things been discussed in this thread
On 11/28/14, Victor Stinner <victor.stin...@gmail.com> wrote: > 2014-11-28 3:49 GMT+01:00 Nick Coghlan <ncogh...@gmail.com>: > [...] > > So yes, it may help to have a new specialized exception, even if "it > works" with RuntimeError. > This is somehow the situation I tried to explain in another thread about PEP 479 (though I did not use the right words) and will be a very common situation in practice . > The drawback is that a new layer would make trollius even slower. > e.g. in a (private) library I wrote for a company that's basically about composition of generators there is a situation similar to what Victor explained in this thread . I mostly would have to end-up doing one of a couple of things try: ... except RuntimeError: return which over-complicates function definition and introduces a long chain of (redundant) exception handling code just to end up raising StopIteration once again (i.e. poor performance) or ... # decorate functions in the public API # ... may be improved but you get the idea def myown_stopiter(f) def wrapper(*args, **kwargs): ... try: ... except RuntimeError as exc: if isinstance(exc.args[0], StopIteration): raise StopIteration # exc.args[0] ? else: raise ... return wrapper which is actually a re-implementation of exception matching itself Otherwise ... {{{#!py # in generator definition # rather than natural syntax for defining sequence logic raise MyOwnException(...) # decorate functions in the public API # ... may be improved but you get the idea def myown_stopiter(f) def wrapper(*args, **kwargs): ... try: ... except MyOwnException: raise StopIteration ... return wrapper }}} In the two las cases the library ends up having two functions , the one that allows (MyOwnException | RuntimeError) to bubble up (only used for defining compositions) , and the one that translates the exception (which *should* not be used for compositions, even if it will work, because of performance penalties) ... thus leading to further complications at API level ... Built-in behavior consisting in raising a subclass of RuntimeError is a much better approach similar to the second case mentioned above . This might definitely help to make less painful the process of rewriting things all over to cope with incompatibilities caused by PEP 479 , but afaict performance issues will be there for a while . -- Regards, Olemis - @olemislc Apache(tm) Bloodhound contributor http://issues.apache.org/bloodhound http://blood-hound.net Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com