This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author veky
Recipients veky
Date 2016-07-17.07:32:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I already wrote, but can't seem to reopen the issue, so I think the best thing is to report the bug separately.

So, in issue, performance enhancement enabled a shortcut for some operations (__pow__ among them) to avoid reducing the result to lowest terms if it can be concluded it's already reduced.

However, the logic has a corner case that was handled incorrectly. If a negative Fraction is raised to a negative integer, the result is a Fraction with a negative denominator, which is not normalized and in fact breaks many other operations (which rightly assume their operands to be normalized).

>>> import fractions
>>> fractions.Fraction(-1, 2) ** -1
Fraction(2, -1)
>>> _ == -2

Of course, the easy fix would be to change line 52 of to _normalize=True - but that would reintroduce the slowness talked about in Alternative fix is to branch depending on the sign of the base, which might be messy if we intend to be completely general -- for example, in finite quotient rings, fractions don't have well-defined signs.

[BTW I'm not quite sure why the code in is so general, with many weird cases trying to support every imaginable construction - maybe someone really wanted such a level of generality. I don't, so I'd be fine with this working only on ordinary int/int Fractions.]
Date User Action Args
2016-07-17 07:32:11vekysetrecipients: + veky
2016-07-17 07:32:11vekysetmessageid: <>
2016-07-17 07:32:11vekylinkissue27539 messages
2016-07-17 07:32:11vekycreate