Title: Make int(float('inf')) raise ValueError rather than OverflowError.
Type: enhancement Stage:
Components: Versions: Python 3.4
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: Ramchandra Apte, asvetlov, casevh, jcea, kachayev, mark.dickinson, serhiy.storchaka, skrah
Priority: normal Keywords: patch

Created on 2012-11-15 21:17 by mark.dickinson, last changed 2012-12-15 02:57 by jcea. This issue is now closed.

File name Uploaded Description Edit
issue16483.diff kachayev, 2012-11-15 22:19 review
Messages (8)
msg175642 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2012-11-15 21:17
[Broken out of the issue 16469 discussion about infinity -> Fraction and nan -> Fraction conversions.]

Conversions from float('inf') or Decimal('inf') to int (or Fraction) currently generate an OverflowError, while conversions from nan give a ValueError.  I'm of the opinion that it would make more sense for both conversions to generate ValueError, and I'm opening this issue to track discussion for that.  There's also a reasonable case that the behaviour is fine as it is, and there's little to be gained by changing it.
msg175654 - (view) Author: Alexey Kachayev (kachayev) * Date: 2012-11-15 22:19
Patch is attached (ported from full issue patch for issue 16469).
msg175668 - (view) Author: Case Van Horsen (casevh) Date: 2012-11-16 05:16
I agree that ValueError is a more "correct" exception but I also don't think OverflowError is all that wrong. I don't think the change is worth the risk of breaking existing code.

I'd be fine with either option.
msg175671 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2012-11-16 09:05
I guess the feeling of wrongness for me mostly comes from the floating-point world, where the IEEE 754 'overflow' floating-point exception is only appropriate for cases where the result is *finite* but so large that it falls outside the representable range for a float.  Regarding conversions from floating-point formats to integer formats, IEEE 754 says: "When a NaN or infinite operand cannot be represented in the destination format and this cannot otherwise be indicated, the invalid operation exception shall be signaled." To the extent that there's a convention at all, we typically map 'invalid operation exceptions' to ValueError.  (See the comments at the top of Modules/mathmodule.c.)

There's also the minor practical inconvenience of having to remember to catch OverflowError *and* ValueError in try: .. except: constructs.

On the other side, there's a very real possibility of breaking code with this change.

I'll leave this open for a week or so, but unless there's a strong consensus that this should be changed, I propose to close as "won't fix".
msg175673 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-11-16 09:53
> There's also the minor practical inconvenience of having to remember to catch OverflowError *and* ValueError in try: .. except: constructs.

And MemoryError (for big decimals).

Might be the best solution would be raising an exception which subclasses both ValueError and OverflowError. Or make OverflowError to be subclass of ValueError.
msg175738 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2012-11-17 13:47
+1 on OverflowError being a subclass of ValueError
msg175739 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2012-11-17 13:56
I don't particularly like OverflowError in any situation where the
potential overflow is detected *before* it actually happens. This is
another example:

 >>> x = [1]*99999999999999999999
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: cannot fit 'int' into an index-sized integer

So I agree that ValueError is more appropriate, but it may not be worth
fixing it. Closing as "won't fix" sounds fine to me.

A general exception cleanup that reduces the number of exceptions that
a user has to remember is tempting, but should probably be discussed on
msg176335 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2012-11-25 10:23
Closing as won't fix.
Date User Action Args
2012-12-15 02:57:40jceasetnosy: + jcea
2012-11-25 10:23:03mark.dickinsonsetstatus: open -> closed
resolution: wont fix
messages: + msg176335
2012-11-17 14:06:40asvetlovsetnosy: + asvetlov
2012-11-17 13:56:40skrahsetnosy: + skrah
messages: + msg175739
2012-11-17 13:47:16Ramchandra Aptesetnosy: + Ramchandra Apte
messages: + msg175738
2012-11-16 09:53:58serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg175673
2012-11-16 09:05:21mark.dickinsonsetassignee: mark.dickinson
messages: + msg175671
2012-11-16 05:16:59casevhsetnosy: + casevh
messages: + msg175668
2012-11-15 22:19:33kachayevsetfiles: + issue16483.diff

nosy: + kachayev
messages: + msg175654

keywords: + patch
2012-11-15 21:17:12mark.dickinsoncreate