Idioms and Anti-Idioms Question

B

Ben Charrow

I have a question about the "Using Backslash to Continue Statements" in the
howto "Idioms and Anti-Idioms in Python"
(http://docs.python.org/howto/doanddont.html#using-backslash-to-continue-statements)


It says:

"...if the code was:

value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] \
+ calculate_number(10, 20)*forbulate(500, 360)

then it would just be subtly wrong."

What is subtly wrong about this piece of code? I can't see any bugs and can't
think of subtle gotchas (e.g. the '\' is removed or the lines become separated,
because in both cases an IndentationError would be raised).

Cheers,
Ben
 
S

Steven D'Aprano

I have a question about the "Using Backslash to Continue Statements" in
the howto "Idioms and Anti-Idioms in Python"
(http://docs.python.org/howto/doanddont.html#using-backslash-to- continue-statements)


It says:

"...if the code was:

value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] \
+ calculate_number(10, 20)*forbulate(500, 360)

then it would just be subtly wrong."

What is subtly wrong about this piece of code? I can't see any bugs and
can't think of subtle gotchas (e.g. the '\' is removed or the lines
become separated, because in both cases an IndentationError would be
raised).


As examples go, it's pretty lousy because you can't just copy and paste
it into an interpreter session and see for yourself. However, with some
helper objects:


def forbulate(*args):
return [1]

def calculate_number(*args):
return 2

class K: pass

foo = K()
foo.bar = lambda: {'first': [1, 2, 3]}
baz = K()
baz.quux = lambda *args: [3]*10

value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] \
+ calculate_number(10, 20)*forbulate(500, 360)


I can run the example. I confirm that it works without a space after the
line continuation character. Using Python 2.5, if I put a space after the
backslash I get

SyntaxError: unexpected character after line continuation character

followed by

IndentationError: unexpected indent


So I don't understand the claim that the code is "subtly wrong" either.
It looks to me like it's obviously wrong.
 
L

Lie Ryan

Ben said:
I have a question about the "Using Backslash to Continue Statements" in
the howto "Idioms and Anti-Idioms in Python"
(http://docs.python.org/howto/doanddont.html#using-backslash-to-continue-statements)


It says:

"...if the code was:

value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] \
+ calculate_number(10, 20)*forbulate(500, 360)

then it would just be subtly wrong."

What is subtly wrong about this piece of code? I can't see any bugs and
can't think of subtle gotchas (e.g. the '\' is removed or the lines
become separated, because in both cases an IndentationError would be
raised).

The preferred style is to put the binary operators before the line-break
(i.e. the line break is after the operators):

value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] + \
calculate_number(10, 20)*forbulate(500, 360)

and even more preferrable is NOT to use explicit line break at all;
relying on implicit breaking with parentheses since then you won't need
to worry about empty lines:

value = (foo.bar()['first'][0]*baz.quux(1, 2)[5:9] +
calculate_number(10, 20)*forbulate(500, 360)
)

although, in a formula that is so complex, the most preferable way is to
separate them so they won't need to take more than a single line:

a = foo.bar()['first'][0]
b = baz.quux(1, 2)[5:9]
c = calculate_number(10, 20)
d = forbulate(500, 360)
value = a*b + c*d

of course, a, b, c, d should be substituted with a more helpful names.

The following is an extract from PEP 8:

"""
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. Make sure to
indent the continued line appropriately. The preferred place to break
around a binary operator is *after* the operator, not before it.
"""
 
L

Lawrence D'Oliveiro

Lie Ryan said:
The preferred style is to put the binary operators before the line-break
...

Not by me. I prefer using a two-dimensional layout to make the expression
structure more obvious:

value = \
(
foo.bar()['first'][0] * baz.quux(1, 2)[5:9]
+
calculate_number(10, 20) * forbulate(500, 360)
)

In this case it's not necessary, but if the factors were really long, this
could become

value = \
(
foo.bar()['first'][0]
*
baz.quux(1, 2)[5:9]
+
calculate_number(10, 20)
*
forbulate(500, 360)
)
 
L

Lawrence D'Oliveiro

Wilbert said:
I' prefer:

value = (foo.bar()['first'][0] * baz.quux(1, 2)[5:9] +
calculate_number(10, 20) * forbulate(500, 360))

I prefer using a two-dimensional layout to make the expression
structure more obvious:

value = \
(
foo.bar()['first'][0] * baz.quux(1, 2)[5:9]
+
calculate_number(10, 20) * forbulate(500, 360)
)

In this case it's not necessary, but if the factors were really long, this
could become

value = \
(
foo.bar()['first'][0]
*
baz.quux(1, 2)[5:9]
+
calculate_number(10, 20)
*
forbulate(500, 360)
)
 
L

Lawrence D'Oliveiro

Damian Conway, in Perl Best Practices, puts forward a clear argument
for breaking *before* the operator:

Except in JavaScript, where you have no choice.
 
C

Carl Banks

I have a question about the "Using Backslash to Continue Statements" in the
howto "Idioms and Anti-Idioms in Python"
(http://docs.python.org/howto/doanddont.html#using-backslash-to-contin...)

It says:

"...if the code was:

value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] \
         + calculate_number(10, 20)*forbulate(500, 360)

then it would just be subtly wrong."

What is subtly wrong about this piece of code?  I can't see any bugs and can't
think of subtle gotchas (e.g. the '\' is removed or the lines become separated,
because in both cases an IndentationError would be raised).

Perhaps it was originally was like this:

value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] \
+ calculate_number(10, 20)*forbulate(500, 360)


Carl Banks
 
D

Dennis Lee Bieber

File "<stdin>", line 1
spam +
^
SyntaxError: invalid syntax

Except in actual code you are likely to get a syntax error from the
lack of matching brackets or whatever is being used to indicate
multiline continuation...
-=-=-=-=-
velveeta = 7
spam = 6
dinner = (spam

+ velveeta
-=-=-=-=-
E:\UserData\Dennis Lee Bieber\My Documents\Python Progs>junk.py
File "E:\UserData\Dennis Lee Bieber\My Documents\Python
Progs\junk.py", line 8

^
SyntaxError: invalid syntax

E:\UserData\Dennis Lee Bieber\My Documents\Python Progs>

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/
 
L

Lie Ryan

Peter said:
Ben said:
value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] \
+ calculate_number(10, 20)*forbulate(500, 360)
What is subtly wrong about this piece of code? I can't see any bugs and
can't think of subtle gotchas (e.g. the '\' is removed or the lines
become separated, because in both cases an IndentationError would be
raised).
The preferred style is to put the binary operators before the line-break
(i.e. the line break is after the operators):
value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] + \
calculate_number(10, 20)*forbulate(500, 360)
...
The following is an extract from PEP 8:
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. Make sure to
indent the continued line appropriately. The preferred place to break
around a binary operator is *after* the operator, not before it.

Damian Conway, in Perl Best Practices, puts forward a clear argument
for breaking *before* the operator:
Using an expression at the end of a statement gets too long,
it's common practice to break that expression after an operator
and then continue the expression on the following line ...
The rationale is that the operator that remains at the end
of the line acts like a continutation marker, indicating that
the expression continues on the following line.
Using the operator as a continutation marker seems like
an excellent idea, but there's a serious problem with it:
people rarely look at the right edge of code.
Most of the semantic hints in a program - such as keywords -
appear on the left side of that code. More importantly, the
structural cues for understanding code - for example, indenting, -
are predominantly on the left as well ... This means that indenting
the continued lines of the expression actually gives a false
impression of the underlying structure, a misperception that
the eye must travel all the way to the right margin to correct.

which seems to me well-argued. I wonder on what grounds PEP8
says "The preferred place to break around a binary operator is
*after* the operator" ?
Perhaps it's just the "continutation marker" rationale?

Regards, Peter

When you're *scanning* the code, breaking the line before the operator
might be better since you can easily see that that a line is a
continuation from the previous line.

However, when it comes to *reading* the code, it's easy to miss that the
code continues to the next line, especially when you rely on
parentheses' implicit line continuation and don't use an explicit
line-continuation character (i.e. \).

So... IMHO when it comes to break before or after the operator, it
depends on whether you rely on parentheses or explicit line
continuation. If you use implicit continuation with parentheses, it's
better to break after operators; else if you use explicit continuation
with \, it's better to break before operators.

Since python prefers using parentheses' implicit line cont., it follows
that breaking after operator is the natural choice.
 
L

Lawrence D'Oliveiro

J. Cliff said:
If the lines got separated, a leading + could disappear into its line
without any errors showing up. A trailing + would raise a syntax error.

Unless, of course, it was moved onto the previous line as part of whatever
caused the separation of the lines. How would you guard against that?
 
J

J. Cliff Dyer

Unless, of course, it was moved onto the previous line as part of whatever
caused the separation of the lines. How would you guard against that?

Can you give an example of what you mean?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top