Mark Dickinson added the comment: > it looks like a good idea
It's not a good idea, though: you risk breaking existing third-party extension modules in surprising ways, which isn't a friendly thing to do. In any case, if anything the PyLong methods should be moving *away* from use of the nb_int slot. This has been discussed multiple times previously; one reason that we haven't made that change yet is the problem of breaking backwards compatibility. > Should I upload the patch with docs and with the warning fixed? Sure, that would be great if you have the time. Tests would be useful too, but one of us can fill those in (eventually). It all depends how much of a hurry you're in. :-) > Will it be applied in 3.4.1? No: as already explained by others, it's a enhancement, not a bugfix, so it can't be applied until 3.5. > P.S.: is there a very fast way to check if a PyLong fits in unsigned long > long with the limited API? Depends on your definition of 'very fast'. There should be no need to compare with a constant: just try the conversion with PyLong_AsUnsignedLong and see if you get an OverflowError back. My guess is that that's not going to be much slower than a custom PyLong_AsUnsignedLongAndOverflow, but the only way you'll find out is by timing your particular use-case. > P.P.S.: Just a random idea: would it be a to rewrite PyLong to use GMP > instead as a PyVarObject of mp_limb_t's? I'll let Victor answer that one. :-) In the mean time, see issue 1814. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21111> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
