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 mark.dickinson
Recipients gregory.p.smith, lukasz.langa, mark.dickinson, miss-islington, seberg, tim.peters, twouters
Date 2021-08-04.18:53:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1628103218.56.0.295439185563.issue44698@roundup.psfhosted.org>
In-reply-to
Content
Thanks, @seberg. I'll take a look and see if we can restore the old behaviour, at least for Python 3.9 and 3.10. I'm not convinced that the new behaviour is objectively wrong, but I agree that the *change* in behaviour is problematic.

I do find it a little odd that we're special-casing integer exponents for complex numbers when no such special-casing exists for floats. It's not purely for optimization (despite what the code might say). And all the messing around with trying to figure out exactly _which_ doubles can safely be cast to long (which was the original cause of this issue) seems like a symptom of a deeper problem, which is that it doesn't make a whole lot of sense to be distinguishing in the first place. But if we're going to change the behaviour, we should only be doing that in 3.11.

OTOH, there *is* real value in z**2 being fast and accurate; we definitely want to keep that. (Perhaps the math and cmath modules should grow a `square` function.)
History
Date User Action Args
2021-08-04 18:53:38mark.dickinsonsetrecipients: + mark.dickinson, tim.peters, twouters, gregory.p.smith, lukasz.langa, seberg, miss-islington
2021-08-04 18:53:38mark.dickinsonsetmessageid: <1628103218.56.0.295439185563.issue44698@roundup.psfhosted.org>
2021-08-04 18:53:38mark.dickinsonlinkissue44698 messages
2021-08-04 18:53:38mark.dickinsoncreate