Ka-Ping Yee wrote: > Hi, > > Here's a summary of some of the remaining open issues and unaddressed > arguments regarding PEP 3131. These are the ones I'm familiar with, > so I don't claim this to be complete. I hope it helps give some > perspective on this huge thread, though.
Thanks so much for this excellent roundup from the RoundUp Master :) Seriously, I've been staying well away from the PEP 3131 threads, and I was hoping that someone would post a summary of the issues so I could catch up. I'd like to make a couple of modest proposals on the PEP 3131 issue that I'm hoping will short-circuit some parts of this discussion. 1) My first proposal is that someone - one of the PEP 3131 advocates probably - create a set of patches, or possibly a branch, that implements unicode identifiers in whatever manner they think is appropriate. Write some actual code instead of just talking about it. This fork will consist of a Python interpreter with a different name - lets call it 'upython' for 'unicode python'. These same PEP 3131 advocates should also distribute precompiled packages containing the upython interpreter. For simplicity, it is OK to assume that regular Python is already installed as a prerequisite. The 'upython' interpreter can live in the same binary directory as regular python. The students who want to learn Python with Japanese identifiers can easily be taught to run 'upython' instead of 'python'. Since upython runs regular python scripts, they still have access to all of the regular python libraries and extension modules. Once upython becomes available to the public, it will be the goal of the 3131 advocates to get widespread adoption of upython. If there is much adoption, then that makes a strong argument for merging those features into regular python. On the other hand, if there is little adoption, then that's an argument to either maintain it as a fork, or drop it altogether. In other words - instead of endless discussions of hypotheticals, let people vote with their feet. Because I can already tell that as far as this mailing list goes, there will never be a consensus on this issue, due to basic value differences. 2) My second proposal is to drop all discussions of bidirectional support, since I think it's a red herring. So far, I haven't heard anyone whose native language is RTL lobbying for support of their language. Most of the vocal proponents of 3131 have been mainly concerned with asian languages. The people who are mainly bringing up the issue of Bidi are the people arguing against 3131, using it as the basis of an "excluded middle" argument that says that since its too difficult to do Bidi properly, then it's too difficult to do unicode identifiers. Yes, it may be technically "unfair" to certain ethnic groups to not support Bidi, but frankly, I don't see why the python-dev community has to solve all of the world's problems in one go. I would even go so far as to say that its OK to drop support for any languages that are "hard to do". (Note that I've done a fair bit of work supporting Bidi in my previous job, so I at least have a passing familiarity with the issues involved.) -- Talin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
