On dom, 2011-01-23 at 16:13 -0500, Daniel Hyams wrote:
> After putting unicode support in the bootloader and getting to the
> point where all tests pass, I took the exe+supporting files for test1,
> and put them in a directory called "C:\Prog°Dir" (note the degree
> sign, which is unicode 00b0). I thought this would be an easy test,
> because even the original bootloader (nonunicode) doesn't have a
> problem with this one. Just for convenience, the test1.py script is
> below:
>
> print "test1 - hooks / strange pkg structures"
> e1 = 'a_func from pkg2.a'
> e2 = 'b_func from pkg2.b (pkg2/extra/b.py)'
> e3 = 'notamodule from pkg2.__init__'
> for p in sys.path:
> print " "+repr(p)
> from pkg1 import *
> t1 = a.a_func()
> if t1 != e1:
> print "expected:", e1
> print " got:", t1
> t2 = b.b_func()
> if t2 != e2:
> print "expected:", e2
> print " got:", t2
> t3 = notamodule()
> if t3 != e3:
> print "expected:", e3
> print " got:", t3
> print "test1 complete"
>
> Alas, I get the following output when I try to run, which corresponds
> to the first time that iu.py wakes up to do an import in the sample
> script iu.py:
>
> test1 - hooks / strange pkg structures
> right now, sys.path is
> u'C:/Prog\xb0Dir/test1'
> u'C:\\Prog\xb0Dir\\test1\\test1.exe?146944'
> Traceback (most recent call last):
> File "<string>", line 23, in <module>
> File "D:\home\My Dropbox\pyinstaller-unicode\iu.py", line 436, in importHook
> mod = _self_doimport(nm, ctx, fqname)
> File "D:\home\My Dropbox\pyinstaller-unicode\iu.py", line 505, in doimport
> mod = director.getmod(nm)
> File "D:\home\My Dropbox\pyinstaller-unicode\iu.py", line 295, in getmod
> owner = self.shadowpath[thing] = self.makeOwner(thing)
> File "D:\home\My Dropbox\pyinstaller-unicode\iu.py", line 313, in makeOwner
> owner = klass(path)
> File "D:\home\My Dropbox\dist\pyinstaller-unicode\iu.py", line 153,
> in __init__
> self.__zip = zipimport.zipimporter(path)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xb0' in
> position 7: ordinal not in range(128)
>
> So yes, there are now unicode entries in sys.path, which is necessary.
> Is the presence of unicode strings in sys.path going to be a big
> problem for iu.py?
Well, it's going to need some patching for sure. It's not supported at
the moment. I'm not even sure it's the correct way forward for 2.x at
least: Python has many bugs on Windows when it comes to handling unicode
filepaths which are not MBCS-encodable (using the system encoding).
Eg: if you are on a Western Windows and you try to run a .py file within
a directory with japanese characters, you get an error and the program
does not start.
As you probably know, Windows has two underlying APIs: the full Unicode
(W suffix in API calls) and the MBCS-encoded-with-system-encoding (A in
API calls). There are non-trivial point in Python itself and the Python
libraries where only the A version ("str" data type) is supported.
So my suggestion is not to force unicode paths in sys.path, but only
resort to them when there is no other way to represent them (= when mbcs
encoding fails). At that point, if zipimporter does not support unicode
path, it means that .egg files will not work, and it will stay as a
missing feature because of a Python bug.
> I'm not sure at all why the call to
> zipimport.zipimporter triggers an encoding either.
Probably a bug.
--
Giovanni Bajo :: Develer S.r.l.
[email protected] :: http://www.develer.com
Blog: http://giovanni.bajo.it
Last post: Compile-time Function Execution in D
--
You received this message because you are subscribed to the Google Groups
"PyInstaller" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pyinstaller?hl=en.
