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 Arfrever, amaury.forgeotdarc, belopolsky, benjamin.peterson, brett.cannon, eric.araujo, georg.brandl, ncoghlan, pitrou, r.david.murray, terry.reedy, vstinner
Date 2011-03-15.00:59:50
SpamBayes Score 1.78896e-12
Marked as misclassified No
Message-id <>
I finished to split the huge patch into smaller commits. You can now test the unicode_import Mercurial branch. Especially, it should be tested on Windows.

I don't know if I should merge the branch as an unique commit or as multiple commits. Some of them can be simply be merged.

You can try (file attached to this issue, extracted from the patch): a short script testing this issue.


The parser and _PyImport_GetDynLoadFunc() (on Windows) do still store the filename as byte strings, and so I don't think that Python is ready to use full Unicode range for filenames on Windows. But at least, it should now support non-ASCII module names and paths which are encodable to the ANSI code page.

Issue #10785 should improve the situation at least for the parser.

But for _PyImport_GetDynLoadFunc(), I don't know if there is a Unicode version of LoadLibraryEx().


> Modules/zipimport.c::make_filename: remove the limit buffer

Implemented in f286d3b514e0.

> Python/importdl.c::_PyImport_LoadDynamicModule: shortnameobj is not necessary

Done in 76907d413b99
Date User Action Args
2011-03-15 00:59:51vstinnersetrecipients: + vstinner, brett.cannon, georg.brandl, terry.reedy, amaury.forgeotdarc, ncoghlan, belopolsky, pitrou, benjamin.peterson, eric.araujo, Arfrever, r.david.murray
2011-03-15 00:59:51vstinnersetmessageid: <>
2011-03-15 00:59:50vstinnerlinkissue3080 messages
2011-03-15 00:59:50vstinnercreate