[Chandler-dev] Re: EggResourceManager ready for review

[Phillip J. Eby]

At 02:42 AM 8/1/2006 -0700, Andi Vajda wrote:

>On Mon, 31 Jul 2006, Brian Kirsch wrote:
>
>>Can you elaborate more, -1 is not very descriptive.
>
>Indeed, it's not. It was getting late here and I was responding to the 
>statement saying "However, requiring only ASCII file paths in the egg is 
>fine. I think anything beyond that is merely a nice to have feature and 
>not a must have feature."
>
>It's not fine and not just a nice to have feature. If this topic is all 
>about doing good on the i18n and l10n promises then requiring ASCII paths 
>seems to be going against that idea. ASCII-only paths are a US-only feature.
>
>But maybe I misunderstood the context of the conversation and my comment 
>is off the mark ?

We were talking about source code and resource filenames only.  For source 
code, file names are already effectively limited to ASCII since Python 
identifiers are strings, so the issue there is moot.

It could perhaps be argued that resource filenames (files containing 
images, HTML, etc.) should allow non-ASCII characters in the file names, 
but the problem is the lack of a universal file encoding across 
platforms.  Ironically, to ensure cross-platform internationalizability, 
filenames for localizable resources may need to be ASCII only.  That is, if 
you create a plugin that has a resource with a non-ASCII filename, a user 
on another platform might not be able to create a localization for it.

It's not solely an issue with zip files, since the user must be able to 
create filesystem files in order to build an egg in the first 
place.  Currently, such files will be zipped with 8-bit paths using the 
default filesystem encoding -- which of course may not match the encoding 
on another system where the zipfile is used.