<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
</div>I consider the limitation of package names to non-ascii to be a blessing in<br>
disguise.  In python3, unicode module names are possible but not portable<br>
between systems.  This is because the non-ascii module names inside of a python<br>
file are abstract text but the representation on the filesystem is whatever<br>
the user's locale is.  The consensus on python-dev when this was brought up<br>
seemed to be that using non-ascii in your local locale was important for<br>
learning to use python.  But distributing non-ascii modules to other people<br>
was a bad idea.  (If you have the attention span for long threads,<br>
<a href="http://mail.python.org/pipermail/python-dev/2011-January/107467.html" target="_blank">http://mail.python.org/pipermail/python-dev/2011-January/107467.html</a><br>
Note that the threading was broken several times but the subject line stayed<br>
the same.)<br>
<br>
<br>
Description of the non-ascii module problem for people who want a summary:<br>
<br>
I have a python3 program that has::<br>
  #!/usr/bin/python3 -tt<br>
  # -*- coding: utf-8 -*-<br>
  import café<br>
  café.do_something()<br>
<br>
python3 reads this file in and represents café as an abstract text type<br>
because I wrote it using utf-8 encoding and it can therefore decode the<br>
file's contents to its internal representation.  However it then has to find<br>
the café module on disk.  In my environment, I have LC_ALL=en_US.utf8.<br>
python3 finds the file café.py and uses that to satisfy the import.<br>
<br>
However, I have a colleague that does work with me.  He has access to my<br>
program over a shared filesystem (or distributed to him via a git checkout<br>
or copied via an sdist, etc).  His locale uses latin-1 (ISO8859-1) as his<br>
encoding (For instance, LC_ALL=en_US.ISO8859-1).  When he runs my program,<br>
python3 is still able to read the application file itself (due to the piece<br>
of the file that specifies it's encoded in utf-8) but when it searches for<br>
a file to satisfy café on the disk it runs into probelsm because the café.py<br>
filename is not encoded using latin-1.</blockquote><div><br></div><div>Horrifying. All codecs that are not utf-8 should be banned, except on Windows. Or at least warn("Your Unicode is broken"); in fact, just put that in site.py unconditionally.</div>
<div><br></div><div>However remember that a non-ASCII pypi name <span style="font-family:arial,sans-serif;line-height:14.545454025268555px">☃ could still be just "import snowman". Only the .dist-info directory </span><span style="font-family:arial,sans-serif;line-height:14.545454025268555px">☃-1.0.0.dist-info would necessarily contain the higher Unicode characters.</span></div>
<div><span style="font-family:arial,sans-serif;line-height:14.545454025268555px"><br></span></div><div><span style="font-family:arial,sans-serif;line-height:14.545454025268555px">I will keep the - and document the - to _ folding convention. - turns into _ when going into a filename, and _ turns back into - when parsed out of a filename.</span></div>
<div><span style="font-family:arial,sans-serif;line-height:14.545454025268555px"><br></span></div><div><font face="arial, sans-serif"><span style="line-height:14.533333778381348px">The alternative to putting the metadata in the filename which btw isn't that big of a problem, is to have indexed metadata. IIUC apt-get and yum work this way and the filename does not matter at all. The tradeoff is of course that you have to generate the index. The simple index is a significant convenience of easy_install derived systems.</span></font></div>
<div><span style="font-family:arial,sans-serif;line-height:14.545454025268555px"><br></span></div><div><span style="font-family:arial,sans-serif;line-height:14.545454025268555px">Daniel Holth</span></div></div></div>