Python style guidelines

[MetalOne]

I do not like style guidelines either.  If one method can be factually
proven better than another method, then it would make sense to
encourage the better method.  However, when this can't be done, then
the guideline is simply based upon taste or gut instinct or personal
preference.  These all vary from person to person and who is to say
what is correct.

During my schooling I was taught to always place statements on their
own line.
x = 0
y = 0
z = 0

I accepted this completely without thinking about it much.
20 years later I have finally come to realize that if (x,y,z)
represents a point that
x = y = z = 0    or
(x,y,z) = (0,0,0)
is not always so bad.  It conserves lines of code, and being able to
see more lines of code at one time is beneficial.

Some guidelines recommend functions with only a single return point. 
I don't understand why this insanity got started.  At one point it was
recognized that multiple entry points into a function was confusing,
but why did it have to get extrapolated to multiple exit points.  Upon
entry to a function, I sometimes like to verify that everything is ok
before proceeding and if it is not just get out.  Parameters can
validated, resources acquired, or whatever.

At my work we currently have a guideline to always use brackets in
"if" statements.
if
{
    single statement
}
else
{
    single statement
}

Simply on the basis that somebody might forget the braces when adding
another statement to the block.  Has this ever actually happened? 
What about actually testing the code?  It is not too onerous of a
guideline, but it does increase lines of code, which affects the
ability to easily see more code, which affects overall readability in
some cases.

Even the usual guideline of placing statements on separate lines I
think is sometimes a mistake.
if cond: statement
elif cond: statement
else: statement

does not always seem too bad to me where you always just have a single
statement.

Somebody once convinced me that I should always use descriptive
unabreviated variable names.  At first this advice seemed a little
strange to me.  Most code that I had ever encountered abreviated
variable names.  Vowels tend to be left out.  I think it might be a
FORTRAN hold over where variables had to be 6 characters or less or
was it 8.  After a while, I realized people do things like
cnt, instead of count. sz instead of size. tmr instead of timer.  I
finally agree that long unabbreviated names are better.  Years later,
I realize that expressions can be hard to read with long variable
names.  It occurs to me that mathematics always use one character
variables like x,y,z or the greek symbols.  Expressions are just
easier to read.  You can simply comment what 'x' means.  So variable
length is not always so simple to decide upon.

And so it goes.  I guess I am a believer in TIMTOWTDI.

The other thing about guidelines is that once somebody publishes a
book with guidelines, lookout.  Your employer may soon have you
following them all whether you agree with them or not.  Rational Rose
and UML are great examples of this, but that is another story.