<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, 30 Aug 2018 at 14:06, Nicolas Rolin <<a href="mailto:nicolas.rolin@tiime.fr">nicolas.rolin@tiime.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I think you could take the implementation further and decide that any power of Fraction(1) is Fraction(1) and any positive power of Fraction(0) is Fraction(0).</div><div>I woudn't be shocked that Fraction(1) ** 3.7 == Fraction(1) and Fraction(0) ** 3.7 == 0.</div></div></blockquote><div><br></div><div>You could do lots of things. But are any of them useful enough to warrant changing documented behaviour, breaking backward compatibility, and introducing a much more complex rule on how the arguments to Fraction.__pow__ affect the type of the return value?</div><div><br></div><div>At the moment, there are no known use cases for this change - beyond Neil's statement that he'd "like" the values to be as he quoted (with no justification given).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>However the implementation for Fraction(-1) seems a bit to "ad hoc", and break some expected behavior of the powers.</div><div>For exemple in your code Fraction(-2) ** Fraction(2, 3) != Fraction(-1) ** Fraction(2, 3) * Fraction(2) ** Fraction(2, 3), whereas floats respect this.</div><div>You could change the code so that the property (a *b) ** c == a**c *b**c, but idk how hard it is.</div></div></blockquote><div><br></div><div>This (what behaviour is "expected" and/or natural) is the sort of detail that can't be answered without knowing use cases - both use cases for the proposed behaviour *and* use cases that rely on the existing behaviour.</div><div><br></div><div>Paul<br></div></div></div>