On dom, 2010-11-28 at 23:27 +0100, Martin Zibricky wrote:
> I posted this on the issue tracker.
> 
> http://www.pyinstaller.org/ticket/298
> 
> It seems that the reason for this issue is that windows environment
> variables on windows are stored in another encoding than the internal
> python unicode encoding.
> 
> As suggested, this bug could be fixed by converting all values in
> '''os.environ['ENVIRONMENT_VARIABLE_NAME']''' to/from encoding contained
> in ''sys.getfilesystemencoding()''.
> 
> However using the function ''sys.getfilesystemencoding()'' is in python
> 2.3+. So it would mean dropping compatibility for python 2.2.

> Manipulating with ''os.environ'' is done on many places in pyinstaller
> code and thus to fix this should be not as trivial as it seems.

But most uses are legit; eg: PyInstaller reads a path from sys.path
(which is not unicode), composes a filename, and passes it to open().
This is perfectly fine under all platforms. The problems seem to arise
for some reason with zipimport; maybe it expects a unicode argument for
some reason, or it is just buggy. 

I would try to fix PyInstaller only where it crashes; it does not make
sense to do a refactoring for these kind of things which are totally
different in Python3 anyway.

> I think it is not feasible to fix this in 1.5 since it would require a
> lot of changes. I would recommend to fix this in svn and in any 1.5.x
> bug fix release.

Since it's not a regression (it's always been broken in latest
releases), I agree: I don't see a reason to rush.
-- 
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.

Reply via email to