[Python-3000] Support for PEP 3131

Stargaming stargaming at gmail.com
Sat May 12 20:12:38 CEST 2007


Guillaume Proux schrieb:
> Dear all,
> 
[snip]
> 
> In this respect, I strongly believe that support non-ASCII identifiers
> as proposed by PEP3131 would improve a number of things:
> - discussion and uptake of python in "non-ascii" countries

While still separating them from ascii-countries. They would start 
writing programs that expose foreign-phrased APIs but we would deny 
using them because we couldn't even type a single word!

> - ability for children to learn programming in their own language (I
> started programming at 7 years old and would have been very disturbed
> if I could not use my own language to type in programs)

AFAIK, allowing non-ascii identifiers would still *not* translate 
python. They would still have to struggle with every part of python that 
is builtin, i.e. builtins (you could let non-ascii identifiers reference 
them, though) and keywords. Better come up with some proposal to 
translate python (perhaps PyPy could do something here?) or all 
python-scripts (I think a translator could do its job here) to improve 
the situation.

> - increase of the number of new "interesting" packages from non-ascii countries

As stated above, we could not use them though. Bad deal, if you ask me!

> - ability for local programmers and local companies to provide
> "bridges" between international (english) APIs and local APIs.

I don't get the improvement offered by this one. We should *allow* 
non-ascii identifiers to **require** wrappers?

> - Increase the number of python users (from 7 to 77 years old)

Works in English, too.

> 
> In my humble opinion, now that UTF8 is accepted as the standard source
> code encoding, it is very difficult to understand why we should start
> putting restrictions on the kind of identifiers that are used (which
> would force people to comment line by line as they do now!).

No, we do not restrict them, we simply do not allow them (what is a huge 
difference here). UTF-8 will be allowed (*and* enforced by default) as a 
file encoding, i.e. strings and comments will be affected. I don't see 
the real restriction here. Correct me please, if I'm wrong.

> 
> When I am programming in Python, I am VERY DISTURBED when the code I
> write contains much comment. It needs to be readable just by glancing
> at it.

OTOH, I cannot glance at japanese code and know what it means. So, 
better the japanese developer named it badly but explained it than 
requiring me to consult a dictionary.

> 
> However, for most of the people who are core python developers, you
> should ask what is the typical reading speed for "ascii" characters
> for a e.g. standard Japanese pupil. You would be very surprised how
> slow that is. In my opinion (after leaving in Japan for quite a bit),
> people are very slow to read ASCII characters and this definitely
> restrain their programming productivity and expressiveness.

See above, at least *my* reading speed for japanese text tends to zero 
(if not less!).

> 
> Of course, for things like "standard libraries", I think that
> self-regulation and project based regulation will impose ASCII
> charsets for the base libraries and APIs but i really believe that
> letting people use their own charset to express themself will REALLY
> give them the productivity boost they would deserve from python.

They're free to express their thoughts in comments, today, still 
separating them from ascii-developers.

> 
> Let me know if you have any question.
> 
> Regards,
> 
> Guillaume

I do not think allowing people to program in *their* language would 
enhance integration. It would just split the python community *even* 
more. I like communicating with non-native English speakers much more 
than not communicating with them at all because they got their own 
language in there.
Additionally, I think the reason for rejection of this PEP is the same 
one that applied to all those "Let the user extend Python's grammar at 
runtime" -- one developer would have to learn a completely new language 
for understanding a program.
To communicate, we just have to find (or agree on) a common point 
between devs. Python is English, that's a matter of fact IMO. It is the 
common language that makes us a community and *one* language.

I'm, well, -1 on this (even though I don't know if I got a voice here).

-- 
Greetings,
Stargaming



More information about the Python-3000 mailing list