int/long unification hides bugs

[Alex Martelli]

kartik <kartick_vaddadi at yahoo.com> wrote:
   ...
> integers are used in different ways from strings. i may expect file

Integers are used in a huge variety of ways, and so are strings.

> 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.

Try doing some accounting in Turkish liras, one of these days.  Today,
each Euro is 189782957 cents of Turkish liras.  If an Italian firm
selling (say) woodcutting equipment bids on a pretty modest contract in
Turkey, offering machinery worth 2375220 Euros, they need to easily
compute that their bid is 450776275125540 cents of Turkisk Liras.  And
that's a _pretty modest_ contract, again -- if you're doing some
computation about truly substantial sums (e.g. ones connected to
government budgets) the numbers get way larger.

[[and yes, integer numbers of some fraction of a currency, typically
cents, are a good and practical way to do accounting -- nix floating
point, be it binary or decimal]].

Sure, Turkey will rebase its currency in 2005 -- but who can predict
when some other country's currency will similarly debase.  Even just for
accounting, unlimited-size integers are simply much more practical.


> 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.

But the same index, used as a dictionary key, works just fine.  Specious
argument, therefore.


> 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.

This may be peculiar to the kind of code you write -- if you hit more
bugs whose symptom is a large integer than ones whose symptom is a large
string, you're probably generating fewer strings than integers.  But
many other people's code have the opposite character, and it's quite
presumptous of you to suggest changing Python without considering that.


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

I suggest you take your blinkers off, and look at all ways integers are
commonly used in all sorts of computations, rather than imagining your
personal code is the end of the world.  As common and everyday a
computation (in some fields) as the factorial of 1000 (number of
permutations of 1000 objects) is 2**8530 -- and combinatorial arithmetic
is anything but an "ivory tower" pursuit these days, and factorial is
the simplest building block in combinatorial arithmetic.

If you need objects with constraints, build them as custom types.
Subclass int, str, whatever, to accept bounds or other checkers in their
constructors (or as compiletime constants, whatever), convert the result
of each operation to the same type, and raise as soon as an instance is
constructed that's out of bounds.  It's not a difficult exercise, and if
you design and apply your constraints well it may help you catch some
categories of bugs sooner than without such constraints.

Once you have convincing use cases and experience to show that this kind
of thing is more useful than previously noticed, _then_ you may stand a
chance to have some kind of optional limit-checking subtypes rolled into
Python's core/standard library.  So far, you have nothing of the kind.


Alex