PEP 3131: Supporting Non-ASCII Identifiers

[Guest]

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).

 

[Stefan Behnel]

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


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

 

[Guest]

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!

 

[Thorsten Kampe]

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

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)

Some people would argue that position.


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]

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

 

[Guest]

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.

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.

 

[Guest]

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.

 

[Stefan Behnel]

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)

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.

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.

 

[Guest]

There is no reason to encourage or discourage people in which language
to write their code.

There is, because code sharing is generally a good thing. If you don't
think it is, then we'll just have to agree to disagree on that point.

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.

The implementaton of this PEP would not make Chinese-only Python code
possible. It would only make a Chinese-English gibberish without ASCII
transliteration possible. Also, alot of code that starts out as "closed"
and not meant to be shared is shared at some point (this is how we got
Zope, AFAIK), and this is a thing that should be encouraged.

 

[Stefan Behnel]

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.

The difference is: keywords and the standard library are
a) limited
b) public
c) domain specific in the Python world or the respective module domain
d) chosen according to Python stdlib guidelines (more or less)

Identifiers are
a) unlimited
b) domain specific to a project domain
c) chosen according to project guidelines

And even if you consider that more clear and readable
than English-only Python code, the fact that it discourages code sharing
remains.

So? Is that bad? Can't OpenSource and closed source happily live together?

Stefan

 

[Thorsten Kampe]

* René Fleschenberg (Tue, 15 May 2007 14:19:46 +0200)

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.

You have a few English keywords that are not meant to be understood
but can be learned.

And even if you consider that more clear and readable
than English-only Python code, the fact that it discourages code sharing
remains.

It neither encourages or discourages anything. And I don't think
encouraring or discouraging code sharing is a good thing. There is
simply no general reason to do so.

 

[Guest]

You have a few English keywords that are not meant to be understood
but can be learned.

I am talking about the stdlib, not about the very few keywords Python
has. Are you going to re-write the standard library in your native
language so you can have a consistent use of natural language among your
code?

It neither encourages or discourages anything. And I don't think
encouraring or discouraging code sharing is a good thing. There is
simply no general reason to do so.

I disagree, but since that is a question of ideology, it makes little
sense to argue about it.

 

[Thorsten Kampe]

* René Fleschenberg (Tue, 15 May 2007 14:27:26 +0200)

There is, because code sharing is generally a good thing. If you don't
think it is, then we'll just have to agree to disagree on that point.

Just by repeating yourself you don't make your point more valid. Code
sharing makes as much sense as book or car sharing. There a lots of
projects where sharing code would be just nonsense. This code would be
no use to anyone.

 

[Thorsten Kampe]

* René Fleschenberg (Tue, 15 May 2007 14:35:33 +0200)

I am talking about the stdlib, not about the very few keywords Python
has. Are you going to re-write the standard library in your native
language so you can have a consistent use of natural language among your
code?

Why would I want to do that? It's not my code. Identifier names are
mine. If I use modules from standard library I use some "foreign
words". There's no problem in that.

 

[Anton Vredegoor]

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.

That is probably because they are just entering the developmental phase
of being able to use formal operational reasoning. I can understand that
they are looking for something to put the blame on but it is an error to
give in to the idea that it is hard for 12 year olds to learn a foreign
language. You realize that children learn new languages a lot faster
than adults?

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.

Again, it's probably not the language but the formal logic they have
problems with. Please do *not* conclude that some child is not very good
at math or logic or programming when they are slow at first. It doesn't
tell one very much how good they might become later on and some
premature idea the teacher might have formed about a pupil in that phase
can even be harmful for their later perspectives.

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.

The older they get the harder it is for them to learn language. By
withholding them English language experience at an early age you are
doing them a disservice because later on they will have more trouble.

The other thing is trying to teach them formal operational logic when
they are not yet ready for it. In that case it would be better to wait
until they are ready, but unfortunately there are large variations in
the age at which children become ready. Please do not confuse the two
very different matters of language acquisition and formal operational
logic. Language is learned at an early age while formal logic starts at
about the age of eleven (but with very large variation among children).

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.

Why not use IronPython? But anyway you are actually making things worse
by *not* teaching them the language now that they will need later on and
by *teaching* them formal operational logic at an age when they just get
disappointed and frustrated by not yet being able to understand it.
Better go easy on them and teach them lots of English computing terms
and only introduce logic when they show they are ready.

A.

 

[Eric Brunel]

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

In the world we live in today, a "closed area project" is something that
tends to disappear. One never knows if the code can be made public
someday, or be outsourced to a country with a different language and
default encoding.

(Now that I think of it, this *is* a valid reason to accept this PEP:
"Sorry, boss, but we can't possibly fire all our development team and
outsource the project to Russia: all the identifiers are in French and
they won't be able to make any sense of it" ;-) )

 

[Guest]

Just by repeating yourself you don't make your point more valid.

You are doing just the same. Your argument that encouraging code-sharing
is not a worthwhile goal is an ideologic one, just as the opposite
argument is, too (I do think that code sharing is very different from
sharing of material goods). That is why I do not think it makes alot of
sense to argue about it. If you don't consider code sharing to be a
value of its own, then that is of course also not an argument against
this PEP. I just happen to have different beliefs.

 

[Stefan Behnel]

The older they get the harder it is for them to learn language. By
withholding them English language experience at an early age you are
doing them a disservice because later on they will have more trouble.

What does "withholding" mean here? Remember: we're talking about foreign
language identifiers here, not about foreign literature.

I don't think all identifiers in the stdlib are
a) well chosen
b) correct English words

So: what can you learn from ASCII identifiers that will honestly help you with
the english language in your later life?

This kind of argument is just plain off-topic.

Stefan