[issue21559] OverflowError should not happen for integer operations

[theme]

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 exactly that (just search this website for OverflowError).
This might cause an expected uncaught exception that the cause cannot be 
deduced after reading the documentation.
There are 2 ways to fix this: either change the documentation, or change 
something in the core of the interpreter.
Note: I don't know what versions of python this affects, but I have tested this 
on python 3.4.0 on windows. (the version that was downloadable from 
www.python.org/downloads/)

--
assignee: docs@python
components: Documentation, Interpreter Core
messages: 218957
nosy: docs@python, theme
priority: normal
severity: normal
status: open
title: OverflowError should not happen for integer operations
type: behavior
versions: Python 3.4

___
Python tracker 
<http://bugs.python.org/issue21559>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21559] OverflowError should not happen for integer operations

[theme]

Changes by theme :


--
components: +Library (Lib)

___
Python tracker 
<http://bugs.python.org/issue21559>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21559] OverflowError should not happen for integer operations

[theme]

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 value is not in range(0, 256)."
- http://bugs.python.org/issue20539 "Patch applied to the default branch (but 
with OverflowError instead of ValueError for large positive inputs)."
- http://bugs.python.org/issue21444 "CPython has historically imposed some 
artificial implementation specific details in order make the implementation 
cleaner and faster internally (i.e. a limit on the number of function 
arguments, sys.maxsize limits, etc.)"
- http://bugs.python.org/issue15988 (No message explicitly telling that 
OverflowError is the right error to raise. However, it is implied that only the 
error message, not the error type, should be changed)

There might be other similar issues out there.
Am I opening a can of worms?

--

___
Python tracker 
<http://bugs.python.org/issue21559>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21559] OverflowError should not happen for integer operations

[theme]

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:

- OverflowError is raised only by "arithmetic operations" on non-integers in 
the strictest sense possible (e.g. +,-,*,/,**) , which does not include library 
functions. This interpretation seems absurd to me.

- OverflowError is raised by arithmetic operations on "non-integers", where 
"integers" refer only to python integers, which never overflow, and excludes C 
integers. This seems pretty awkward, since this implies that the behavior of 
library functions regarding overflows is implementation-defined (aka undefined 
behavior) to some extent, and I don't think this is good.

- OverflowError is raised by arithmetic operations on non-integers, which can 
be initiated by either the user, a user script or a library function. However, 
the issues linked in msg219024 involve library functions that obviously deals 
only with integers. Resolving behaviors to match this interpretation seems 
pretty logical to me, but will most likely cause a lot of implementation issues.

--

___
Python tracker 
<http://bugs.python.org/issue21559>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12946] PyModule_GetDict() claims it can never fail, but it can

[theme]

Changes by theme :


--
versions: +Python 3.4, Python 3.5

___
Python tracker 
<http://bugs.python.org/issue12946>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com