This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients ajaksu2, ezio.melotti, loewis, mhammond, vstinner
Date 2010-05-22.01:36:14
SpamBayes Score 1.320729e-07
Marked as misclassified No
Message-id <1274492176.31.0.938033584889.issue850997@psf.upfronthosting.co.za>
In-reply-to
Content
I patched py3k with mbcs_errors.patch (only encode_mbcs, not the decoder function) and most test pass: I opened #8784 for test_tarfile failure.

I don't think that it's a problem that mbcs only supports few error handlers, eg. 'strict', 'replace' and 'errors' (but not 'ignore' nor 'surrogateescape'). mbcs should be avoided anyway :-) It is kept for backward compatibility (with Python2). Python3 tries to avoid it by using the Unicode functions of Windows API.

I don't know exactly where mbcs is still used in Python3. If mbcs becomes more strict and raise new errors, I would like to say that the problem comes from the program, not in the encodig, and the program should be fixed (especilly if the "program" is the Python standard library).

About the backward compatibility with Python < 3.2: I don't know exactly if this change would be a problem or not. I bet that few people use (directly or indirectly) mbcs with Python 3.1 (on Windows), and few peple (or nobody) would notice this change. And as I wrote, if someone notices a problem: the problem should be fixed in the function using mbcs, not in the codec.
History
Date User Action Args
2010-05-22 01:36:16vstinnersetrecipients: + vstinner, loewis, mhammond, ajaksu2, ezio.melotti
2010-05-22 01:36:16vstinnersetmessageid: <1274492176.31.0.938033584889.issue850997@psf.upfronthosting.co.za>
2010-05-22 01:36:15vstinnerlinkissue850997 messages
2010-05-22 01:36:14vstinnercreate