[Python-3000] PEP 3131 roundup

[Talin]

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