> From: kirby urner <kirby.urner@gmail.com>
> To: edu-sig@python.org
>
> I find myself thinking about PEP8 a lot, not that I have it memorized.
>
> Now that Unicode reigns at the top-level, we've got an influx of
> Chinese namespaces, Hindi namespaces, Cyrillic namespaces...
> a nice long list, and the PEP8 conventions regarding capitalization,
> while sensible in Latin-1, might not cover the new cases [...]
Remember that PEP 8 is a guideline, not a requirement, and that it is documented as:
"This document gives coding conventions for the Python code comprising the standard library in the main Python distribution. "
Any programmer may choose any style she prefers for her own use. If she is writing modules for the standard library -- and expects to have them accepted by the community -- then she will follow PEP 8.
> The inter-readability of Latin-1 means lots of headaches removed,
> like at least *something* positive came out of that Roman period [...]
Yes, having taken a contract to maintain code where the author wrote his comments in Romanized Ukrainian, I have a great respect for non-English-native authors who take the time to learn English well. It is a terrible language to have to learn, I am told, but is the only one _all_ software engineers can be expected to know.
Also PEP 8 states that: "Latin-1 (or
UTF-8) should only be used when a comment or docstring needs to
mention an author name that requires Latin-1; otherwise, using
\x, \u or \U escapes is the preferred way to include non-ASCII
data in string literals."
Even then, I would hope that an author would include an Anglicized version of his name, so that I can recognize it when I see it again. The only alphabets I personally can read are Latin, Cyrillic, Hebrew, and Greek. If your name is in Cherokee, then please put (John Standing Bear) in ASCII along side it.
There is a very good reason for this: standard library code must be readable for people all over the world. That's why a Dutch software engineer wrote a language in which all the keywords and commentary are in English.
>
> The flip side argument, which I find more persuasive, is that
> one of the biggest barriers to diversity is over-reliance on Latin-1,
> and "just ASCII" in particular.
>
> The whole point of Unicode was to open up source code writing,
> as an occupation, to more than just Euro-English speakers.
I disagree. The whole point of Unicode is to open up application writing, so that _users_ can see computer output in their own languages. A person who wishes to pursue code writing as an occupation must understand and use English -- or be relegated to producing work only for his own culture. In the modern "flat" world, English is the language of commerce and computer programming. Not being able to write understandable English is a severe handicap. My programs are written in Python, documented in English, and usable by persons of another language. For example, see CaesarCalc.py from https://launchpad.net/romanclass , which assumes the user to be able to understand pigeon Latin. Even then, I give the result of (XVI - XVI) as "Nulla" because I expect that most users will not recognize "Nvlla" as meaning "nothing."
Here is sample output. Notice that, when it blows up the traceback is in Python with English explanations:
<console dump>
procer numerus hic:III - II
I
procer numerus hic:3 - 2
I
procer numerus hic:3 - 3
Nulla
procer numerus hic:2 - 3
Traceback (most recent call last):
File "CaesarCalc.py", line 40, in <module>
print (cvt(subtrahends[0]) - cvt(subtrahends[1]))
File "/home/vernon/romanclass-1.0.1/romanclass.py", line 99, in __sub__
return Roman(self.__int__() - other)
File "/home/vernon/romanclass-1.0.1/romanclass.py", line 85, in __new__
raise OutOfRangeError, 'Cannot store "%s" as Roman' % repr(N)
romanclass.OutOfRangeError: Cannot store "-1" as Roman
</console dump>
IMHO, on the whole, PEP 8 is a pretty good document.
--
Vernon