Deprecate multicall #58

goodboy · 2017-07-10T05:27:06Z

This starts the deprecation of __multicall__ by following the suggestions from @RonnyPfannschmidt and @hpk42 in #23:

if __multicall__ is detected in a hookimpl fall back to the legacy version, otherwise use the new faster implementation.

The benchmark tests show that the new _MultiCall implementation (without the recursion previously required for wrappers) outperforms the _LegacyMultiCall after more then one hook is registered (likely the short circuting of the while loop condition is faster then the multiple try/for loop fallthroughs in the new version).

For greater numbers of wrappers the new version significanly outperforms; it is also consistently faster with equivalent numbers of hook impls.

Watch the CI run for the comparisons.
Let me know what you guys think!

Add a new `pluggy.callers._MultiCall` implementation which removes support the implicit `__multicall__` special argument and drops the recursion required to handle hook wrappers. Rename the original implementation `_LegacyMultiCall` and load it only when the `__multicall__` argument is detected in a hookimpl function signature. Add a deprecation warning whenever the legacy fallback occurs. Resolves pytest-dev#23

goodboy · 2017-07-11T01:44:43Z

@RonnyPfannschmidt @hpk42 I'd appreciate a look-over from you two as well :)

RonnyPfannschmidt · 2017-07-11T05:07:08Z

pluggy/callers.py

+    """ Hook was called wrongly. """
+
+
+class Result(object):


this is a duplication of outcome just to remove the bad ctor
lets just move the exception handling behaviour to a alternate ctor,

so we can have _Result(result=...) or _Result.from_call(func)

Yeah I really didn't like the duplication.
@RonnyPfannschmidt are you ok with keeping _Result and being rid of _CallOutcome?

both are internal classes and the exposed api is the same, so go ahead :)

@RonnyPfannschmidt good enough?

goodboy · 2017-07-11T17:56:05Z

@RonnyPfannschmidt alright changed as suggested.

Let me know if there's anything else!

`_CallOutcome` limits usage due the constructor calling a function input. Instead add a `classmethod` constructor `_Result.from_call()` which can be used to get the same behaviour and avoids duplicate types.

goodboy · 2017-07-13T16:27:56Z

@RonnyPfannschmidt @hpk42 any reason I can't merge this?
I was hoping to move this forward, maybe get out another minor release, and then move towards actual removal of __multicall__ for 1.0

Let me know what you guys are thinking :)

nicoddemus · 2017-07-13T16:32:18Z

I was hoping to move this forward, maybe get out another minor release, and then move towards actual removal of multicall for 1.0

Hmm how would release 1.0 affect pytest users I wonder? 🤔

goodboy · 2017-07-13T16:34:14Z

@nicoddemus yeah no rush on that ;)

We can also fully remove it in a minor release?

nicoddemus · 2017-07-13T16:38:24Z

yeah no rush on that ;)

Yeah, it is clear that we won't be releasing 1.0 right away, just wondering what will happen when we actually do; plugins which have been working for a long time but using __multicall__ would break.

I guess we should also start issuing DeprecationWarnings when __multicall__ is used to at least make it official.

We can also fully remove it in a minor release?

Given that this is 0.x technically we could... but this will probably force pytest to keep its vendored version pinned for a long time so we don't break things in the wild.

goodboy · 2017-07-13T16:49:16Z

I guess we should also start issuing DeprecationWarnings when multicall is used to at least make it official.

That's already in this PR so maybe it's worth getting in the wild sooner then later?
There's no reason to rush the removal since the legacy support is of course still there.

this will probably force pytest to keep its vendored version pinned for a long time

Sure but I think getting the deprecation warning live sooner then later is probably best.
I also wonder if it's that big of a deal. __multicall__ was supposedly never officially supported and it's not like some old plugins breaking is that critical.

Maybe we could also scour github to check how many projects are still using it?

nicoddemus · 2017-07-13T17:12:34Z

That's already in this PR so maybe it's worth getting in the wild sooner then later?

Oops my bad! I took a little quick look at master and thought we were not doing that yet.

Sure but I think getting the deprecation warning live sooner then later is probably best.

Definitely.

I also wonder if it's that big of a deal. multicall was supposedly never officially supported and it's not like some old plugins breaking is that critical.

I agree, it probably isn't that big a deal. I was just wondering aloud what would happen in 1.0 because I was under the impression you wanted that out "soonish", but I understand now that's not really the case.

In summary: definitely agree with merging this and making a new release. We should then vendor it into pytest for 3.2. 👍

RonnyPfannschmidt · 2017-07-13T19:16:25Z

We should enable pytest to generate warnings about multicall, and drop it on 4.x as well

nicoddemus · 2017-07-13T19:47:52Z

We should enable pytest to generate warnings about multicall, and drop it on 4.x as well

I agree with the idea, but unless I'm mistaken we don't have to actually do anything in pytest other than vendor the pluggy version which emits the warning, correct?

RonnyPfannschmidt · 2017-07-13T19:58:03Z

@nicoddemus we need a pytest specific warning that plugin autors can rely on (and we should make plugin authors trigger the pytest ones for their own sake)

RonnyPfannschmidt · 2017-07-13T19:58:38Z

as in the warnings in pytest need to be able to derive from PyTestWarning

nicoddemus · 2017-07-13T20:00:43Z

Do you think that's necessary? Can't we rely on the standard deprecation warning raised by pluggy?

RonnyPfannschmidt · 2017-07-13T20:02:38Z

if a plugin author enables pytest warnings and not pluggy warnings, he wont even see it coming and be very unhappy on 4.x

goodboy · 2017-07-14T00:29:13Z

@RonnyPfannschmidt fwiw I used a warnings.DeprecationWarning. Are you saying some users disable this by default?

Also @RonnyPfannschmidt are you giving this a stamp of approval or no?
Again if there's anything outstanding I'm happy to make adjustments.

RonnyPfannschmidt · 2017-07-14T05:00:59Z

@tgoodlet what i mean to say is we should enable pytest to use a subclass of PytestWarning, so pytest plugin authors can be more easily be made aware of it (its common to disable warnings you cant affect in testing so you can work on those you can affect)

goodboy · 2017-07-14T16:16:33Z

@RonnyPfannschmidt Yeah sounds reasonable.
Is it maybe worth creating a subclass, PluggyWarning to accomplish the same?

Also not to bug but if you're happy with this PR do you mind approving?

RonnyPfannschmidt

im ok with the state, i hope someone finds the time to follow up with the warnings

goodboy · 2017-07-16T15:14:17Z

@RonnyPfannschmidt just as an FYI there already is a warning in pytest.

Not sure if that's what you're looking for or if a futher warning needs to be added?

RonnyPfannschmidt · 2017-07-17T08:01:02Z

@tgoodlet thanks for bringing that up to my attention, my concerns are to be considered resolved

Tyler Goodlet added 4 commits July 7, 2017 19:26

Convert pluggy.py into a package module

fb00c4e

Adjust tests to use legacy multicall when necessary

09d7589

Parametrize over legacy versus new multicall types

21fd6c4

goodboy added the enhancement label Jul 10, 2017

goodboy requested review from hpk42, RonnyPfannschmidt and nicoddemus July 10, 2017 05:27

goodboy mentioned this pull request Jul 10, 2017

Document the pluggy._Result API #49

Closed

nicoddemus approved these changes Jul 10, 2017

View reviewed changes

RonnyPfannschmidt reviewed Jul 11, 2017

View reviewed changes

goodboy force-pushed the deprecate__multicall__ branch from 07715f5 to 54a1ec6 Compare July 11, 2017 18:15

Remove _CallOutcome; embrace _Result

88f1b73

`_CallOutcome` limits usage due the constructor calling a function input. Instead add a `classmethod` constructor `_Result.from_call()` which can be used to get the same behaviour and avoids duplicate types.

goodboy force-pushed the deprecate__multicall__ branch from 54a1ec6 to 88f1b73 Compare July 11, 2017 18:48

RonnyPfannschmidt approved these changes Jul 16, 2017

View reviewed changes

goodboy merged commit 6689c91 into pytest-dev:master Jul 16, 2017

goodboy mentioned this pull request Jul 16, 2017

Remove __multicall__ support #59

Closed

pyup-bot mentioned this pull request Sep 18, 2017

Scheduled weekly dependency update for week 38 qutebrowser/qutebrowser#2985

Closed

pyup-bot mentioned this pull request Sep 25, 2017

Scheduled weekly dependency update for week 39 qutebrowser/qutebrowser#3031

Merged

pyup-bot mentioned this pull request Oct 5, 2017

Initial Update aio-libs/async-lru#11

Closed

pyup-bot mentioned this pull request Oct 29, 2017

Update pluggy to 0.5.2 uppsaladatavetare/foobar-api#56

Closed

This was referenced Nov 24, 2017

Update pluggy to 0.6.0 amureki/whoisp#76

Closed

Update pluggy to 0.6.0 DavidHickman/calendary#181

Open

Update pluggy to 0.6.0 StuartJSquires/markov_slackbot#147

Closed

pyup-bot mentioned this pull request Jan 19, 2018

Update pluggy to 0.6.0 Poorvak/http_pipeline#8

Merged

pyup-bot mentioned this pull request Feb 8, 2018

Initial Update aio-libs/aiocassandra#9

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Deprecate multicall #58

Deprecate multicall #58

goodboy commented Jul 10, 2017

goodboy commented Jul 11, 2017

RonnyPfannschmidt Jul 11, 2017

goodboy Jul 11, 2017

RonnyPfannschmidt Jul 11, 2017

goodboy Jul 12, 2017

goodboy commented Jul 11, 2017

goodboy commented Jul 13, 2017

nicoddemus commented Jul 13, 2017 •

edited

Loading

goodboy commented Jul 13, 2017 •

edited

Loading

nicoddemus commented Jul 13, 2017

goodboy commented Jul 13, 2017

nicoddemus commented Jul 13, 2017

RonnyPfannschmidt commented Jul 13, 2017

nicoddemus commented Jul 13, 2017

RonnyPfannschmidt commented Jul 13, 2017

RonnyPfannschmidt commented Jul 13, 2017

nicoddemus commented Jul 13, 2017

RonnyPfannschmidt commented Jul 13, 2017

goodboy commented Jul 14, 2017 •

edited

Loading

RonnyPfannschmidt commented Jul 14, 2017

goodboy commented Jul 14, 2017

RonnyPfannschmidt left a comment

goodboy commented Jul 16, 2017

RonnyPfannschmidt commented Jul 17, 2017

Deprecate __multicall__ #58

Deprecate __multicall__ #58

Conversation

goodboy commented Jul 10, 2017

goodboy commented Jul 11, 2017

RonnyPfannschmidt Jul 11, 2017

Choose a reason for hiding this comment

goodboy Jul 11, 2017

Choose a reason for hiding this comment

RonnyPfannschmidt Jul 11, 2017

Choose a reason for hiding this comment

goodboy Jul 12, 2017

Choose a reason for hiding this comment

goodboy commented Jul 11, 2017

goodboy commented Jul 13, 2017

nicoddemus commented Jul 13, 2017 • edited Loading

goodboy commented Jul 13, 2017 • edited Loading

nicoddemus commented Jul 13, 2017

goodboy commented Jul 13, 2017

nicoddemus commented Jul 13, 2017

RonnyPfannschmidt commented Jul 13, 2017

nicoddemus commented Jul 13, 2017

RonnyPfannschmidt commented Jul 13, 2017

RonnyPfannschmidt commented Jul 13, 2017

nicoddemus commented Jul 13, 2017

RonnyPfannschmidt commented Jul 13, 2017

goodboy commented Jul 14, 2017 • edited Loading

RonnyPfannschmidt commented Jul 14, 2017

goodboy commented Jul 14, 2017

RonnyPfannschmidt left a comment

Choose a reason for hiding this comment

goodboy commented Jul 16, 2017

RonnyPfannschmidt commented Jul 17, 2017

Deprecate multicall #58

Deprecate multicall #58

nicoddemus commented Jul 13, 2017 •

edited

Loading

goodboy commented Jul 13, 2017 •

edited

Loading

goodboy commented Jul 14, 2017 •

edited

Loading