PEP 3131: Supporting Non-ASCII Identifiers

[=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=]

PEP 1 specifies that PEP authors need to collect feedback from the
community. As the author of PEP 3131, I'd like to encourage comments
to the PEP included below, either here (comp.lang.python), or to
py*********@python.org

In summary, this PEP proposes to allow non-ASCII letters as
identifiers in Python. If the PEP is accepted, the following
identifiers would also become valid as class, function, or
variable names: Löffelstiel, changé, ошибка, or 売りå*´
(hoping that the latter one means "counter").

I believe this PEP differs from other Py3k PEPs in that it really
requires feedback from people with different cultural background
to evaluate it fully - most other PEPs are culture-neutral.

So, please provide feedback, e.g. perhaps by answering these
questions:
- should non-ASCII identifiers be supported? why?
- would you use them if it was possible to do so? in what cases?

Regards,
Martin
PEP: 3131
Title: Supporting Non-ASCII Identifiers
Version: $Revision: 55059 $
Last-Modified: $Date: 2007-05-01 22:34:25 +0200 (Di, 01 Mai 2007) $
Author: Martin v. Löwis <ma****@v.loewis.de>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 1-May-2007
Python-Version: 3.0
Post-History:
Abstract
========

This PEP suggests to support non-ASCII letters (such as accented
characters, Cyrillic, Greek, Kanji, etc.) in Python identifiers.

Rationale
=========

Python code is written by many people in the world who are not familiar
with the English language, or even well-acquainted with the Latin
writing system. Such developers often desire to define classes and
functions with names in their native languages, rather than having to
come up with an (often incorrect) English translation of the concept
they want to name.

For some languages, common transliteration systems exist (in particular,
for the Latin-based writing systems). For other languages, users have
larger difficulties to use Latin to write their native words.

Common Objections
=================

Some objections are often raised against proposals similar to this one.

People claim that they will not be able to use a library if to do so
they have to use characters they cannot type on their keyboards.
However, it is the choice of the designer of the library to decide on
various constraints for using the library: people may not be able to use
the library because they cannot get physical access to the source code
(because it is not published), or because licensing prohibits usage, or
because the documentation is in a language they cannot understand. A
developer wishing to make a library widely available needs to make a
number of explicit choices (such as publication, licensing, language
of documentation, and language of identifiers). It should always be the
choice of the author to make these decisions - not the choice of the
language designers.

In particular, projects wishing to have wide usage probably might want
to establish a policy that all identifiers, comments, and documentation
is written in English (see the GNU coding style guide for an example of
such a policy). Restricting the language to ASCII-only identifiers does
not enforce comments and documentation to be English, or the identifiers
actually to be English words, so an additional policy is necessary,
anyway.

Specification of Language Changes
=================================

The syntax of identifiers in Python will be based on the Unicode
standard annex UAX-31 [1]_, with elaboration and changes as defined
below.

Within the ASCII range (U+0001..U+007F), the valid characters for
identifiers are the same as in Python 2.5. This specification only
introduces additional characters from outside the ASCII range. For
other characters, the classification uses the version of the Unicode
Character Database as included in the ``unicodedata`` module.

The identifier syntax is ``<ID_Start<ID_Continue>*``.

``ID_Start`` is defined as all characters having one of the general
categories uppercase letters (Lu), lowercase letters (Ll), titlecase
letters (Lt), modifier letters (Lm), other letters (Lo), letter numbers
(Nl), plus the underscore (XXX what are "stability extensions" listed in
UAX 31).

``ID_Continue`` is defined as all characters in ``ID_Start``, plus
nonspacing marks (Mn), spacing combining marks (Mc), decimal number
(Nd), and connector punctuations (Pc).

All identifiers are converted into the normal form NFC while parsing;
comparison of identifiers is based on NFC.

Policy Specification
====================

As an addition to the Python Coding style, the following policy is
prescribed: All identifiers in the Python standard library MUST use
ASCII-only identifiers, and SHOULD use English words wherever feasible.

As an option, this specification can be applied to Python 2.x. In that
case, ASCII-only identifiers would continue to be represented as byte
string objects in namespace dictionaries; identifiers with non-ASCII
characters would be represented as Unicode strings.

Implementation
==============

The following changes will need to be made to the parser:

1. If a non-ASCII character is found in the UTF-8 representation of the
source code, a forward scan is made to find the first ASCII
non-identifier character (e.g. a space or punctuation character)

2. The entire UTF-8 string is passed to a function to normalize the
string to NFC, and then verify that it follows the identifier syntax.
No such callout is made for pure-ASCII identifiers, which continue to
be parsed the way they are today.

3. If this specification is implemented for 2.x, reflective libraries
(such as pydoc) must be verified to continue to work when Unicode
strings appear in ``__dict__`` slots as keys.

References
==========

... [1] http://www.unicode.org/reports/tr31/
Copyright
=========

This document has been placed in the public domain.

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Paul Rubin schrieb:

>Plenty of programming languages already support unicode identifiers,

Could you name a few? Thanks.

The GNU assembler also supports non-ASCII symbol names on object file
formats that support it; this includes at least ELF (not sure about
PE32). Higher-level programming languages can use that to encode symbols
in UTF-8.

Regards,
Martin

[Stefan Behnel]

Paul Rubin wrote:

Stefan Behnel <st******************@web.dewrites:

>But then, where's the problem? Just stick to accepting only patches that are
plain ASCII *for your particular project*.

There is no feature that has ever been proposed for Python, that cannot
be supported with this argument. If you don't like having a "go to"
statement added to Python, where's the problem? Just don't use it in
your particular project.

"go to" is not meant for clarity, nor does it encourage code readability.

But that's what this PEP is about.

Stefan

[Stefan Behnel]

Paul Rubin wrote:

Stefan Behnel <st******************@web.dewrites:

>But then, where's the problem? Just stick to accepting only patches that are
plain ASCII *for your particular project*.

There is no feature that has ever been proposed for Python, that cannot
be supported with this argument. If you don't like having a "go to"
statement added to Python, where's the problem? Just don't use it in
your particular project.

"go to" is not meant for clarity, nor does it encourage code readability.

But that's what this PEP is about.

Stefan

[Eric Brunel]

On Mon, 14 May 2007 18:30:42 +0200, <ru***@yahoo.comwrote:
[snip]

Can a discussion about support for non-english identifiers (1)
conducted in a group where 99.9% of the posters are fluent
speakers of english (2), have any chance of being objective
or fair?

Agreed.

Although probably not-sufficient to overcome this built-in
bias, it would be interesting if some bi-lingual readers would
raise this issue in some non-english Python discussion
groups to see if the opposition to this idea is as strong
there as it is here.

Done on the french Python newsgroup.
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"

[Eric Brunel]

On Tue, 15 May 2007 07:15:21 +0200, ZeD <vi***********@gmail.comwrote:

Neil Hodgson wrote:

> Ada 2005 allows Unicode identifiers and even includes the constant
'?' in Ada.Numerics.

^^^

this. is. cool.

Yeah, right... The problems begin...

Joke aside, this just means that I won't ever be able to program math in
ADA, because I have absolutely no idea on how to do a 'pi' character on my
keyboard.

Still -1 for the PEP...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"

[Stefan Behnel]

Eric Brunel wrote:

On Tue, 15 May 2007 07:15:21 +0200, ZeD <vi***********@gmail.comwrote:

>Neil Hodgson wrote:

>> Ada 2005 allows Unicode identifiers and even includes the constant
'?' in Ada.Numerics.

^^^

>this. is. cool.

Yeah, right... The problems begin...

Joke aside, this just means that I won't ever be able to program math in
ADA, because I have absolutely no idea on how to do a 'pi' character on
my keyboard.

Ah, you'll learn. :)

Stefan

[Antoon Pardon]

On 2007-05-15, Paul Rubin <httpwrote:

Stefan Behnel <st******************@web.dewrites:

>But then, where's the problem? Just stick to accepting only patches that are
plain ASCII *for your particular project*.

There is no feature that has ever been proposed for Python, that cannot
be supported with this argument. If you don't like having a "go to"
statement added to Python, where's the problem? Just don't use it in
your particular project.

There is no feature that has ever been propose that cannot be rejected
by the opposite argument: I don't want to be bothered with something
like this and if it is introduced sooner or later I will.

And in my experience this argument is used a lot more than the first.

--
Antoon Pardon

[Duncan Booth]

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.com >
wrote:

Stefan Behnel a écrit :

>Bruno Desthuilliers wrote:

>>but CS is english-speaking, period.

That's a wrong assumption.

I've never met anyone *serious* about programming and yet unable to
read and write CS-oriented technical English.

I don't believe that Python should be restricted to people *serious* about
programming.

Recently there has been quite a bit of publicity about the One Laptop Per
Child project. The XO laptop is just beginning rollout to children and
provides two main programming environments: Squeak and Python. It is an
exciting thought that that soon there will be millions of children in
countries such as Nigeria, Brazil, Uruguay or Nepal[*] who have the
potential to learn to program, but tragic if the Python community is too
arrogant to consider it acceptable to use anything but English and ASCII.

Yes, any sensible widespread project is going to mandate a particular
language for variable names and comments, but I see no reason at all why
they all have to use English.

[*] BTW, I see OLPC Nepal is looking for volunteer Python programmers this
Summer: if anyone fancies spending 6+ weeks in Nepal this Summer for no
pay, see http://www.mail-archive.com/de***@la.../msg04109.html

[Hendrik van Rooyen]

"Anders J. Munch" wrote:

Hendrik van Rooyen wrote:

And we have been through the Macro thingy here, and the consensus
seemed to be that we don't want people to write their own dialects.

Macros create dialects that are understood only by the three people in your
project group. It's unreasonable to compare that to a "dialect" such as
Mandarin, which is exclusive to a tiny little clique of one billion people.

A bit out of context here - I was trying to address the dichotomy of
reserved words and native identifiers - so if you want Mandarin or
Russian or Cantonese or Afrikaans or Flemish or German or Hebrew
identifiers, will you really be happy with the hassle of "for", "while",
"in" - as plain old English ASCII? How are you going to allow the native
speaker to get those into his mother's tongue without something like macros?

Are you suggesting separate parsers for each language?
Table driven parsers?

And if you go the macro route, how are you going to stop it being
abused for purposes that have nothing to do with language translation?

Do I have to draw a picture?

- Hendrik

[Eric Brunel]

On Tue, 15 May 2007 09:38:38 +0200, Duncan Booth
<du**********@invalid.invalidwrote:

Recently there has been quite a bit of publicity about the One Laptop Per
Child project. The XO laptop is just beginning rollout to children and
provides two main programming environments: Squeak and Python. It is an
exciting thought that that soon there will be millions of children in
countries such as Nigeria, Brazil, Uruguay or Nepal[*] who have the
potential to learn to program, but tragic if the Python community is too
arrogant to consider it acceptable to use anything but English and ASCII.

You could say the same about Python standard library and keywords then.
Shouldn't these also have to be translated? One can even push things a
little further: I don't know about the languages used in the countries you
mention, but for example, a simple construction like 'if <condition<do
something>' will look weird to a Japanese (the Japanese language has a
"post-fix" feel: the equivalent of the 'if' is put after the condition).
So why enforce an English-like sentence structure?

Yes, any sensible widespread project is going to mandate a particular
language for variable names and comments, but I see no reason at all why
they all have to use English.

Because that's what already happens? We definitely are in a globalized
world, and the only candidate language having a chance to allow people to
communicate with each other is English. Period. And believe me, I don't
like that (I'm French, if that can give you an idea about how much I
don't...). But that's a fact. Even people knowing the same language
sometimes communicate in English just in case they have to widen the
discussion to somebody else. To give you a perfect example, I had to
discuss just yesterday an answer we had to do to a Belgian guy, who speaks
French without any problem. His mail was written in English, and we
answered in English.

Anyway:

I don't believe that Python should be restricted to people *serious*
about programming.

You have a point here. When learning to program, or when programming for
fun without any intention to do something serious, it may be better to
have a language supporting "native" characters in identifiers. My problem
is: if you allow these, how can you prevent them from going public someday?
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"

[Stefan Behnel]

Eric Brunel wrote:

You have a point here. When learning to program, or when programming for
fun without any intention to do something serious, it may be better to
have a language supporting "native" characters in identifiers. My
problem is: if you allow these, how can you prevent them from going
public someday?

My personal take on this is: search-and-replace is easier if you used well
chosen identifiers. Which is easier if you used your native language for them,
which in turn is easier if you can use the proper spellings. So I don't see
this problem getting any worse compared to the case where you use a
transliteration or even badly chosen english-looking identifiers from a small
vocabulary that is foreign to you.

For example, how many German names for a counter variable could you come up
with? Or english names for a function that does domain specific stuff and that
was specified in your native language using natively named concepts? Are you
sure you always know the correct english translations?

I think native identifiers can help here. Using them will enable you to name
things just right and with sufficient variation to make a search-and-replace
with english words easier in case it ever really becomes a requirement.

Stefan

[Anton Vredegoor]

Duncan Booth wrote:

Recently there has been quite a bit of publicity about the One Laptop Per
Child project. The XO laptop is just beginning rollout to children and
provides two main programming environments: Squeak and Python. It is an
exciting thought that that soon there will be millions of children in
countries such as Nigeria, Brazil, Uruguay or Nepal[*] who have the
potential to learn to program, but tragic if the Python community is too
arrogant to consider it acceptable to use anything but English and ASCII.

Please don't be too quick with assuming arrogance. I have studied social
psychology for eleven years and my thesis was just about such a subject.
I even held a degree in social psychology for some time before my
government in their infinite wisdom decided to 'upgrade' the system so
that only people holding *working* positions at a university would be
able to convert their degrees to the new system. I suspect discerning
people can still sense a twinge of disagreement with that in my
professional attitude. However I still think the results of my research
were valid.

The idea was to try and measure whether it would be better for foreign
students visiting the Netherlands to be kept in their own separate
groups being able to speak their native language and to hold on to their
own culture versus directly integrating them with the main culture by
mixing them up with Dutch student groups (in this case the main culture
was Dutch).

I think I my research data supported the idea that it is best even for
the foreigners themselves to adapt as quickly as possible to the main
culture and start to interact with it by socializing with 'main culture'
persons.

My research at that time didn't fit in at all with the political climate
of the time and subsequently it was impossible for me to find a job.
That didn't mean that I forgot about it. I think a lot of the same ideas
would help the OLPC project so that they will not make the same mistake
of creating separate student populations.

I believe -but that is a personal belief which I haven't been able to
prove yet by doing research- that those people currently holding
positions of power in the main culture actively *prevent* new groups to
integrate because it would threaten their positions of power.

So instead of having a favorable view of teachers who are 'adapting' to
their students culture I have in fact quite the opposite view: Those
teachers are actually harming the future prospects of their students.
I'm not sure either whether they do it because they're trying to protect
their own positions or are merely complicit to higher up political forces.

Whatever you make of my position I would appreciate if you'd not
directly conclude that I'm just being arrogant or haven't thought about
the matter if I am of a different opinion than you.

Yes, any sensible widespread project is going to mandate a particular
language for variable names and comments, but I see no reason at all why
they all have to use English.

Well I clearly do see a reason why it would be in their very best
interest to immediately start to use English and to interact with the
main Python community.

[*] BTW, I see OLPC Nepal is looking for volunteer Python programmers this
Summer: if anyone fancies spending 6+ weeks in Nepal this Summer for no
pay, see http://www.mail-archive.com/de***@la.../msg04109.html

Thanks. I'll think about it. The main problem I see for my participation
is that I have absolutely *no* personal funds to contribute to this
project, not even to pay for my trip to that country or to pay my rent
while I'm abroad.

A.

[Steven D'Aprano]

On Sun, 13 May 2007 23:00:16 -0700, Alex Martelli wrote:

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:

>automated -- if the patch uses an unexpected "#-*- coding: blah" line,
or

No need -- a separate PEP (also by Martin) makes UTF-8 the default
encoding, and UTF-8 can encode any Unicode character you like.

Ah, that puts a slightly different perspective on the issue.

--
Steven.

[Steven D'Aprano]

On Sun, 13 May 2007 23:00:17 -0700, Alex Martelli wrote:

Aldo Cortesi <al**@nullcube.comwrote:

>Thus spake Steven D'Aprano (st****@REMOVE.THIS.cybersource.com.au):

If you're relying on cursory visual inspection to recognize harmful
code, you're already vulnerable to trojans.

What a daft thing to say. How do YOU recognize harmful code in a patch
submission? Perhaps you blindly apply patches, and then run your test
suite on a quarantined system, with an instrumented operating system to
allow you to trace process execution, and then perform a few weeks
worth of analysis on the data?

Me, I try to understand a patch by reading it. Call me old-fashioned.

I concur, Aldo. Indeed, if I _can't_ be sure I understand a patch, I
don't accept it -- I ask the submitter to make it clearer.

Yes, but there is a huge gulf between what Aldo originally said he does
("visual inspection") and *reading and understanding the code*.

If somebody submits a piece of code where all the variable names,
functions, classes etc. are like a958323094, a498307913, etc. you're
going to have a massive problem following the code despite being in
ASCII. You would be sensible to reject the code. If you don't read
Chinese, and somebody submits a patch in Chinese, you would be sensible
to reject it, or at least have it vetted by somebody who does read
Chinese.

But is it really likely that somebody is going to submit a Chinese patch
to your English or Italian project? I don't think so.

Homoglyphs would ensure I could _never_ be sure I understand a patch,
without at least running it through some transliteration tool. I don't
think the world of open source needs this extra hurdle in its path.

If I've understood Martin's post, the PEP states that identifiers are
converted to normal form. If two identifiers look the same, they will be
the same.

Except, probably, identifiers using ASCII O and 0, or I l and 1, or rn
and m. Depending on your eyesight and your font, they look the same. The
solution to that isn't to prohibit O and 0 in identifiers, but to use a
font that makes them look different.

But even if the homoglyphs was a problem, as hurdles go, it's hardly a
big one. No doubt you already use automated tools for patch management,
revision control, bug tracking, unit-testing, maybe even spell checking.
Adding a transliteration tool to your arsenal is not really a disaster.

--
Steven.

[Thorsten Kampe]

* Eric Brunel (Tue, 15 May 2007 10:52:21 +0200)

On Tue, 15 May 2007 09:38:38 +0200, Duncan Booth
<du**********@invalid.invalidwrote:

Recently there has been quite a bit of publicity about the One Laptop Per
Child project. The XO laptop is just beginning rollout to children and
provides two main programming environments: Squeak and Python. It is an
exciting thought that that soon there will be millions of children in
countries such as Nigeria, Brazil, Uruguay or Nepal[*] who have the
potential to learn to program, but tragic if the Python community is too
arrogant to consider it acceptable to use anything but English and ASCII.

You could say the same about Python standard library and keywords then.

You're mixing apples and peaches: identifiers (variable names) are
part of the user interface for the programmer and free to his
diposition.

Thorsten

[Steven D'Aprano]

On Sun, 13 May 2007 21:21:57 -0700, Paul Rubin wrote:

Steven D'Aprano <st****@REMOVE.THIS.cybersource.com.auwrites:

>password_is_correct is all ASCII.

How do you know that? What steps did you take to ascertain it?

Why would I care? I don't bother to check it is ASCII because it makes no
difference whether it is ASCII or not. Allowing non-ASCII chars adds no
new vulnerability. Here's your example again, modified to show what I
mean:
if user_entered_password != stored_password_from_database:
password_is_correct = False
# much code goes here...
password_is_correct = True # sneaky backdoor inserted by Black Hat
# much code goes here...
if password_is_correct:
log_user_in()

Your example was poor security in the first place, but the vulnerability
doesn't come from the name of the identifier. It comes from the algorithm
you used.
--
Steven.

[Duncan Booth]

"Eric Brunel" <er*********@pragmadev.comwrote:

On Tue, 15 May 2007 09:38:38 +0200, Duncan Booth
<du**********@invalid.invalidwrote:

>Recently there has been quite a bit of publicity about the One Laptop
Per Child project. The XO laptop is just beginning rollout to
children and provides two main programming environments: Squeak and
Python. It is an exciting thought that that soon there will be
millions of children in countries such as Nigeria, Brazil, Uruguay or
Nepal[*] who have the potential to learn to program, but tragic if
the Python community is too arrogant to consider it acceptable to use
anything but English and ASCII.

You could say the same about Python standard library and keywords
then. Shouldn't these also have to be translated? One can even push
things a little further: I don't know about the languages used in the
countries you mention, but for example, a simple construction like
'if <condition<do something>' will look weird to a Japanese (the
Japanese language has a "post-fix" feel: the equivalent of the 'if'
is put after the condition). So why enforce an English-like sentence
structure?

Yes, non-English speakers have to learn a set of technical words which are
superficially in English, but even English native speakers have to learn
non-obvious meanings, or non-English words 'str', 'isalnum', 'ljust'.
That is an unavoidable barrier, but it is a limited vocabulary and a
limited set of syntax rules. What I'm trying to say is that we shouldn't
raise the entry bar any higher than it has to be.

The languages BTW in the countries I mentioned are: in Nigeria all school
children must study both their indigenous language and English, Brazil and
Uruguay use Spanish and Nepali is the official language of Nepal.

[Duncan Booth]

Anton Vredegoor <an*************@gmail.comwrote:

Whatever you make of my position I would appreciate if you'd not
directly conclude that I'm just being arrogant or haven't thought
about the matter if I am of a different opinion than you.

Sorry, I do apologise if that came across as a personal attack on you. It
certainly wasn't intended as such.

I was writing about the community as a whole: I think it would be arrogant
if the Python community was to decide not to support non-ascii identifiers
purely because the active community of experienced users doesn't want them
used in OSS software. OTOH, it may just be my own arrogance thinking such a
thing.

>

>Yes, any sensible widespread project is going to mandate a particular
language for variable names and comments, but I see no reason at all
why they all have to use English.

Well I clearly do see a reason why it would be in their very best
interest to immediately start to use English and to interact with the
main Python community.

I think the 'main Python community' is probably a very small subset of all
Python developers. To be honest I expect that only a tiny percentage of
OLPC users will ever do any programming, and a miniscule fraction of those
will go beyond simple scripts (but I'd love to be proved wrong and in a few
years be facing 50 million new Python programmers). Most of the programming
which is likely to happen on these devices is not going to require input
from the wider community.

>

>[*] BTW, I see OLPC Nepal is looking for volunteer Python programmers
this Summer: if anyone fancies spending 6+ weeks in Nepal this Summer
for no pay, see
http://www.mail-archive.com/de***@la.../msg04109.html

Thanks. I'll think about it. The main problem I see for my
participation is that I have absolutely *no* personal funds to
contribute to this project, not even to pay for my trip to that
country or to pay my rent while I'm abroad.

I think accomodation was included for the first 4 volunteers, the tricky
bit would be the air fare, I've no idea how much but I suspect flights to
Nepal aren't cheap.

[Eric Brunel]

On Tue, 15 May 2007 11:25:50 +0200, Thorsten Kampe
<th******@thorstenkampe.dewrote:

* Eric Brunel (Tue, 15 May 2007 10:52:21 +0200)

>On Tue, 15 May 2007 09:38:38 +0200, Duncan Booth
<du**********@invalid.invalidwrote:

Recently there has been quite a bit of publicity about the One Laptop

Per

Child project. The XO laptop is just beginning rollout to children and
provides two main programming environments: Squeak and Python. It is

an

exciting thought that that soon there will be millions of children in
countries such as Nigeria, Brazil, Uruguay or Nepal[*] who have the
potential to learn to program, but tragic if the Python community is

too

arrogant to consider it acceptable to use anything but English and

ASCII.

You could say the same about Python standard library and keywords then.

You're mixing apples and peaches: identifiers (variable names) are
part of the user interface for the programmer and free to his
diposition.

So what? Does it mean that it's acceptable for the standard library and
keywords to be in English only, but the very same restriction on
user-defined identifiers is out of the question? Why? If I can use my own
language in my identifiers, why can't I write:

classe MaClasse:
définir __init__(moi_même, maListe):
moi_même.monDictionnaire = {}
pour i dans maListe:
moi_même.monDictionnaire[i] = Rien

For a French-speaking person, this is far more readable than:

class MaClasse:
def __init__(self, maListe):
self.monDictionnaire = {}
for i in maListe:
self.monDictionnaire[i] = None

Now, *this* is mixing apples and peaches... And this would look even
weirder with a non-indo-european language...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Stefan Behnel schrieb:

I agree that code posted to comp.lang.python should use english identifiers
and that it is worth considering to use english identifiers in open source
code that is posted to a public OS project site. Note that I didn't say "ASCII
identifiers" but plain english identifiers. All other code should use the
language and encoding that fits its environment best.

Unless you are 150% sure that there will *never* be the need for a
person who does not know your language of choice to be able to read or
modify your code, the language that "fits the environment best" is English.

I simply doubt that the problem which this PEP wants to solve actually
exists. If you know so little English that you really need non-ASCII
identifiers, you will have a very hard time programming Python anyway.

My native language is German, and in code I cooperate on with other
Germans, I still use English identifiers, even if I am "quite sure" that
no non-German will ever have to read the code. It also makes it easier
and more beautiful for me if my code uses the same natural language as
the stdlib and third party modules do. I do not need non-ASCII
characters in Python identifiers.

--
René

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Marc 'BlackJack' Rintsch schrieb:

You find it in the sources by the line number from the traceback and the
letters can be copy'n'pasted if you don't know how to input them with your
keymap or keyboard layout.

Typing them is not the only problem. They might not even *display*
correctly if you don't happen to use a font that supports them.

--
René

[Stefan Behnel]

René Fleschenberg wrote:

Marc 'BlackJack' Rintsch schrieb:

>You find it in the sources by the line number from the traceback and the
letters can be copy'n'pasted if you don't know how to input them with your
keymap or keyboard layout.

Typing them is not the only problem. They might not even *display*
correctly if you don't happen to use a font that supports them.

Sounds like high time for an editor that supports the project team in their
work, don't you think?

Stefan

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Steven D'Aprano schrieb:

How is that different from misreading "disk_burnt = True" as "disk_bumt =
True"? In the right (or perhaps wrong) font, like the ever-popular Arial,
the two can be visually indistinguishable. Or "call" versus "cal1"?

That is the wrong question. The right question is: Why do you want to
introduce *more* possibilities to do such mistakes? Does this PEP solve
an actual problem, and if so, is that problem big enough to be worth the
introduction of these new risks and problems?

I think it is not. I think that the problem only really applies to very
isolated use-cases. So isolated that they do not justify a change to
mainline Python. If someone thinks that non-ASCII identifiers are really
needed, he could maintain a special Python branch that supports them. I
doubt that there would be alot of demand for it.

--
René

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Anders J. Munch schrieb:

There's any number of things to be done about that.
1. # -*- encoding: ascii -*-

This would limit comments and string literals to ASCII, too. I use "-*-
coding: utf-8 -*-" in all of my code and I am still against this PEP.

It is useful to be able to spell my own name correctly in a comment. It
is not useful to do so in a Python identifier.

--
René

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Stefan Behnel schrieb:

Ok, but then maybe that code just will not become Open Source. There's a
million reasons code cannot be made Open Source, licensing being one, lack of
resources being another, bad implementation and lack of documentation being
important also.

But that won't change by keeping Unicode characters out of source code.

Allowing non-ASCII identifiers will not change existing hindrances for
code-sharing, but it might add a new one.

IMO, the burden of proof is on you. If this PEP has the potential to
introduce another hindrance for code-sharing, the supporters of this PEP
should be required to provide a "damn good reason" for doing so. So far,
you have failed to do that, in my opinion. All you have presented are
vague notions of rare and isolated use-cases.

I'm only saying that this shouldn't be a language restriction, as there
definitely *are* projects (I know some for my part) that can benefit from the
clarity of native language identifiers (just like English speaking projects
benefit from the English language). And yes, this includes spelling native
language identifiers in the native way to make them easy to read and fast to
grasp for those who maintain the code.

If a maintenance programmer does not understand enough English to be
able to easily cope with ASCII-only identifiers, he will have a problem
anyway, since it will be very hard to use the standard library, the
documentation, and so on.

--
René

[Aldo Cortesi]

Thus spake Steven D'Aprano (st****@REMOVE.THIS.cybersource.com.au):

Me, I try to understand a patch by reading it. Call me old-fashioned.

I concur, Aldo. Indeed, if I _can't_ be sure I understand a patch, I
don't accept it -- I ask the submitter to make it clearer.

Yes, but there is a huge gulf between what Aldo originally said he does
("visual inspection") and *reading and understanding the code*.

Let's set aside the fact that you're guilty of sloppy quoting here, since the
phrase "visual inspection" is yours, not mine. Regardless, your interpretation
of my words is just plain dumb. My phrasing was intended to draw attention to
the fact that one needs to READ code in order to understand it. You know - with
one's eyes. VISUALLY. And VISUAL INSPECTION of code becomes unreliable if this
PEP passes.

If I've understood Martin's post, the PEP states that identifiers are
converted to normal form. If two identifiers look the same, they will be the
same.

I'm sorry to have to tell you, but you understood Martin's post no better than
you did mine. There is no general way to detect homoglyphs and "convert them to
a normal form". Observe:

import unicodedata
print repr(unicodedata.normalize("NFC", u"\u2160"))
print u"\u2160"
print "I"
So, a round 0 for reading comprehension this lesson, I'm afraid. Better luck
next time.


Regards,


Aldo


--
Aldo Cortesi
al**@nullcube.com
http://www.nullcube.com
Mob: [phone]

[HYRY]

- should non-ASCII identifiers be supported? why?
Yes. I want this for years. I am Chinese, and teaching some 12 years
old children learning programming. The biggest problem is we cannot
use Chinese words for the identifiers. As the program source becomes
longer, they always lost their thought about the program logic.

English keywords and libraries is not the problem, because we only use
about 30 - 50 of these words for teaching programming idea. They can
remember these words in one week. But for the name of variable or
function, it is difficult to remember all the English word. For
example, when we are doing numbers, maybe these words: [odd, even,
prime, minus ...], when we are programming for drawing: [line, circle,
pixel, ...], when it's for GUI: [ button, event, menu...]. There are
so many words that they cannot just remeber and use these words to
explain there idea.

Eventlly, when these children go to high school and study enough
English, I think they can use English words for programming. But as
the beginning step, it is difficult to learn both programming and
English.

So, I made a little program, just replace all the Chinese words in the
program to some sequency identifiers such as [a1, a2, a3, ...], So we
can do programming in Chinese, and Python can still run it.

If non-ASCII identifiers becomes true, I think it will be the best
gift for Children who donot know English.

[Stefan Behnel]

René Fleschenberg wrote:

you have failed to do that, in my opinion. All you have presented are
vague notions of rare and isolated use-cases.

I don't think software development at one of the biggest banks in Germany can
be considered a "rare and isolated use case".

Admittedly, it's done in Java, but why should Python fail to support unicode
identifiers in the way Java does?

Stefan

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Stefan Behnel schrieb:

My personal take on this is: search-and-replace is easier if you used well
chosen identifiers. Which is easier if you used your native language for them,
which in turn is easier if you can use the proper spellings.

I strongly disagree with this. My native language is German, and I do
*not* find it easier to find well chosen identifiers using German. Not
at all. Quite the opposite.

Programming is such an English-dominated culture that I even "think" in
English about it. When I want to explain something related to Computers
to German "non-techies", I often have to think about an appropriate
German word for what I have in mind first. Using the familiar English
term would be alot easier.

My experience is: If you know so little "technical" English that you
cannot come up with well chosen English identifiers, you need to learn
it. If you don't, you will not be able to write decent programs anyway.
All the keywords are in English, all of the standard library is in
English, most of the documentation is only available in English, almost
all third party modules' interfaces are in English.

Any program that uses non-English identifiers in Python is bound to
become gibberish, since it *will* be cluttered with English identifiers
all over the place anyway, wether you like it or not.

The point is: Supporting non-ASCII identifiers does *not* allow people
to write programs "using their native natural language". For that, you
would also have to translate the standard library and so on.

meincsv = csv.reader(open("meinedatei.csv"))
for zeile in meincsv:
for eintrag in zeile:
print eintrag.upper()

Even in that little trivial code snippet, you need to understand stuff
like "reader", "open", "for", "in", "print" and "upper". Mixing in the
German identifiers is both ugly and unnecessary.

For example, how many German names for a counter variable could you come up
with? Or english names for a function that does domain specific stuff and that
was specified in your native language using natively named concepts? Are you
sure you always know the correct english translations?

I don't need to know the perfect English translation, just one that is
understood by anyone who knows enough "Programming English", which is
just about any programmer in the world.

--
René

[Marco Colombo]

On 13 Mag, 17:44, "Martin v. Löwis" <[e-mail]:

- should non-ASCII identifiers be supported? why?

Yes. For the same reason non-ASCII source files are supported.

- would you use them if it was possible to do so? in what cases?

Yes. In the same cases I'd use:
1) non-English comments;
2) non-English string literals;
3) a source file that is already non-ASCII.

Not that I usually do that. I speak Italian natively, but write
programs with English identifiers, English comments, English output
most of the time and usually the encoding is ASCII. Yet we support
other encoding for the source file, that is non-ASCII comments,
literals, and so on. And non-ASCII means non-English.

There may be very few reasons to use non-ASCII, non-English words in a
python program, _anywhere_, but that's not the issue. We already
support people writing program with, say, Italian comments, Italian
words in string literals (natively utf-8 encoded, not with escape
sequences), no matter if they are right or wrong doing so. The
following is a valid source file:

# coding=utf-8
# stampa il nome della città
citta = "Milano"
print "Città:", citta

We support people doing that. While we're at it, why not support this
one as well:

# coding=utf-8
# stampa il nome della città
città = "Milano"
print "Città:", città

(for people unable to see it: there's a "LATIN SMALL LETTER A WITH
GRAVE" at the end of "citta" instead of a plain "LATIN SMALL LETTER A"
- in the second program, that's true for the identifier as well).

Question is: if we support the former (right or wrong, we do), what do
we loose in supporting the latter? Most arguments against this PEP I
saw here apply to both programs, I'd like to see one that applies only
to the second one.

..TM.

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Steven D'Aprano schrieb:

>

>A Python
project that uses Urdu identifiers throughout is just as useless
to me, from a code-exchange point of view, as one written in Perl.

That's because you can't read it, not because it uses Unicode. It could
be written entirely in ASCII, and still be unreadable and impossible to
understand.

That is a reason to actively encourage people to write their code in
English whereever possible, not one to allow non-ASCII identifiers,
which might even do the opposite.

> - Unicode is harder to work with than ASCII in ways that are more
important
in code than in human-language text. Humans eyes don't care if two
visually indistinguishable characters are used interchangeably.
Interpreters do. There is no doubt that people will accidentally
introduce mistakes into their code because of this.

That's no different from typos in ASCII. There's no doubt that we'll give
the same answer we've always given for this problem: unit tests, pylint
and pychecker.

Maybe it is no different (actually, I think it is: With ASCII, at least
my terminal font can display all the identifiers in a traceback), but
why do you want to create *more* possibilities to do mistakes?

--
René

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Stefan Behnel schrieb:

"go to" is not meant for clarity, nor does it encourage code readability.

Some people would argue that position.

But that's what this PEP is about.

IMHO, this PEP does not encourage clarity and readability, it
discourages it. Identifiers which my terminal cannot even display surely
are not very readable.

--
René

[Stefan Behnel]

René Fleschenberg wrote:

Programming is such an English-dominated culture that I even "think" in
English about it.

That's sad.

My experience is: If you know so little "technical" English that you
cannot come up with well chosen English identifiers, you need to learn
it.

:) This is not about "technical" English, this is about domain specific
English. How big is your knowledge about, say, biological terms or banking
terms in English? Would you say you're capable of modelling an application
from the domain of biology, well specified in a large German document, in
perfect English terms?

And: why would you want to do that?

Stefan

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Stefan Behnel schrieb:

Sounds like high time for an editor that supports the project team in their
work, don't you think?

I think your argument about "isolated projects" is flawed. It is not at
all unusual for code that was never intended to be public, whose authors
would have sworn that it will never ever be need to read by anyone
except themselves, to surprisingly go public at some point in the future.

Moreover, wether it uses ASCII-only identifiers or not might actually be
a factor in deciding wether it can then become useful for the community
as a whole or not.

If only some few projects that are so very very isolated from the rest
of the world profit from the change this PEP proposes, then it should
IMHO be feasible to require them to use a special Python branch. That
would keep the burden of all the possible problems away from the rest of
the Python community.

--
René

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Stefan Behnel schrieb:

René Fleschenberg wrote:

>you have failed to do that, in my opinion. All you have presented are
vague notions of rare and isolated use-cases.

I don't think software development at one of the biggest banks in Germany can
be considered a "rare and isolated use case".

And that software development at that bank is not done in Python because
Python does not support non-ASCII identifiers? Can you provide a source
for that?

Admittedly, it's done in Java, but why should Python fail to support unicode
identifiers in the way Java does?

Your example does not prove much. The fact that some people use
non-ASCII identifiers when they can does not at all prove that it would
be a serious problem for them if they could not.

--
René

[Stefan Behnel]

René Fleschenberg wrote:

Stefan Behnel schrieb:

>René Fleschenberg wrote:

>>you have failed to do that, in my opinion. All you have presented are
vague notions of rare and isolated use-cases.

I don't think software development at one of the biggest banks in Germany can
be considered a "rare and isolated use case".

And that software development at that bank is not done in Python because
Python does not support non-ASCII identifiers? Can you provide a source
for that?

>Admittedly, it's done in Java, but why should Python fail to support unicode
identifiers in the way Java does?

Your example does not prove much. The fact that some people use
non-ASCII identifiers when they can does not at all prove that it would
be a serious problem for them if they could not.

Are we trying to prove that?

And, would we have serious problems and people running from Python if Python
2.5 did not integrate the "with" statement?

Stefan

[Stefan Behnel]

René Fleschenberg wrote:

Stefan Behnel schrieb:

>Sounds like high time for an editor that supports the project team in their
work, don't you think?

I think your argument about "isolated projects" is flawed. It is not at
all unusual for code that was never intended to be public, whose authors
would have sworn that it will never ever be need to read by anyone
except themselves, to surprisingly go public at some point in the future.

Ok, but how is "using non-ASCII identifiers" different from "using mandarin
tranliterated ASCII identifiers" in that case?

Please try to understand what the point of this PEP is.

Stefan

[Thorsten Kampe]

* Eric Brunel (Tue, 15 May 2007 11:51:20 +0200)

On Tue, 15 May 2007 11:25:50 +0200, Thorsten Kampe
<th******@thorstenkampe.dewrote:

* Eric Brunel (Tue, 15 May 2007 10:52:21 +0200)

On Tue, 15 May 2007 09:38:38 +0200, Duncan Booth
<du**********@invalid.invalidwrote:
Recently there has been quite a bit of publicity about the One Laptop
Per
Child project. The XO laptop is just beginning rollout to children and
provides two main programming environments: Squeak and Python. It is
an
exciting thought that that soon there will be millions of children in
countries such as Nigeria, Brazil, Uruguay or Nepal[*] who have the
potential to learn to program, but tragic if the Python community is
too
arrogant to consider it acceptable to use anything but English and
ASCII.

You could say the same about Python standard library and keywords then.

You're mixing apples and peaches: identifiers (variable names) are
part of the user interface for the programmer and free to his
diposition.

So what? Does it mean that it's acceptable for the standard library and
keywords to be in English only, but the very same restriction on
user-defined identifiers is out of the question?

Yes.

Why? If I can use my own
language in my identifiers, why can't I write:

classe MaClasse:
définir __init__(moi_meme, maListe):
moi_meme.monDictionnaire = {}
pour i dans maListe:
moi_meme.monDictionnaire[i] = Rien

For a French-speaking person, this is far more readable than:

Because keywords are not meant meant to extended or manipulated or
something similar by the programmers. Keywords are well known and only
a limited set of words. That's why you can't use keywords as
identifiers.

On the contrary identifiers are for the user's disposition. The
convention for naming them is: give them the name that makes the most
sense in relation to the code. In a lot of cases this will mean
english names and ASCII charset. And in some restricted environments
this means naming identifiers with terms from the native language. And
in this case it makes no sense at all to restrict these people to use
ASCII characters to write words in their own language.

There really is no difference to allow strings or comments in non-
english languages and non-ASCII characters.

Thorsten

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Stefan Behnel schrieb:

René Fleschenberg wrote:

>Programming is such an English-dominated culture that I even "think" in
English about it.

That's sad.

I don't think so. It enables me to communicate about that topic with a
very broad range of other people, which is A Good Thing.

>My experience is: If you know so little "technical" English that you
cannot come up with well chosen English identifiers, you need to learn
it.

:) This is not about "technical" English, this is about domain specific
English. How big is your knowledge about, say, biological terms or banking
terms in English? Would you say you're capable of modelling an application
from the domain of biology, well specified in a large German document, in
perfect English terms?

As I have said, I don't need to be able to do that (model the
application in perfect English terms). It is better to model it in
non-perfect English terms than to model it in perfect German terms. Yes,
I do sometimes use a dictionary to look up the correct English term for
a domain-specific German word when programming. It is rarely necessary,
but when it is, I usually prefer to take that effort over writing a
mixture of German and English.

And: why would you want to do that?

1) To get the broadest possible range of coworkers and maintenance
programmers.

2) To be consistent. The code is more beautiful if it does not
continously jump from one language to another. And the only way to
achieve that is to write it all in English, since the standard library
and alot of other stuff is in English.

--
René

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Stefan Behnel schrieb:

>>Admittedly, it's done in Java, but why should Python fail to support unicode
identifiers in the way Java does?

Your example does not prove much. The fact that some people use
non-ASCII identifiers when they can does not at all prove that it would
be a serious problem for them if they could not.

Are we trying to prove that?

IMO, if you cannot prove it, the PEP should be rejected, since that
would mean it introduces new problems without any proven substantial
benefits.

And, would we have serious problems and people running from Python if Python
2.5 did not integrate the "with" statement?

1) Which additional potential for bugs and which hindrances for
code-sharing do you see with the with-statement?

2) The with-statement does have proven substantial benefits, IMO.

--
René

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Thorsten Kampe schrieb:

Because keywords are not meant meant to extended or manipulated or
something similar by the programmers. Keywords are well known and only
a limited set of words. That's why you can't use keywords as
identifiers.

This is true for keywords, but not for the stdlib. Are you suggesting
that the stdlib should be "internationalized"?

There really is no difference to allow strings or comments in non-
english languages and non-ASCII characters.

Comments in a non-English language are a bad idea. And of course there
is a difference between strings (data) and identifiers (program logic).

--
René

[Stefan Behnel]

René Fleschenberg wrote:

Stefan Behnel schrieb:

>>>Admittedly, it's done in Java, but why should Python fail to support unicode
identifiers in the way Java does?
Your example does not prove much. The fact that some people use
non-ASCII identifiers when they can does not at all prove that it would
be a serious problem for them if they could not.

Are we trying to prove that?

IMO, if you cannot prove it, the PEP should be rejected, since that
would mean it introduces new problems without any proven substantial
benefits.

>And, would we have serious problems and people running from Python if Python
2.5 did not integrate the "with" statement?

1) Which additional potential for bugs and which hindrances for
code-sharing do you see with the with-statement?

I'm not sufficiently used to it to understand it immediately when I read it.
So I would have to look deeper into patches that use it, for example, and
couldn't accept them at first look. Plus, some editors do not highlight it as
a Python keyword. So it should have been rejected.

2) The with-statement does have proven substantial benefits, IMO.

Not to me. I don't use it, so no-one should. And since it does not make sense
in public projects, it should also be forbidden in in-house projects.

Stefan

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Stefan Behnel schrieb:

>I think your argument about "isolated projects" is flawed. It is not at
all unusual for code that was never intended to be public, whose authors
would have sworn that it will never ever be need to read by anyone
except themselves, to surprisingly go public at some point in the future.

Ok, but how is "using non-ASCII identifiers" different from "using mandarin
tranliterated ASCII identifiers" in that case?

1) Transliterated ASCII identifiers do not have problems such as not
displaying at all and not being easily possible to type.

2) I consider transliterated ASCII identifiers a bad idea, but it is
virtually impossible to prohibit them at the language level.

Please try to understand what the point of this PEP is.

Please try to understand that the fact that certain bad practices are
possible today is no valid argument for introducing support for more of
them!

--
René

[Thorsten Kampe]

* René Fleschenberg (Tue, 15 May 2007 13:17:13 +0200)

Steven D'Aprano schrieb:

A Python
project that uses Urdu identifiers throughout is just as useless
to me, from a code-exchange point of view, as one written in Perl.

That's because you can't read it, not because it uses Unicode. It could
be written entirely in ASCII, and still be unreadable and impossible to
understand.

That is a reason to actively encourage people to write their code in
English whereever possible, not one to allow non-ASCII identifiers,
which might even do the opposite.

There is no reason to encourage or discourage people in which language
to write their code. Code that's meant to be shared makes just a tiny
percentage of all the code written right this moment.

This "ready to be shared" code is neither better nor worse than
"closed" german or chinese-only code.

[Thorsten Kampe]

* René Fleschenberg (Tue, 15 May 2007 13:21:10 +0200)

Stefan Behnel schrieb:

"go to" is not meant for clarity, nor does it encourage code readability.

Some people would argue that position.

But that's what this PEP is about.

IMHO, this PEP does not encourage clarity and readability, it
discourages it.

Identifiers which my terminal cannot even display surely
are not very readable.

This PEP is not about you. It's about people who write in their native
language and who are forced to use a dodgy transcription from
characters of their own language to ASCII.

[Stefan Behnel]

René Fleschenberg wrote:

Please try to understand that the fact that certain bad practices are
possible today is no valid argument for introducing support for more of
them!

You're not trying to suggest that writing code in a closed area project is a
bad habit, are you?

What would be bad about allowing a project to decide about the best and
clearest way to name identifiers? And: if it's not a project you will ever get
in touch with - what do you care?

Stefan

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Stefan Behnel schrieb:

>1) Which additional potential for bugs and which hindrances for
code-sharing do you see with the with-statement?

I'm not sufficiently used to it to understand it immediately when I read it.

http://www.python.org/dev/peps/pep-0343/
It is not that hard to grasp.

So I would have to look deeper into patches that use it, for example, and
couldn't accept them at first look. Plus, some editors do not highlight it as
a Python keyword. So it should have been rejected.

Support for highlighting that is easily added, contrary to support for
displaying all possible Unicode glyphs, let alone typing them in easily.

>2) The with-statement does have proven substantial benefits, IMO.

Not to me. I don't use it, so no-one should.

Now you are starting to troll?

And since it does not make sense
in public projects, it should also be forbidden in in-house projects.

It does make alot of sense in public projects, since it actually *does*
make the code clearer. A programmer who does not understand it at first
can easily find and understand its documentation. The same is *not* true
for things like Kanji glyphs and the like.

--
René

[=?UTF-8?B?UmVuw6kgRmxlc2NoZW5iZXJn?=]

Thorsten Kampe schrieb:

>Identifiers which my terminal cannot even display surely
are not very readable.

This PEP is not about you. It's about people who write in their native
language and who are forced to use a dodgy transcription from
characters of their own language to ASCII.

It is impossible to write Python in a native language other than English
even with the implementation of this PEP. All you get is a weird mixture
of English identifiers from various libraries and identifiers in your
native language. And even if you consider that more clear and readable
than English-only Python code, the fact that it discourages code sharing
remains.

--
René

[Stefan Behnel]

René Fleschenberg wrote:

Now you are starting to troll?

Sorry, I was omitting the signs of sarcasm as I thought that would be clear
from the previous posts in this thread (which I was citing).

Feel free to re-read my post.

Stefan

[Thorsten Kampe]

* René Fleschenberg (Tue, 15 May 2007 14:04:07 +0200)

Thorsten Kampe schrieb:

Because keywords are not meant meant to extended or manipulated or
something similar by the programmers. Keywords are well known and only
a limited set of words. That's why you can't use keywords as
identifiers.

This is true for keywords, but not for the stdlib. Are you suggesting
that the stdlib should be "internationalized"?

No, because it's the /Standard/ Library to be used by everyone. And
the lowest common denominator is ASCII and English.

There really is no difference to allow strings or comments in non-
english languages and non-ASCII characters.

Comments in a non-English language are a bad idea.

No, they're not. It depends on the purpose of the code. For a lot of
projects comments in English might be a bad idea.

And of course there is a difference between strings (data) and
identifiers (program logic).

It's not about identifiers but about identifiers' names. Identifiers'
names are a kind of API where the programmers "plug in" their own
individuality or nationality. Just like string data and comments.
You're not supposed to understand nor read nor even display this code.
If you are then it's the programmer's responsibility to enable you to
do so.