Jim Jewett wrote:
> Martin v. Löwis replied:
>
>> ... column numbers shouldn't exceed 16-bits, and line #s
>> shouldn't exceed 31 bits.
>
> Why these particular numbers?
>
> As nearly as I can tell, 8 bits is already too many columns for human
> readability.
There isn't a practical 8-bit intege
(Neal Norwitz asked about changing some additional ints and longs to ssize_t)
Martin v. Löwis replied:
> ... column numbers shouldn't exceed 16-bits, and line #s
> shouldn't exceed 31 bits.
Why these particular numbers?
As nearly as I can tell, 8 bits is already too many columns for human
reada
Neal Norwitz wrote:
> Should the following values be ints (limited to 2G)?
>
> * dict counts (ma_fill, ma_used, ma_mask)
I think Tim said he'll look into them.
> * line #s and column #s
I think we should really formalize a limit, and then enforce it
throughout. column numbers shouldn't exceed
Neal Norwitz wrote:
> Should the following values be ints (limited to 2G)?
>
> * line #s and column #s
Anyone with a source file more than 2G lines long
or 2G chars wide deserves whatever they get. :-)
Not-investing-in-a-1.3e10-pixel-wide-screen-any-time-soon-ly,
Greg
_
Here's the int questions. The entire list is too big to post (50k),
so it's here:
http://www.python.org/neal/header-ints
Should the following values be ints (limited to 2G)?
* dict counts (ma_fill, ma_used, ma_mask)
* line #s and column #s
* AST (asdl.h) sequences
* recursion limit
* read/
