Mark Dickinson added the comment:
> I'd call it a deviation from the specification then.
> Do you happen to know what the intention was?
Well, we're kinda outside the specification here.
Rightly or wrongly, Decimal('infinity').as_tuple() was originally implemented
to return (0, (0,), 'F'); I'm fairly sure that was intentional, and I think
that the Decimal constructor should continue to accept that tuple as a
representation of infinity---else we're risking breaking existing code.
I think I may have muddied the waters at some later stage by modifying the
constructor to ignore the second argument on input, so that (0, (), 'F') and
(0, (0,), 'F') both work on input. Or maybe it was already the case that the
second argument was ignored; I'm not sure about that.
I do agree that (0, (), 'F') is a better representation of infinity, and it
would have been a little better if that had been used from the start, but I
don't think it's worth the potential breakage or the deprecation cycles
involved in 'fixing' this.
If it helps at all, it would probably be safe to disallow tuples other than ()
and (0,); I doubt anyone's intentionally passing anything else here.
So:
+1 on allowing ((0, (0,), 'F')) as input in _decimal. I do see this report as
a regression from 3.2 that should be fixed.
-0 on changing Infinity.as_tuple() to (0, (), 'F'), and perhaps then
deprecating ((0, (0,), 'F') as a legal input.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15882>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
