On Dec 2, 2007 12:56 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
