[Edu-sig] Musings on PEP8

[Vernon Cole]

> From: kirby urner <kirby.urner at gmail.com>
> To: edu-sig at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20110718/d2913699/attachment.html>