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/040616.html below:

[Python-Dev] Int FutureWarnings and other 2.4 TODOs

[Python-Dev] Int FutureWarnings and other 2.4 TODOsAndrew Koenig ark-mlist at att.net
Tue Dec 2 16:25:41 EST 2003
> > Aren't integers immutable?  If so, I would think it doesn't make sense
> for them to change representation, as they don't change value.

> I was using shorthand-speak meaning that different instances of the
> same class would use a different representation (which the class can
> somehow recognize by looking at the instance, of course).

Got it.

> > Anyway, if you want to use type to encode representation, I would
> > think that the various integer types should be related by
> > inheritance.  As a long can always substitute for an int, at least
> > in theory, I would think that long should be derived from int.  Then
> > isinstance(42L, int) would yield True.

> Or should int be a subclass of long?  I believe that OO theorists
> consider the base class the set with the largest number of elements
> (since it is the least constrained).  Now, all ints are longs, but all
> longs are not ints, since ints can only represent values in
> [-sys.maxint-1, sys.maxint].  According to this reasoning, long should
> be the base class.

I think that int should be the base class, because I can imagine long
supporting operations that int does not support, but not vice versa.



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