A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-December/040634.html below:

[Python-Dev] Int FutureWarnings and other 2.4 TODOs

[Python-Dev] Int FutureWarnings and other 2.4 TODOs [Python-Dev] Int FutureWarnings and other 2.4 TODOsNick Coghlan ncoghlan at iinet.net.au
Wed Dec 3 06:18:32 EST 2003
Guido van Rossum wrote:
> I don't particularly like either approach, because the 'long' type is
> an implementation detail over which the user has no control (this is a
> change of heart since Python's original design!).  I guess that means
> I have to work harder and make the single int type support both
> representations.  I'm sure it can be done.

Isn't the 'long' format the more general representation, with the 'int' 
format then being a performance hack to take advantage of the speed of C 
integer arithmetic?

I'm just wondering if a different way of thinking about it might help 
with figuring out how to handle a combined implementation.

Cheers,
Nick.



More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4