int/long unification hides bugs

kartik kartick_vaddadi at yahoo.com
Tue Oct 26 00:25:07 EDT 2004


aleaxit at yahoo.com (Alex Martelli) wrote in message news:<1gm8jkc.7gtvc31avo0xhN%aleaxit at yahoo.com>...
> kartik <kartick_vaddadi at yahoo.com> wrote:
> 
> > there seems to be a serious problem with allowing numbers to grow in a
> > nearly unbounded manner, as int/long unification does: it hides bugs.
> 
> So does allowing strings to be any length.
> 
> > most of the time, i expect my numbers to be small. 2**31 is good
> > enough for most uses of variables, and when more is needed, 2**63
> > should do most of the time.
> 
> Most of the time, I expect my strings to be short.  1000 characters is
> good enough for most uses of strings, and when more is needed, a million
> should do most of the time.
> 
> > granted, unification allows code to work for larger numbers than
> > foreseen (as PEP 237 states) but i feel the potential for more
> > undetected bugs outweighs this benefit.
> 
> Granted, unlimited string length allows code to work for longer strings
> than foreseen (as common sense states) but (if you're consistent) you
> feel the potential for more undetected bugs outweighs this benefit.
> 
> 
> By this parallel, I intend to communicate that (and part of why) I
> consider your observations to be totally without merit.

integers are used in different ways from strings. i may expect file
paths to be around 100 characters, and if i get a 500-character path,
i have no problem just because of the length. but if a person's age is
500 where i expect it to be less than 100, then **definitely**
something's wrong.

as another example, using too long a string as an index into a
dictionary is not a problem (true, the dictionary may not have a
mapping, but i have the same issue with a short string). but too long
an index into a list rewards me with an exception.

as i look at my code, i rarely have an issue with string sizes, but if
an integer variable gets very large (say > 2**31 or 2**63), it
generally reflects a bug in my code.

i suggest u base your comments on real code, rather than reasoning in
an abstract manner from your ivory tower.

-kartik



More information about the Python-list mailing list