On Tue, 7 Dec 2004 16:44:56 -0500, Tim Peters <[EMAIL PROTECTED]> wrote:
>[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
Me neither, now that I'd been nudged into thinking about it -- that's why I was
*asking* ;-)
>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.
I guess the above is a long spelling of "yes" as an answer to my question ;-)
I assumed that python int was not indifferent to the underlying platform's
native C integer representations, and that its presence was a compromise
(now being deprecated) to permit armslength internal representation control,
for whatever reason (most likely to ease interfacing with something using a
fixed
representation deriving from a C library).
>
>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
IME a corner-case discrepancy in a 1:1 correspondence is a bug waiting to appear
and bite. I admit to an aesthetic component to my unease with it though ;-)
>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?
>
Those calls have obvious reasons for handling large-file sizes, but
they don't explicitly call for an int representation (whatever it means).
"""
Help on class int in module __builtin__:
class int(object)
| int(x[, base]) -> integer
|
| Convert a string or number to an integer, if possible. A floating point
| argument will be truncated towards zero (this does not include a string
| representation of a floating point number!) When converting a string, use
| the optional base. It is an error to supply a base when converting a
| non-string. If the argument is outside the integer range a long object
| will be returned instead.
"""
Maybe the above should be amended to say that the "integer range"
is [-sys.maxint, sys.maxint-1] when the argument is a float ;-)
Or explain what "an integer" means ;-)
>...
>> 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.
I guess there won't be a bug until it bites, so we have to imagine an app
where it would matter not to be able to get sys.maxint from a float
(except via int(int(floatarg)) ;-)
However unlikely, that seemed to me most likely to happen if there was
interfacing to some external function requiring a C-derived integer
representation, which is why I thought ctypes might be where a corner case
long that should have been an int might be detected, and the "problem"
might be solved there with a corner-case test and conversion, so as not
to fail on a legitimate value whose specific representation is something
the Python language per se is disassociating itself from ;-)
Not saying it's a bug wrt Python's unified integer future, just noting
the slow death of legacy expectations, and I guess tending to view it
as a bug so long as int implies anything at all about representation,
and sys.maxint purports to mean something specific about that ;-)
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
