Home Original page

int/long unification hides bugs

Alex Martelli aleaxit at yahoo.com
Tue Oct 26 03:17:08 EDT 2004 
Cliff Wells <clifford.wells at comcast.net> wrote:
   ...
> The pivotal word here is "you".  The data *you* want to store.  One more
> time YOU.  I'm not correcting your mangling of English at this point,
> rather I'm pointing out that it's *you*, not Python, that knows what
> sort of data *you* want to store.  If *you* want to limit your integers
> to some arbitrary amount then *you* are going to have to write code to
> do that.  What *you* need for *your* application isn't necessarily what
> anyone else needs for theirs.

This is correct, but optional constraint checking (on all kinds of data
types) can be a handy feature for many kinds of applications.  It might
be handy to have a 'type decorator' for that, one which would wrap all
operations returning a result (and all mutations, for mutables) into
suitable checks.  If I have a list that's supposed to always be between
5 and 8 items, it might be handy to write:

x = constrain(list, LenConstraint(5, 9))([0]*7)

and if I have an integer number that's supposed to always be (and return
when operated upon other such ints) nonnegative and less than 500,

y = constrain(int, SizeConstraint(0, 500))()

Now, y-1 would raise a ConstraintViolation, as would, say,
x.extend('hello').  Sure, nothing momentous, but this would catch some
typos (where I meant y+1) or thinkos (where I meant x.append('hello'))
faster than the unittests would.

There is some previous art for that, of course.  For integers only,
Pascal let you declare a range of admissible values; in debug mode only,
many compilers would helpfully catch range-mistakes, much like (say) in
Python, debug or not, list indexing catches out-of-bounds errors.  In
SQL (and other data modeling situations), it's normal and helpful to
express optional constraints on the range of allowed values.

Of course, this has nothing to do with silly and arbitrary bounds such
as 2**31-1.  But constraint checking should not necessarily be ruled out
as a generally helpful technique.

Maybe it's better to attach constraints to attributes rather than to
types -- use c.y rather than bare y, so that assignments to c.y that do
not meet the constraints will raise ConstraintViolation, say.  That
would surely be easier to program, and speedier, for non-mutables.

Exploring these design-space variations and gathering real-world use
cases is best done by designing and implementing a Python extension for
the purpose, of course.  Rolling some such functionality into the Python
core / standard library would be silly without such specific previous
experience.


Alex
More information about the Python-list mailing list