[Python-3000] C API for ints and strings
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