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, unless the unittest is rigged so that it tests the pure Python version as well as the C version. But it still remains a matter of judgment whether in a particular case the unittest is overspecified or the Python version is incorrect. I think that in this case Kristján's hunch is correct, and the pure Python version needs to be adjusted to pass the test. I also think this is a low priority issue since it only affects behavior of error cases. --Guido On Sat, Jul 21, 2012 at 3:56 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote: > 2012/7/21 Antoine Pitrou <solipsis at pitrou.net>: >> Kristján Valur Jónsson <kristjan at ccpgames.com> 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) > TypeError: name must be a string > > But if the _hashlib extension module is not available, the python > version is used and ValueError is raised: > >>>> import sys >>>> sys.modules['_hashlib'] = None >>>> import hashlib >>>> hashlib.new(1) > ValueError: unsupported hash type 1 > > -- > Amaury Forgeot d'Arc > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4