[Python-3000] PyInt_ to PyLong_ rename

[Guido van Rossum]

On Dec 2, 2007 12:56 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > It's only used for sys.maxint. Do we still need sys.maxint and
> > PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are
> > better names.
>
> I think they should go entirely. They don't give any interesting
> information about the Python implementation.

Actually it's still somewhat interesting to be able to tell whether a
particular Python build uses 64-bit pointer or 32-bit pointers. (I
realize sys.maxint doesn't quite tell us this, but on Linux at least
it does.) I also suspecet that sys.maxint is used frequently for "some
large integer" used as an approximation of infinity in some context.

> > The name for PyInt_CheckExact is confusing, too. It's defines as
> > PyInt_CheckExact(op) (PyLong_CheckExact(op) && _PyLong_FitsInLong(op)).
> > PyLong_CheckFitsInLong() or PyLong_CheckNativeLong() (Georg's idea) do
> > explain the meaning better.
>
> No. It's not that the name is confusing - the implementation is.
> PyInt_CheckExact tests whether the object is exactly the builtin
> 'int' type. Now that the original 'int' type is gone, it does not
> make sense anymore to test for it - except that code does test for
> it (which it should stop doing).
>
> In most cases, PyInt_CheckExact was only used to determine whether
> it is safe to invoke PyInt_AsLong; and the new definition of
> PyInt_CheckExact has a good approximation for that case.

IMO we should devise an API specifically for that. Or we should get
rid of it and force everyone to just call PyInt_AsLong and test for an
error return. But I suspect that would cause the code to be slightly
clumsier. (And slower if an error is detected, but that presumably
doesn't matter.)

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