On Fri, Sep 9, 2016 at 2:39 AM, Random832 <random...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
