[Python-Dev] (some) C99 added to PEP 7

[Chris Angelico]

On Fri, Sep 9, 2016 at 2:39 AM, Random832 <random832 at fastmail.com> wrote:
> On Thu, Sep 8, 2016, at 12:30, Chris Barker wrote:
>> That's why I said "based on" -- under the hood, a C type is used, and
>> IIUC, that type has been "long" for ages. And a long on Windows 64
>> (with the MS compiler anyway) is 32 bit, and a long on *nix (with the
>> gnu compilers, at least) is 64 bits.
>>
>> This doesn't expose itself to pure python (and sys.maxint is now gone)
>> but it does get exposed in the C API, and in particular, when passing
>> data back and forth between numpy and pure python (numpy doesn't
>> support an unlimited integer like python), or working with buffers or
>> bytearrays, or whatever in Cython.
>
> I'm not sure "the builtin integer type" was the right term for what
> you're referring to.
>
> You're talking about changing Py_ssize_t, right?

There are a few places where the size of ssize_t becomes visible to a
Python script.

Python 3.6.0a4+ (default:4b64a049f451+, Aug 19 2016, 23:41:43)
[GCC 6.1.1 20160802] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x=1<<(1<<30)
>>> x=1<<(1<<34)
>>> x=1<<(1<<62)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> x=1<<(1<<66)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C ssize_t

But I got the same result on 3.5.2 on Win 7 64-bit, so I'm not seeing
a difference here - it seems that PyLong_AsSsize_t has the same limits
on both platforms.

ChrisA