Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > int/long unification hides bugs

Reply
Thread Tools

int/long unification hides bugs

 
 
kartik
Guest
Posts: n/a
 
      10-25-2004
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.
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.

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.

the other benefit of the unification - portability - can be achieved
by defining int32 & int64 types (or by defining all integers to be
32-bit (or 64-bit))

PEP 237 says, "It will give new Python programmers [...] one less
thing to learn [...]". i feel this is not so important as the quality
of code a programmer writes once he does learn the language.

-kartik
 
Reply With Quote
 
 
 
 
Peter Hansen
Guest
Posts: n/a
 
      10-25-2004
kartik 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.

[snip]
> PEP 237 says, "It will give new Python programmers [...] one less
> thing to learn [...]". i feel this is not so important as the quality
> of code a programmer writes once he does learn the language.


Do you feel strongly enough about the quality of your code to write
automated tests for it? Or are you just hoping that one tiny class
of potential bugs will be caught for you by this feature of the
language?

I'm not sure what you're asking, because even the exposure of
latent bugs which you are describing can happen only when you
*run* the code. Are you planning to have your users report
that there are bugs when the program crashes in a code path
which you didn't get around to testing manually?

-Peter
 
Reply With Quote
 
 
 
 
Istvan Albert
Guest
Posts: n/a
 
      10-25-2004
kartik 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.


No it does not.

Just because a runaway program stops sooner by hitting the
integer limit it does not mean that this having this limit
is a validation method.

> i feel this is not so important as the quality
> of code a programmer writes


A code that relies on hitting the integer limit
is anything but high quality.

If you are worried about some numbers growing too much, then
check them yourself, you'll get much better results that way.

Istvan.
 
Reply With Quote
 
Rocco Moretti
Guest
Posts: n/a
 
      10-25-2004
kartik 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.
> most of the time, i expect my numbers to be small.


The question is how small is small? Less than 2**7? Less than 2**15?
Less than 2**31? Less than 2**63? And what's the significance of powers
of two? And what happens if you move from a 32 bit machine to a 64 bit
one? (or a 1024 bit one in a hundred years time?)

> PEP 237 says, "It will give new Python programmers [...] one less
> thing to learn [...]". i feel this is not so important as the quality
> of code a programmer writes once he does learn the language.


The thing is, the int/long cutoff is arbitrary, determined soley by
implemetation detail. A much better idea is the judicious use of assertions.

assert x < 15000

Not only does it protect you from runaway numbers, it also documents
what the expected range is, resulting in a much better "quality of code"
 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      10-25-2004
kartik <(E-Mail Removed)> 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.


Alex
 
Reply With Quote
 
Michael J. Fromberger
Guest
Posts: n/a
 
      10-25-2004
In article <(E-Mail Removed) >,
http://www.velocityreviews.com/forums/(E-Mail Removed) (kartik) 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.


Can you exhibit any non-trivial examples of the types of bugs you are
talking about?

-M

--
Michael J. Fromberger | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/ | Dartmouth College, Hanover, NH, USA
 
Reply With Quote
 
Jeff Epler
Guest
Posts: n/a
 
      10-26-2004
Here's a bug that passes silently because ints are not limited in range
from 1 to 100:
...

OK, just joking. I couldn't think of one.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBfbriJd01MZaTXX0RArSWAJ4oSiMopjUa21IIpBl0ZY itXWj1OQCfedWu
/4aKnk9Lcd5balUhxzJBYDM=
=bDVr
-----END PGP SIGNATURE-----

 
Reply With Quote
 
Cliff Wells
Guest
Posts: n/a
 
      10-26-2004
On Mon, 2004-10-25 at 21:48 -0500, Jeff Epler wrote:
> Here's a bug that passes silently because ints are not limited in range
> from 1 to 100:
> ...
>
> OK, just joking. I couldn't think of one.


Here's one:

# count how many ferrets I have
ferrets = 0
while 1:
try:
ferrets += 1
except:
break
print ferrets

As you can clearly see, the answer should have been 3, but due to Python
silently allowing numbers larger than 3 the program gets stuck in an
apparently interminable loop, requiring me to reboot Microsoft Bob.

--
Cliff Wells <(E-Mail Removed)>

 
Reply With Quote
 
kartik
Guest
Posts: n/a
 
      10-26-2004
Peter Hansen <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...

> Do you feel strongly enough about the quality of your code to write
> automated tests for it? Or are you just hoping that one tiny class
> of potential bugs will be caught for you by this feature of the
> language?


1)catching overflow bugs in the language itself frees u from writing
overflow tests.
2)no test (or test suite) can catch all errors, so language support 4
error detection is welcome.
3)overflow detection helps when u dont have automated tests 4 a
particular part of your program.

> I'm not sure what you're asking, because even the exposure of
> latent bugs which you are describing can happen only when you
> *run* the code.


Agreed. i'm saying that without int/long unification, the bugs will b
found sooner & closer to where they occur, rather than propagating
throughout the program's objects & being found far away from the
source, if at all.

-kartik
 
Reply With Quote
 
kartik
Guest
Posts: n/a
 
      10-26-2004
Istvan Albert <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> kartik 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.

>
> No it does not.
>
> Just because a runaway program stops sooner by hitting the
> integer limit it does not mean that this having this limit
> is a validation method.


i didn't say it is. all i say is that it catches bugs - & that's
valuable.


> > i feel this is not so important as the quality
> > of code a programmer writes

>
> A code that relies on hitting the integer limit
> is anything but high quality.


once again, i'm not relying on the integer limit to catch bugs, but
i'd much rather have bugs exposed by an overflow exception than by end
users complaining about wrong data values.


> If you are worried about some numbers growing too much, then
> check them yourself, you'll get much better results that way.


maybe, why not use an automated test built-in 2 the language? i get it
4 free.

-kartik
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Bugs and Bugs...get rid of them Jason Computer Security 1 01-31-2006 10:47 PM
Still use 'ruby-bugs' for Ruby bugs? Josef 'Jupp' Schugt Ruby 2 11-04-2004 10:10 PM
Re: int/long unification hides bugs Josiah Carlson Python 3 10-28-2004 08:44 AM
Re: int/long unification hides bugs kartik vaddadi Python 7 10-28-2004 08:41 AM
Re: int/long unification hides bugs kartik vaddadi Python 2 10-27-2004 01:06 PM



Advertisments