In #260, @maxnikulin argued against using a "plain" generator function for this, preferring a new @hookimpl(wrapper=True) instead, to make it explicit.

My opinion is that implicit is fine, because that's how python functions themselves work, and how e.g. pytest.fixture works, and I think they're mostly fine. But I'm willing to be outvoted on this.

It Will make async a little Harder, but reasonably so

Seems like async generators have the necessary asend/athrow, the only thing they're missing is return support. I wonder why they don't support that.

Thanks for the reviews @RonnyPfannschmidt.

I plan to:

• Extract the force_exception change to its own PR with own changelog.
• Try to port pytest to detect any issues and measure performance in a realistic setting.
• Wait a week or two to allow for discussion.

Here's a branch converting all of pytest to new-style wrappers: https://github.com/bluetech/pytest/commits/new-style-wrappers

All of the tests pass, you can use it to get an impression of usage. I haven't compared performance yet.

I've made the following performance measurements:

1. Pluggy benchmark - old pluggy/new pluggy - neutral
2. Pytest benchmarks - old pytetst+old pluggy/new pytest+new pluggy - neutral
3. Pytest benchmarks - old pytetst+old pluggy/old pytest+new pluggy - neutral

I also made an experiment where I removed hookwrapper=True support entirely from _multicall (removing _Result etc.) and this gets a ~15% improvement in pluggy benchmark. But we don't have to drop old-style wrappers to get this improvement; it is easy to add a fast path which specializes for only new-style case - see here (better to view ignoring whitespace). Will maybe submit this as a separate PR if this one gets merged.

How expensive would it be to have legacy hook wrappers be implemented in terms off The new wrappers thus making them slower but allowing the new wrappers also Bugfix the exception escape

I'm not sure, but I generally think it'd be better to keep the existing hookwrapper=True semantics as-is, to avoid breaking things (https://xkcd.com/1172/ situation). Switching to the new style would also be opting in to the new semantics.

Great work @bluetech!

The idea seems great, I will take a look at the code in the next few days! 👍

Thanks for the reviews!

After taking another look at #257, I've made a few changes:

• Added the teardown.close() bit -- it's good to have. Added it only for the new style so as not to touch old style.
• Ported the tests from there.
• Added @maxnikulin as co-author