Author mark.dickinson
Recipients jneb, mark.dickinson, serhiy.storchaka, tim.peters
Date 2021-01-15.17:25:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1610731538.55.0.439962724025.issue42911@roundup.psfhosted.org>
In-reply-to
Content
Thank you for the proposal and PR!

There are some tradeoffs to be considered here, between simplicity and performance; it's not always trivial to find the sweet spot.  Python's int implementation mostly favours the simplicity end of the spectrum. It's also focused on the sort of integer sizes that turn up in everyday problems, rather than crypto-sized (or worse, number-theoretic-sized) integers - those are more the province of libraries like cryptlib and GMP. That's why Python still has quadratic-time division and base-conversion algorithms.

For this particular case, my feeling is that the added complexity (~300 lines of C code) isn't worth the payoff.

That said, the existing integer powering implementation, like much else in longobject.c, goes back to Tim Peters. If Tim wants to champion this change and push it forward, I'm certainly not going to oppose that.
History
Date User Action Args
2021-01-15 17:25:38mark.dickinsonsetrecipients: + mark.dickinson, tim.peters, jneb, serhiy.storchaka
2021-01-15 17:25:38mark.dickinsonsetmessageid: <1610731538.55.0.439962724025.issue42911@roundup.psfhosted.org>
2021-01-15 17:25:38mark.dickinsonlinkissue42911 messages
2021-01-15 17:25:38mark.dickinsoncreate