[Python-3000] PyInt_ to PyLong_ rename

[Guido van Rossum]

On Dec 4, 2007 7:55 AM, Jim Jewett <jimjjewett at gmail.com> wrote:
> 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
>

definitely (a)

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