Does Python need a '>>>' operator?

Ken Peek Ken.Peek at SpiritSongDesigns.comNOSPAM
Mon Apr 15 02:55:32 EDT 2002


"Martin v. Loewis" <martin at v.loewis.de> wrote in message
news:m3lmbpmqij.fsf at mira.informatik.hu-berlin.de...

| So why should hexadecimal be different? It is just the
| base-16 representation of the number, nothing more.

1) Actually, if the long an int types are properly unified,
the long will be converted to an int as soon as it can
be properly represented by an int.

2) Secondly, when we are printing integers in the hex format,
we are not interested in the sign-- we are looking at the
bit pattern.

3) With unification, the long and the int types should not
print differently when calling the 'hex()' method.  (The
'int' version of this method NEVER has, and shouldn't
print a minus sign, and _I_ don't think the long version
of 'hex()' should either.  This _is_ what needs to happen
to have proper unification.

4) We are not using 1.5.2 anymore.  We are on 2.2.x now.
You need to imprint on your brain that there now should be
_NO_ visible difference (to the programmer) between the long
and the int type.  In fact, the int and long representations
are now just an implementation detail, and should be hidden,
and transparent to the programmer.

5) These two types (int and long) _CAN_ be unified for
_ALL_ operators and methods-- I know they can, because the
language known as "Ruby" does a very good job of it.  In
Ruby, there is simply no difference (at least visibly) to
the programmer _at_all_.  The 2 types are automatically
converted back and forth without the knowledge or consent
of the programmer.  If Ruby does it, so can Python.


Martin, why do you resist the unification of these two
types for _ALL_ operations and methods?  Don't you think
Python would be better if there simply was no visible,
operational or programmatical difference between an int
and a long?






More information about the Python-list mailing list