[Python-Dev] Re: [snake-farm] test test_slice failed -- [9, 7, 5, 3, 1] == [0]

[Guido van Rossum]

> I looked at how hard it would be to support 64 bit sequences.
> 
> If we did this, 64 bit users would be able to use long sequences at
> the expense of backwards compatibility.  Also, we would need something
> like Py_seq_len, use a configure option, and all the ob_size,
> arguments etc. would have to use the new type name.
> 
> I did a grep for int, there were a ton.  But it looks like
> those used for sequence lengths were much fewer.
> 
> I suppose this change could be accomplished in stages.  
> 
>         Step 1, typedef int Py_seq_len; for all platforms.
>         Step 2, start using it for the proper APIs in the header files.
>         Step 3, change the C files.
>         Repeat steps 2 & 3 until done.
> 
> I'm not volunteering, of course. :-) I don't need this and have no
> system to use for testing.  So this is all academic at best.

I have no time to do it either, but I hereby officially pronounce that
I wouldn't mind breaking binary compatibility for this, once, at 2.3
or 2.4.  Maybe someone gets inspired.

The proper type should probably be size_t or perhaps ssize_t, BTW.

Also, Python ints should use an integral type that's at least as wide
as a pointer; at least on Windows64, long is 32 bits but pointers are
64 bits, so long isn't it.  If Python ints could be 64 bits even on 32
bit platforms (if long long is supported) that would be cool to.
It could possibly break more stuff if sys.maxint doesn't fit
in a C long -- but that would already be a problem for Win64.

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