Message6435

Author amak
Recipients amak, yyamano
Date 2011-03-13.18:15:01
SpamBayes Score 6.500356e-14
Marked as misclassified No
Message-id <1300040102.58.0.359507947217.issue1707@psf.upfronthosting.co.za>
In-reply-to
Content
> It is taken from CPythonLib/test/test_multibytecodec_support.py.
> I'd like to make the test work for japanese codec.

OK. So the only place that it appears is in test code, not a real-world use case.

I would make the argument that the test is broken. It can only work on python interpreters that use UCS-2, i.e. cpython: it cannot work on python interpreters that use UTF-16, i.e. jython, and possibly ironpython.

I think it should be reported on the cpython bug tracker as a non-portable, i.e. cpython-specific, test.

I will see if I can come up with a patch we can push upstream.

In the meantime, I advise you to treat those tests as broken. Looking at several of the tests, they seem to only be using the illegal value for purposes not relating to the value itself. In these case, I advise you to simply use different test values, i.e. some other sequence that causes the user-supplied encode function to be called.

For example, in the following test, it is the return type of the myreplace function that is under test, not the unmappable sequence.

def test_callback_wrong_objects(self):
  def myreplace(exc):
    return (ret, exc.end)
  codecs.register_error("test.cjktest", myreplace)
  for ret in ([1, 2, 3], [], None, object(), 'string', ''):
    self.assertRaises(TypeError, self.encode, self.unmappedunicode,
       'test.cjktest')

Replacing self.unmappedunicode with some other sequence which causes invocation of "myreplace", at encode time, should permit the test to run, without needing an illegal UTF-16 sequence.
History
Date User Action Args
2011-03-13 18:15:02amaksetmessageid: <1300040102.58.0.359507947217.issue1707@psf.upfronthosting.co.za>
2011-03-13 18:15:02amaksetrecipients: + amak, yyamano
2011-03-13 18:15:02amaklinkissue1707 messages
2011-03-13 18:15:01amakcreate