Showing content from http://mail.python.org/pipermail/python-dev/attachments/20110120/0c1b56a2/attachment-0001.html below:
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 20, 2011, at 11:46 AM, Guido van Rossum wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Thu, Jan 20, 2011 at 5:16 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br><blockquote type="cite">On Thu, Jan 20, 2011 at 10:08 PM, Simon Cross<br></blockquote><blockquote type="cite"><<a href="mailto:hodgestar+pythondev@gmail.com">hodgestar+pythondev@gmail.com</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">I'm changing my vote on this to a +1 for two reasons:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">* Initially I thought this wasn't supported by Python at all but I see<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that currently it is supported but that support is broken (or at least<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">limited to UTF-8 filesystem encodings). Since support is there, might<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">as well make it better (especially if it tidies up the code base at<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the same time).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">* I still don't think it's a good idea to give modules non-ASCII names<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">but the "consenting adults" approach suggests we should let people<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">shoot themselves in the foot if they believe they have good reason to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">do so.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I'm also +1 on this for the reasons Simon gives.<br></blockquote><br>Same here. *Most* code will never be shared, or will only be shared<br>between users in the same community. When it goes wrong it's also a<br>learning opportunity. :-)<br></div></blockquote></div><br><div>Despite my usual proclivity for being contrarian, I find myself in agreement here. Linux users with locales that don't specify UTF-8 frankly _should_ have to deal with all kinds of nastiness until they can transcode their filesystems. MacOS and Windows both have a "right" answer here and your third-party tools shouldn't create mojibake in your filenames.</div><div><br></div><div>However, I feel that we should not necessarily be making non-ASCII programmers second-class citizens, if they are to be supported at all. The obvious outcome of the current regime is, if you want your code to <i>work</i> in the wider world, you have to make everything ASCII, so non-ASCII programmers have to do a huge amount of extra work to prepare their stuff for distribution. As an english speaker I'd be happy about that, but as a person with a lot of Chinese in-laws, it gives me pause.</div><div><br></div><div>There is a difference between sharing code for inspection and editing (where a little codec pain is good for the soul: set your locale to UTF-8 and forget it already!) and sharing code so that a (non-programming) user can just <i>run</i> it. If I can write software in English and distribute it to Chinese people, fair's fair, they should be able to write it in chinese and have it work on my computer.</div><div><br></div><div>To support the latter, could we just make sure that zipimport has a consistent, non-locale-or-operating-system-dependent interpretation of encoding? That way a distributed egg would be importable from a zipfile regardless of how screwed up the distribution target machine's filesystem is. (And this is yet more motivation for distributors to set zip_safe=True.)</div></body></html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4