int / long统一隐藏了bug [英] int/long unification hides bugs

问题描述

似乎存在一个严重的问题，即允许数字以近乎无限的方式增长，因为int / long统一确实存在：它隐藏了错误。

大多数那时候，我希望我的数字很小。 2 ** 31很好

足以满足大多数变量的用途，当需要更多时，2 ** 63

应该在大部分时间内完成。


被授予，统一允许代码工作的数量大于

预计（如PEP 237所述）但我觉得可能更多

未被发现错误胜过这个好处。


统一的另一个好处 - 可移植性 - 可以通过定义int32&来实现
int64类型（或通过定义所有整数为

32位（或64位））

PEP 237说，它会给新的Python程序员[...]少了一点学习[...]的东西。我觉得这不像程序员学习语言时所写的代码质量那么重要。


-kartik

解决方案

kartik写道：

似乎存在严重的问题，允许数字以几乎无限的方式增长，如int / long unification确实：它隐藏了bug。
[snip] PEP 237说，它将为新的Python程序员提供一个更少的东西来学习[...]。我觉得这不像程序员在学习语言后所写的代码的质量那么重要。

你对质量有足够的认识吗？你的代码要编写

自动化测试吗？或者你只是希望通过这个

语言的功能为你捕获一个小小的

潜在的错误？


我不确定你在问什么，因为即使是你所描述的潜在错误的曝光也只会发生在你b $ b * * *代码。您是否计划让您的用户报告

当程序在代码路径中崩溃时有错误

你没有手动测试？


-Peter

kartik写道：

似乎有一个严重的问题允许数字以几乎无限的方式增长，正如int / long统一所做的那样：它隐藏了错误。


不是没有。


只是因为一个失控的程序因为点击

整数限制而停止了并不意味着这个有这个限制

是一种验证方法。

i觉得这不像程序员编写的代码质量那么重要

一个依赖于整数限制的代码

是高质量的东西。


如果你担心一些数字增长太多，然后

自己检查一下，你会得到更好的结果。


Istvan。

kartik写道：

似乎存在严重的问题，允许数字以几乎无限的方式增长，如int / long统一确实：它隐藏了错误。
大部分时间，我希望我的数字很小。


问题是小有多小？不到2 ** 7？小于2 ** 15？

小于2 ** 31？不到2 ** 63？什么是权力的意义

两个？如果你从32位机器移动到64位

，会发生什么？ （或者一百年后的1024位？）

PEP 237说，它将为新的Python程序员提供一个更少的学习东西[...] ]" ;.我觉得这不像程序员学习语言时编写的代码质量那么重要。

事情是，int / long截止是任意的，通过

实现细节确定。一个更好的想法是明智地使用断言。


断言x< 15000


它不仅可以保护您免受失控数字的影响，而且还会记录预期范围是什么，从而产生更好的代码质量。 ;

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

解决方案

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"

这篇关于int / long统一隐藏了bug的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！