On 29 July 2013 16:48, Steven Velez <[email protected]> wrote:
> Linux is my weakest platform, but if the filenames are stored as byte
> strings on disk (no reason to believe they are not), then how that byte
> string is interpreted is a function of the encoding of the bytes.
However, as I understand it (which admittedly isn't well), the
'interpretation' as a unicode string is dependent on the host system, not
something stored in the filesystem. So if I name a file with a € character
on a system using UTF-8, its name contains the bytes \xe2\x82\xac, and I
still need to use those bytes if I access it on a system using Latin 1.
Anyway, looking at the code: in the base, we get a wide char filename (on
Py3) from Py_GetProgramFullPath, which is then converted to a plain char
filename using wcstombs, then converted back in SetExecutableFilename by
cxString_FromString, which is a macro calling PyUnicode_Decode. Is this the
issue you're looking at?
I agree that the double conversion seems superfluous. We need the
plain-char version to call system functions like stat and readlink, but it
should be possible to do that with a single conversion, so long as there's
a neat way to do that.
Thanks,
Thomas
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
cx-freeze-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cx-freeze-users
