A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be poked with soft cushions!

Slight modification to Terry's suggestion: I think we can do:

ifmodisnotNone:returnNotImplemented

and then the general machinery should construct a reasonable error message for us. And intheory this gives other classes a chance to participate whereFraction declined to do so, but I'm not sure the delegation rules for ternary operations are particularly well-defined.

I have made the requested changes; please review again.

Should__rpow__ also get the same treatment? Interestingly,pow(1, Fraction(1), 1) already gives the right error message but it looks as thoughFraction.__rpow__ does not get invoked at all in that case.I don't quite understand why.

edit: Found a sort-of answer in thedocs, where it says

Note that ternarypow() will not try calling__rpow__() (the coercion rules would become too complicated).

The ternary coercion rules inPEP 208 do seem complicated. So according to the status quo, seems a third argument for__rpow__ would be pointless (itwon't be used without changes in the C code).

Thanks for making the requested changes!

@terryjreedy: please review the changes made to this pull request.

The ternary coercion rules inPEP 208 do seem complicated. So according to the status quo, seems a third argument for__rpow__ would be pointless (itwon't be used without changes in the C code).

Agreed, I think. I don't think it would be activelywrong to add the check to__rpow__, but it does look as though it wouldn't achieve anything (and so the status quo wins). Thanks for tracking down the relevant source - that was on my list of things to do.

Should not__rpow__ be modified too?

The conclusion that@wimglenn came to in the comments above (and that I think I agree with) is that__rpow__ is never called for a ternarypow() call, so modifying__rpow__ would be pointless. I've just been staring at the relevant source code, and it's tangled enough that I can't tell forsure whether that's true or not.

Ah, sorry, I did not read the discussion before looking at the code in this PR. I experimented and was not able to trigger calling__rpow__. It seems that it is only called inslot_nb_power_binary, which is only used when the third argument is None.

I experimented and was not able to trigger calling__rpow__.

Yep, same here.

I am changing title and blurb to reflect user visible effect of change. Will then merge.