[Python-Dev] PEP 479 and asyncio

Olemis Lang olemis at gmail.com
Fri Nov 28 16:15:16 CET 2014


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.stinner at gmail.com> wrote:
> 2014-11-28 3:49 GMT+01:00 Nick Coghlan <ncoghlan at 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:


More information about the Python-Dev mailing list