Prev: Updating path.py
Next: How to capture all the environment variables from shell?
From: Steven D'Aprano on 26 Jul 2010 19:31
On Mon, 26 Jul 2010 17:20:09 -0500, Peng Yu wrote:

> This webpage http://www.python.org/dev/peps/pep-0008/ recommends the
> following. It looks to me that both styles are fine. Could anybody let
> me know what the rationale is behind this recommendation?
>
> - Use spaces around arithmetic operators:

Because it looks better and is easier to read. Operators are small
(single characters) and sometimes need space around them to stand out.

> i=i+1

See? It's hideously ugly and cramped. It's much worse if you use larger
names:

sensiblynamedvariable=sensiblynamedvariable+1

But use your common sense. I usually group powers, multiplications and
divisions, and separate additions and subtractions:

y = 2*x + 1 - (3*x - 4/(2 + x**2))**-2

And unary + and - operators should always be grouped with their operand:

y = -2 # not "- 2"



--
Steven
From: geremy condra on 26 Jul 2010 21:55
On Mon, Jul 26, 2010 at 4:31 PM, Steven D'Aprano
<steve(a)remove-this-cybersource.com.au> wrote:
> On Mon, 26 Jul 2010 17:20:09 -0500, Peng Yu wrote:
>
>> This webpage http://www.python.org/dev/peps/pep-0008/ recommends the
>> following. It looks to me that both styles are fine. Could anybody let
>> me know what the rationale is behind this recommendation?
>>
>>     - Use spaces around arithmetic operators:
>
> Because it looks better and is easier to read. Operators are small
> (single characters) and sometimes need space around them to stand out.
>
>>           i=i+1
>
> See? It's hideously ugly and cramped. It's much worse if you use larger
> names:
>
> sensiblynamedvariable=sensiblynamedvariable+1
>
> But use your common sense. I usually group powers, multiplications and
> divisions, and separate additions and subtractions:
>
> y = 2*x + 1 - (3*x - 4/(2 + x**2))**-2
>
> And unary + and - operators should always be grouped with their operand:
>
> y = -2  # not "- 2"

This is the rule that I use, with the exception that I will generally
explicitly parenthesize the numerator in a division, since my eyes
frequently gloss over the / symbol for some reason.

Geremy Condra
From: Stephen Hansen on 26 Jul 2010 22:35
On 7/26/10 3:20 PM, Peng Yu wrote:
> This webpage http://www.python.org/dev/peps/pep-0008/ recommends the
> following. It looks to me that both styles are fine. Could anybody let
> me know what the rationale is behind this recommendation?

PEP8 is a style guide. Parts of style guides are rational judgements and
decisions based on experience and can certainly be "explained" or
justified, but parts are just... personal taste. Style is part rational
thought and part intuition, and in the latter -- people will disagree
quite a bit. There's no right or wrong there. There isn't always a
rationale.

Guido finds "x=a+1" less readable then "x = a + 1". Originally he wrote
this down with other anecdotal little tidbits up into an eassy and
posted it on the python.org website. Eventually, others decided that his
intuitive sense of style actually tended to be rather spot on for them
too (why wouldn't it, since that same sense of style brought Python into
existence and most of us quite like it), and so that guide and some
others were codified into PEP8, and tweaked from time to time.

PEP8 is only a "rule" for the stdlib, and only for new code in the
stdlib at that -- and its only really a rule to encourage consistency
and maintainability, not because its objectively The Right Way To Code.

Personally, while I agree with much of it, I disagree in several points
and ignore PEP8 whenever it suits me (most notably on line length rules,
and for a long time on methodNamingSchemes, but lately I've found I'm
coming_around).

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

From: J.B. Brown on 28 Jul 2010 03:41
I personally prefer to be slightly excessive in the amount of spacing
I used, especially when parentheses are involved.

In no way do I assert that my code style is right for all situations,
but here are a few examples of my personal style.
---
myTuple = ( 1, 2, 3, 4, 5 ) # Comment about what this tuple will
conceptually represent or store.

myTuple2 = ( 1, 2, 3*myFunc(4), 4*myFunc2( "text arg" ), ) # Yes, I
leave the tailing comma for spacing and to remind myself it is a
tuple/list.

textFieldWidth = 80 / numFields # Balance width of fields

fileObject.write( "My text goes here. Value of some function = " +
str( someFunc( argList ) ) ) # Write out results.
---
Combining my code style with the parenthesis/brace/bracket
highlighting feature of Vi/Vim makes it easy for me to figure out if I
have closed all braces, and additionally what is the context in which
I am nesting functions or arguments.

Again, this is just my preference, but it emerged over time after many
hours of development and debugging on remote machines where only a
terminal environment and a text-based editor are available.

Even in my comments, in which I _strongly_ believe in a minimum of 1
comment line per 3 code lines (1:3) though I often code 1:2 or 1:1, I
use the parenthesis style above.
Example:
# The true positive rate of an experiment is calculated as: TPR = [ TP
/ ( TP + FN ) ] .

Just food for thought.

J.B. Brown
Kyoto University
From: Lawrence D'Oliveiro on 30 Jul 2010 07:16
In message <mailman.1246.1280302904.1673.python-list(a)python.org>, J.B. Brown
wrote:

> I personally prefer to be slightly excessive in the amount of spacing
> I used, especially when parentheses are involved.
>
> myTuple = ( 1, 2, 3, 4, 5 )

Parentheses are punctuation. Why not leave spaces around the commas as well,
to be consistent?

myTuple = ( 1 , 2 , 3 , 4 , 5 )

T,FTFY.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Updating path.py
Next: How to capture all the environment variables from shell?