Default indentation of 4 columns

François Pinard pinard at IRO.UMontreal.CA
Mon Oct 25 01:08:17 EDT 1999


"Tim Peters" <tim_one at email.msn.com> écrit:

>     Keyword arguments:
>     real -- the real part (default 0.0)
>     imag -- the imaginary part (default 0.0)

> That's certainly clear!

Yes, of course, when this is what you want to say.  But if you want to
write running prose in which you explain the relation between variables,
the tabular form does not apply very well.  No doubt that one might make
stunts to fit a description into tables, the same as I could have turned
this paragraph I'm writing into some kind of itemized list, if I really
had no choice but to do so.  Yet, you will most probably agree with me
that prose is better than tables for many purposes, and being forced into
tables is rather artificial.

> >     for file_name, line_number, function_name, python_text in frames:
> >         if (function_name[0] not in ('_', '<')
> >             and function_name not in transparent_functions):
> >             name = os.path.basename(file_name)
> >             if name not in transparent_files:
> >                 return name, line_number

> <GUIDOQUOTE screaming_added_by="tim">
> [...] Emacs Python-mode does this right. [...]

The above was indeed indented by Emacs Python-mode.

> Some examples:

>         if width == 0 and height == 0 and \
>            color == 'red' and emphasis == 'strong' or \
>            highlight > 100:
>             raise ValueError, "sorry, you lose"

Yet, you just quoted:

> The preferred way of wrapping long lines is by using Python's implied line
> continuation inside parentheses, brackets and braces.  If necessary, you
> can add an extra pair of parentheses around an expression, but sometimes
> using a backslash looks better.

So, it seems here that backslashes look better, and that the preferred way
does not really apply above.  Since `if' is a rather frequent statement,
I'm not sure what to think. :-)

> But easier to remember that readability is the goal.

Indeed.  INDENT/DEDENT considerations, or explanations about Python logical
construction of single lines from physical lines, are a bit extraneous!

>     for file_name, line_number, function_name, python_text in frames:
>         if (function_name[0] not in ('_', '<') and
>                 function_name not in transparent_functions):
>             name = os.path.basename(file_name)
>             ...
>     [and other examples]

Of course, they all look better, yet these imply fighting or defeating
Emacs mode to some extent.

> It's sheer coincidence in your example that the first non-whitespace
> character following the open paren was 4 columns to the right of the
> 'i' in "if", and I agree it doesn't read well.  So hit the spacebar a
> few times -- pymode won't hit you!

Somewhere else, Guido insists that we should not use extraneous whitespace
for lining up things (assignments given as examples), somewhat suggesting
that we should keep the spacing simple, and not invent spaces just for
the sake of building an overall look.  As I see it, there is some peeking
inconsistencies in these suggestions, which are sometimes strongly formulated
We could surely make religious debates trying to explain everything (we say
"exégèse" in French for that science which interprets religious texts :-).
My overall feeling is that the guide is not fully satisfactory as it stands.

This being said, we are surely free to do well, as you examplify many
times in your reply.  Yet, this weakens the Python style guide.  I used to
follow GNU standards for C code rather strictly, and the result was quite
acceptable all along (once accepted the position of braces, of course, as
some people just cannot stand them, Linus being one well known example).
We just have no choice than be more loose with the Python guide, and it's
a bit sad for utter Piagetian-anal guys like me! :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard




More information about the Python-list mailing list