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
83  3435 
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
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.
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"
kartik <ka************ *@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.
Alex
In article <94************ **************@ posting.google. com>, ka************* @yahoo.com (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
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)
iD8DBQFBfbriJd0 1MZaTXX0RArSWAJ 4oSiMopjUa21IIp Bl0ZYitXWj1OQCf edWu
/4aKnk9Lcd5balUh xzJBYDM=
=bDVr
-----END PGP SIGNATURE-----
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 <cl************ @comcast.net>
Peter Hansen <pe***@engcorp. com> wrote in message news:<_a******* *************@p owergate.ca>... 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
Istvan Albert <ia*****@mailbl ocks.com> wrote in message news:<Ho******* *************@g iganews.com>... 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 This thread has been closed and replies have been disabled. Please start a new discussion. |
