int/long unification hides bugs
kartick_vaddadi at yahoo.com
Tue Oct 26 06:25:07 CEST 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**
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.
More information about the Python-list