Fixed. The TypeError in this nonsense never gonna work use case is now
consistent in 2.7, 3.2 and 3.3.
On Sat, Jul 21, 2012 at 7:10 PM, R. David Murray wrote:
> On Sun, 22 Jul 2012 01:05:35 -,
> =?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?= wrote:
> > Indeed, shame on me for not mentioning thi
On Sun, 22 Jul 2012 01:05:35 -, =?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=
wrote:
> Indeed, shame on me for not mentioning this.
> I rarely have the full complement of externals available when I'm doing
> python work, and it struck me that this unitest was failing.
> I suppose it should be
n.
K
Frá: python-dev-bounces+kristjan=ccpgames@python.org
[python-dev-bounces+kristjan=ccpgames@python.org] fyrir hönd Amaury
Forgeot d'Arc [amaur...@gmail.com]
Sent: 21. júlí 2012 22:56
To: Antoine Pitrou
Cc: python-dev@python.org
Efni: Re: [
I think I see Kristján's point: the pure Python implementation handles
errors differently than the C implementation, so the unittest fails if
the pure Python version is enabled. I imagine this is a general
problem that often occurs when a pure Python version is normally
shadowed by a C extension, u
2012/7/21 Antoine Pitrou :
> Kristján Valur Jónsson wrote:
>>
>> The code will raise ValueError when int(1) is passed in, but the
>> unittests expect a TypeError.
>
> Well, if test_hashlib passes, surely your analysis is wrong, no?
In the normal case, yes:
>>> import hashlib
>>> hashlib.new(1)
T
On Sat, 21 Jul 2012 21:29:50 +
Kristján Valur Jónsson wrote:
>
> The code will raise ValueError when int(1) is passed in, but the
> unittests expect a TypeError.
Well, if test_hashlib passes, surely your analysis is wrong, no?
--
Software development and contracting: http://pro.pitrou.net
I was hit by this today.
in test_hashlib.py there is this:
def test_unknown_hash(self):
self.assertRaises(ValueError, hashlib.new, 'spam spam spam spam spam')
self.assertRaises(TypeError, hashlib.new, 1)
but in hashlib.py, there is this code:
except ImportError:
pass # no e
