[Python-Dev] PEP 8 updates/clarifications

[François Pinard]

[Guido van Rossum]

>In a module where you import 'foo' I don't understand why you would
>name a local variable 'foo'. So I'm not sure how the conflict would
>arise.

It goes the other way around.  First suppose, following an example in 
a previous message, that I have a lot of variables named 'text', as this 
is kind of the default name everywhere for the text being handled in 
a function, in a program handling text.

Now, let's presume that Python adds a new standard module named 'text', 
containing many things that interest me, enough that I would want to 
import the whole module globally in that program.  The module would be 
shadowed at many places, and whenever I'll have to use it, I'll have to 
make some stunts, like changing the local 'text' here and there for 
unshadowing the global module, or importing it the global module under 
a different name.  In the first case, I have inconsistent naming.  In 
the second case, I impose an indirection in the understanding to whoever 
will maintain my program after me.  In any case, it looks messed up.

Now, I'm sure I'm not alone, as a programmer, having plenty of habits
or own conventions.  What I do in a program, I'm likely doing in many 
others.  Seeing a module name added in the standard Python library with 
a name that I already much use usually means that I have no choice than 
to give up on my own choices, because Python will not change his (:-), 
and I ought to do tons of changes on my side so programs stay clean in 
the long run, and do not finish looking like the remains of battle 
field.

'text' is a particularly good example for me, because when I started 
using Python 1.5.2 after having done a lot of C and Perl, I already had 
the strong habit of using 'string' everywhere for the string under 
consideration, and had to change this particular habit so the 'string' 
module would be available.  This is why I started to use 'text' 
everywhere, and would not like changing conventions again.

Let's consider how people name variables.  Some people write programs 
like they do algebra and stick with one letter variables, merely one of 
those habits directly or indirectly inherited from FORTRAN (FORmula 
TRANslator).  These people like using `k' for counters, and `s' for 
string or socket, depending on context.  They either want to spare 
either the memory required to store the full identifier, or more 
probably, their own keystrokes within their editor, unaware of the 
modern un-abbreviating facilities. :-)  A second set of programmers (I'm 
in this set) prefer identifiers written as natural language words fully 
written -- my counters are written `counter', and cursors are written 
`cursor' --, or agglomeration of a few words tied with underlines.  The 
remainder of programmers might do clever things like using neologisms 
('textwrap' is an example of those), or much, much less clever things 
like making their identifiers by random removal of letters from words --
vowels often being the first to go --.  By random, I mean that it 
constantly and gratuitously strains the memory of people later having to 
read their code.

No standard Python module name uses single-letter algebraic-style names, 
thanks God, so the FORTRANic programmers are already protected.  I would 
like if module naming convention was extending its protective wing over 
the second set of programmers (the set I'm in, of course!).  Programmers 
not being in the first two sets do not require so much protection: for 
the clever ones, because the probability of clashes between neologisms 
is much smaller than the probability of clashes with usual natural 
language words; for the randomising programmers, well, because they do 
not deserve being protected :-).

-- 
François Pinard   http://pinard.progiciels-bpi.ca