[Python-Dev] Please reconsider PEP 479. (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Nov 27 12:04:39 CET 2014

On 27 November 2014 at 11:15, Guido van Rossum <guido at python.org> wrote:

On Wed, Nov 26, 2014 at 2:53 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 27 Nov 2014 06:35, "Guido van Rossum" <guido at python.org> wrote: [...] > I think we can put a number to "much faster" now -- 150 nsec per > try/except. > > I have serious misgivings about that decorator though -- I'm not sure > how viable it is to pass a flag from the function object to the execution > (which takes the code object, which is immutable) and how other Python > implementations would do that. But I'm sure it can be done through sheer > willpower. I'd call it the @hettinger decorator in honor of the PEP's most > eloquent detractor. :-) I agree with everything you wrote in your reply, so I'll just elaborate a bit on my proposed implementation for the decorator idea. This remark is ambiguous -- how strongly do you feel that this decorator should be provided? (If so, it should be in the PEP.)

I think it makes sense to standardise it, but something like "itertools.allow_implicit_stop" would probably be better than having it as a builtin. (The only reason I suggested a builtin initially is because putting it in itertools didn't occur to me until later)

Including the decorator provides a straightforward way to immediately start writing forward compatible code that's explicit about the fact it relies on the current StopIteration handling, without being excessively noisy relative to the status quo:

# In a module with a generator that relies on the current behaviour
from itertools import allow_implicit_stop

@allow_implicit_stop
def my_generator():
    ...
    yield next(itr)
    ...

In terms of code diffs to ensure forward compatibility, it's 1 import statement per affected module, and 1 decorator line per affected generator, rather than at least 3 lines (for try/except/return) plus indentation changes for each affected generator. That's a useful benefit when it comes to minimising the impact on version control code annotation, etc.

If compatibility with older Python versions is needed, then you could put something like the following in a compatibility module:

try:
    from itertools import allow_implicit_stop
except ImportError:
    # Allowing implicit stops is the default in older versions
    def allow_implicit_stop(g):
        return g

Regards, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list