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/040642.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 TODOsGuido van Rossum guido at python.org
Wed Dec 3 09:17:21 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.

Nick Coghlan:
> 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.

I proposed that too, but Andrew Koenig didn't like it.

--Guido van Rossum (home page: http://www.python.org/~guido/)

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