On 9/9/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 9/9/07, Greg Ewing <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
