int/long unification hides bugs

[Cliff Wells]

On Tue, 2004-10-26 at 09:17 +0200, Alex Martelli wrote:
> 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:
> 

<snip speculative examples>

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

Not at all.  I do quite a bit of database programming and use
constraints (foreign keys, unique indices, etc) extensively.  The
concept is also in widespread use in GUI programming libraries for
controls that deal with user input (e.g. masked input controls).  In
fact, most controls present in a GUI implicitly constrain user input
(menus, buttons, etc).

Of course what you describe above can be done now using functions and
derived classes, but it would certainly be interesting to have a general
(and concise) way of describing constraints within the language itself.


Regards,
Cliff

-- 
Cliff Wells <clifford.wells at comcast.net>