[Python-3000] C API for ints and strings (original) (raw)

Nicholas Bastin nick.bastin at gmail.com
Mon Sep 10 04:41:07 CEST 2007

On 9/9/07, Jim Jewett <jimjjewett at gmail.com> wrote:

On 9/9/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> I think it's just trying to say dynamic rather than static ... > library can be updated just by replacing a file, ... > So Windows DLLs qualify, as far as I can see. How many external library calls would need to be resolved at runtime for the following code? for x in range(N): x = 0 while x < N: # Would this comparison be external? x +=1 # And this incf? If python handled small ints itself, and only farmed out the "large" ones, I think the situation would be worse than today, as extensions would still need to support two forms of integer, but they wouldn't even know which was going to be used for a given numeric value.

For the current implementation in 3.0, for C API extension writers, this is practically already the case. The same type is used everywhere, but you have to test if it is out of range for C types, and then extract it as a string to put in some other long integer type, or work with it using the Python C API exclusively.

I'm not suggesting that Python handle small ints itself and then farm out large integer computations, I'm suggesting that since we've already coalesced small ints into 'large' ones, we might want to review the performance implications of that decision, and possibly consider that other people have already solved this problem. Clearly GMP appears to fail on a technical level, but there might be other options worth investigating.

-- Nick

More information about the Python-3000 mailing list