Mark Dickinson dicki...@gmail.com added the comment:
Given the lack of agreement here, I propose that we just leave the current code
as it is; it doesn't seem like a big issue to me, and we should resist messing
with code that isn't clearly broken.
--
resolution: - wont fix
status:
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7811
___
Mark Dickinson dicki...@gmail.com added the comment:
It's a bit ambiguous: the object being supplied to the Decimal constructor
does have the right type (tuple), but the wrong contents (i.e., value). So you
could argue either way on this, I guess.
--
assignee: - mark.dickinson
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
A ValueError seems more appropriate to me.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7811
___
Mark Dickinson dicki...@gmail.com added the comment:
From both practical and purity points of view I think I prefer TypeError for
the cases Stefan gives: if you're passing a float for the sign, then you've
somehow ended up with the wrong type for that sign, and that's a TypeError
rather than
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I could see a TypeError for the outer tuple a tuple wasn't passed-in. If the
contents aren't what we expect, I believe that calling it a ValueError is the
Python way.
--
___
New submission from Stefan Krah stefan-use...@bytereef.org:
As discussed privately, the following test cases should raise TypeError
(currently ValueError):
self.assertRaises(TypeError, Decimal, (0., (4, 3, 4, 9, 1), 2) )
self.assertRaises(TypeError, Decimal, (Decimal(1), (4, 3, 4, 9, 1), 2))
