testfailure on test_unicode.py in trivial object space
![](https://secure.gravatar.com/avatar/ec81952bf056935cc95aa84ac13aba69.jpg?s=120&d=mm&r=g)
Hi, I just checked out the source code and ran the unittest as per instructions on http://codespeak.net/pypy/index.cgi?source i.e. python pypy/pypy/testall.py (Note that there is a typo in the filename there (should be test_all.py), and that this runs the tests in trivial objectspace.) There is a test failure in objspace/std/test/test_unicodestring.py which is reproduced by python py.py -T PyPy in TrivialObjSpace on top of Python 2.3.3
u'a' == 'a' ||Traceback (interpreter-level): ... Traceback (application-level): File "<inline>", line 1 in ? 'a' == u'a' (application-level) TypeError: unicode.__cmp__(x,y) requires y to be a 'unicode', not a 'str'
This works correctly in standard object space. As far as I can tell pypy -T tries u'a'.__cmp__('a'), which raises the exception, while CPython ends up doing 'a'.__eq__(str(u'a')) I do think that pypy approaches this more rationally in standard object space (i.e., implementing __eq__ and __lt__ for unicode, rather than __cmp__, as CPython does). So it's probably a good idea to accept the exception in trivila object space, rather than trying to emulate the convoluted rules for comparison in CPython. It would probably be a good idea to skip the test in trivial object space (see patch). Cheers, Roeland Rengelink Index: test_unicodestring.py =================================================================== --- test_unicodestring.py (revision 5925) +++ test_unicodestring.py (working copy) @@ -5,13 +5,17 @@ from pypy.tool import testit -class TestUnicodeString(testit.AppTestCase): +class TestUnicodeStringStdOnly(testit.AppTestCase): + def setUp(self): + self.space = testit.objspace('std') + def test_compares(self): self.assertEqual(u'a', 'a') self.assertEqual('a', u'a') self.assertNotEqual(u'a', 'b') self.assertNotEqual('a', u'b') +class TestUnicodeString(testit.AppTestCase): def test_addition(self): def check(a, b): self.assertEqual(a, b)
![](https://secure.gravatar.com/avatar/5b37e6b4ac97453e4ba9dba37954cf79.jpg?s=120&d=mm&r=g)
Hello Roeland, On Wed, Aug 11, 2004 at 06:51:13PM +0200, Roeland Rengelink wrote:
PyPy in TrivialObjSpace on top of Python 2.3.3
u'a' == 'a' ||Traceback (interpreter-level): ...
It would probably be a good idea to skip the test in trivial object space (see patch).
Definitely. Patch applied -- thanks. A bientôt, Armin
![](https://secure.gravatar.com/avatar/1efc90ff6075b7654d8a8ce6e51a2cd3.jpg?s=120&d=mm&r=g)
Armin Rigo <arigo@tunes.org> writes:
Hello Roeland,
On Wed, Aug 11, 2004 at 06:51:13PM +0200, Roeland Rengelink wrote:
PyPy in TrivialObjSpace on top of Python 2.3.3
u'a' == 'a' ||Traceback (interpreter-level): ...
It would probably be a good idea to skip the test in trivial object space (see patch).
Definitely. Patch applied -- thanks.
I should have done this sooner, it's my fault and I've known about the trivial object space failure for some time, sorry. When is it time to make the standard object space the default? Cheers, mwh -- I have gathered a posie of other men's flowers, and nothing but the thread that binds them is my own. -- Montaigne
![](https://secure.gravatar.com/avatar/1efc90ff6075b7654d8a8ce6e51a2cd3.jpg?s=120&d=mm&r=g)
Armin Rigo <arigo@tunes.org> writes:
Hello Michael,
On Thu, Aug 12, 2004 at 06:41:50PM +0100, Michael Hudson wrote:
When is it time to make the standard object space the default?
Right now would be a great plan.
Done. Cheers, mwh -- ... so the notion that it is meaningful to pass pointers to memory objects into which any random function may write random values without having a clue where they point, has _not_ been debunked as the sheer idiocy it really is. -- Erik Naggum, comp.lang.lisp
participants (3)
-
Armin Rigo
-
Michael Hudson
-
Roeland Rengelink