Roundup Robot added the comment:
New changeset 9ba324a20bad by Terry Jan Reedy in branch '3.4':
Issue #21559: Add alternative (historical) reason for OverflowError.
http://hg.python.org/cpython/rev/9ba324a20bad
--
nosy: +python-dev
___
Python tracker
Changes by Terry J. Reedy tjre...@udel.edu:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21559
___
___
Python-bugs-list
Changes by Terry J. Reedy tjre...@udel.edu:
--
resolution: - fixed
stage: - resolved
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21559
___
___
Josh Rosenberg added the comment:
It usually doesn't just mean outside a required range, it means outside the
range of values representable due to implementation specific limitations (e.g.
the function is converting to a C type). You don't raise OverflowError because
your function only allows
R. David Murray added the comment:
Your second bullet item would seem to me to be the obvious interpretation of
the docs. This is, after all, Python, so 'integer' would refer to Python
integers and their operations. So I agree with Stefan that the docs are
correct as they stand. As he also
Terry J. Reedy added the comment:
I was tempted to close this, but I think there is an issue that 'theme' has
implied but not stated clearly enough. The OverflowError entry might be
re-written as Raised when the result of an arithmetic operation involving at
least one non-int is too large to
R. David Murray added the comment:
Integers are outside a required range makes me wonder why it isn't a
ValueError. An OverflowError should be the result of a *computation*, IMO, not
a bounds check.
So, maybe add your sentence with the additional phrase for historical
reasons? :)
Stefan Krah added the comment:
OverflowError vs. ValueError is a debatable issue (msg215873). In my
view ValueError should be raised in most of the cases.
I do not see anything wrong with the docs though, since the link
you posted talks about arithmetic operations.
--
nosy: +skrah
theme added the comment:
skrah: I am not sure what link are you referring to.
However, no matter which link you are talking about, the documentation still
doesn't match the behavior no matter how you interpret it.
Some possible interpretations of the documentation on OverflowError:
-
New submission from theme:
From the documentation at
https://docs.python.org/3.4/library/exceptions.html#OverflowError all integer
operations should not throw OverflowError no matter what. However, there are
so many issues here that describe library functions and built-in functions
doing
Changes by theme theemat...@gmail.com:
--
components: +Library (Lib)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21559
___
___
Python-bugs-list
Terry J. Reedy added the comment:
In 2.7, it was only *long integers* that could not overflow. In both python 2
and 3, the comment only applys to operations on integers and not to integers
converted to floats. Perhaps that could be clarified. If have any example from
running Python where
theme added the comment:
This is a (non-comprehensive) list of issues that describe or imply that
OverflowError on integers is normal.
- http://bugs.python.org/issue7267 Attached patch works around the inital
issue (u'{0:c}'.format(256)) by raising OverflowError on int.__format__('c') if
the
13 matches
Mail list logo
