[Python-3000] PyInt_ to PyLong_ rename

[Jim Jewett]

On 12/3/07, Guido van Rossum <guido at python.org> wrote:
> On Dec 3, 2007 12:12 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > >> Sure. However, you could also use
> > >> _testcapi.PY_SSIZE_T_MAX, or
> > >> ctypes.sizeof(ctypes.py_object).

> > > Much less intuitive though.

> > Actually, I find the ctypes version a more direct answer to the
> > question "what is the address space?".

(1)  Is there a valid use case for this that needs to be supported
with the "same code" across distributions before ctypes?

(2)  Is "without ctypes" still a supported build configuration,
because of the crash-risks?  More narrowly, is can we assume that they
don't need the exact size/address unless they're doing extensions that
have at least as much risk as ctypes?

> It's just that I didn't even know about it -- and I suspect most users
> would never think of it. OTOH most users will expect sys.maxint to
> be 2**63-1 on a 64-bit machine (never mind that they are wrong for
> Win64 :-).

I think anyone expecting a particular number would also expect that
integers larger are in some way special.  Whether they need to use
doubles (as in C) or they fail entirely, or they just slow down
(python 2.x) ... they should be special.

Maybe sys.maxint should just be removed entirely.

Reasons to keep it:
   It is useful information, even it isn't quite what the naive expect.
   It serves as a "really big integer".

Reasons to drop it:
   Attractive nuisance that isn't quite correct.

> I would remove the optimizations for now; we should benchmark
> again later in the 3.0 beta release cycle. In general I'm all for
> removing clutter that was once added in the hope of speeding
> things up; for 3.0 my main priority is correctness.

When this happens, what should be left behind?

(a)  Nothing -- just go to subversion
(b)  A comment that this was optimized in the past
(c)  A note in some sort of "optimiation ideas" readme

-jJ