[Tim Peters]
>> ... there's no promise anywhere, e.g., that Python will return an int
>> whenever it's physically possible to do so.
[Bengt Richter]
> Ok, I understand the expediency of that policy, but what is now the meaning
> of int, in that case? Is it now just a vestigial artifact on the way to
> transparent unification of int and long to a single integer type?
I don't really know what you mean by "int". Python isn't C, and the
distinction between Python's historical short integers and unbounded
integers is indeed going away. "int" is the name of a specific Python
type, and the constructor for that type (which old-timers will think
of as the builtin function named "int()") is happy to return unbounded
integers in modern Pythons too. Python-level distinctions here have
become increasingly meaningless over time; I expect that "int" and
"long" will eventually become synonyms for the same type at the Python
level.
The distinction remains very visible at the Python C API level, for
obvious reasons, but even C code has to be prepared to deal with that
a PyIntObject or a PyLongObject may be given in contexts where "an
integer" is required.
> Promises or not, ISTM that if int->float succeeds in preserving all
> significant bits,
> then then a following float->int should also succeed without converting to
> long.
Yes, that was obvious <wink>. But you haven't explained why you
*care*, or, more importantly, why someone else should care. It just
as obviously doesn't bother me, and I'm bold enough to claim that it
"shouldn't" bother anyone. This seems as peripheral to me as arguing
that "there's something wrong" about returning "a long" in either of
these cases:
>>> import os
>>> os.path.getsize("a.py")
165L
>>> f = open("a.py")
>>> f.tell()
0L
The implementations of getsize() and .tell() certainly could have
endured complications to ensure that "an int", and not "a long", was
returned whenever physically possible to do so -- but why bother?
...
> The 2.3.2 source snippet in floatobject.c :
> --------------
> static PyObject *
> float_int(PyObject *v)
> {
...
> But this is apparently accessed through a table of pointers, so would you
> oppose
> an auto-configuration that one time tested whether
> int(float(sys.maxint))==sys.maxint and
> int(float(-sys.maxint-1))==-sys.maxint-1
> (assuming that's sufficient, of which I'm not 100% sure ;-) and if so switched
> the pointer to a version that tested if(LONG_MIN <= wholepart &&
>> wholepart<=LONG_MAX)
> instead of the safe-for-some-obscure-system version?
In the absence of identifying an actual problem this would solve, I
would oppose adding *gratuitous* complication. Abusing your sense of
aesthetics isn't "an actual problem" in this sense to me, although it
may be to you. Of course you're welcome to make any code changes you
like in your own copy of Python <wnk>.
> Of course, if int isn't all that meaningful any more, I guess the problem can
> be
> moved to the ctypes module, if that gets included amongst the batteries ;-)
What problem? If there's an actual bug here, please open a bug report.
--
http://mail.python.org/mailman/listinfo/python-list
