Reduce need of backslash

[Nicolas Fleury]

Hi,

I was wondering if the need for \ could be reduce in the language. For
example, could a line ending with = or + could be automaticly considered
incomplete?

Regards,

Nicolas

 

[Peter Otten]

I was wondering if the need for \ could be reduce in the language. For
example, could a line ending with = or + could be automaticly considered
incomplete?

Did you know about (...)?
.... + "beta"
.... + "gamma"
....
.... )
'alphabetagamma'

Peter

 

[Peter Hansen]

I was wondering if the need for \ could be reduce in the language. For
example, could a line ending with = or + could be automaticly considered
incomplete?

What should Python do in the following case?

a = 5 +
someFunc(a)

Okay, you want it to quietly add 5 and the result of someFunc() together and
assign to "a". What if I told you that I actually had intended to add 5
plus "b" and assign to a, then call someFunc() and discard the return value.

You've just turned a nice clean error message from the compiler into a
silent and possibly deadly bug.

"Explicit is better than implicit, and errors should never pass silently"
as has been noted again recently in another thread.

-Peter

 

[Duncan Booth]

I was wondering if the need for \ could be reduce in the language. For
example, could a line ending with = or + could be automaticly considered
incomplete?

You very rarely need \ as it is. Any parenthesised expression may be split
across lines without problems.

 

[John Roth]

You very rarely need \ as it is. Any parenthesised expression may be split
across lines without problems.

And you can parenthesize a surprisingly large number of places. One
that I learned just recently was that the entire operand string of the
print statement can be put into parenthesis.

John Roth

 

[Nicolas Fleury]

And you can parenthesize a surprisingly large number of places. One
that I learned just recently was that the entire operand string of the
print statement can be put into parenthesis.

I'm not sure what you mean exactly.
print (1,2) prints a tuple while print 1,2 prints a different thing.

Regards,

Nicolas

 

[Nicolas Fleury]

I'm not sure what you mean exactly.
print (1,2) prints a tuple while print 1,2 prints a different thing.

Ok, print (1) doesn't print a tuple... forget my question...

Nicolas

 

[Nicolas Fleury]

Nicolas Fleury wrote:




Did you know about (...)?

Actually, no. But it's still not what I'm looking for. It's just that
I'm used to languages where I can put my code on multiple easily to make
lines shorter. As John pointed, it's possible to add () to print. I
just discovered that it can be done with return also. I wonder how to
remove the need for \ in that example:

parser.StartElementHandler = \
lambda name, attrs: \
GenericParser.handleElementStart(self, name, attrs)

Regards,

Nicolas

 

[Nicolas Fleury]

What should Python do in the following case?

a = 5 +
someFunc(a)

Okay, you want it to quietly add 5 and the result of someFunc() together and
assign to "a". What if I told you that I actually had intended to add 5
plus "b" and assign to a, then call someFunc() and discard the return value.

You've just turned a nice clean error message from the compiler into a
silent and possibly deadly bug.

What if the second line would be indented? Indentation is already used
to determine blocks, why not instructions? For example, the following
is not error-prone at all:

a = 5 +
someFunc()

Doesn't it stay with python minimalistic philosophy?

Regards,

Nicolas

 

[John Roth]

Actually, no. But it's still not what I'm looking for. It's just that
I'm used to languages where I can put my code on multiple easily to make
lines shorter. As John pointed, it's possible to add () to print. I
just discovered that it can be done with return also. I wonder how to
remove the need for \ in that example:

parser.StartElementHandler = \
lambda name, attrs: \
GenericParser.handleElementStart(self, name, attrs)

How about:

parser.StartElementHandler = (lambda name, attrs:
GenericParser.handleElementStart(self, name, attrs))

John Roth

 

[Stephen Horne]

What if the second line would be indented? Indentation is already used
to determine blocks, why not instructions? For example, the following
is not error-prone at all:

a = 5 +
someFunc()

Doesn't it stay with python minimalistic philosophy?

I don't know the original rationale, but to me this mostly looks ugly.
Maybe I'd get used to it if it happened a lot, but this is rarely an
issue in practice.

Basically, when I need to break an expression over multiple lines, the
odds are that it already has parentheses anyway. And I wouldn't indent
that way anyway, I'd do it as...

a = ( firstitem
+ seconditem
+ ( thirditem
* fourthitem
)
)

.... ie using indentation to clarify the structure of the expression
much as I would with block structuring - whether I was using Python or
some other language.

In a way I can imagine some value to putting a statement in
parentheses. It would look very Lispy, but then some would say that's
a good thing.

Occasionally, I go through a phase of thinking semicolons should be
used as compulsory statement terminators rather than as the rarely
used separators they are now - in which case '\' would be completely
redundant - but it really is a trivial issue, whereas the idea of
changing such a fundamental piece of syntax - well, don't go there.

 

[Nicolas Fleury]

Basically, when I need to break an expression over multiple lines, the
odds are that it already has parentheses anyway. And I wouldn't indent
that way anyway, I'd do it as...

a = ( firstitem
+ seconditem
+ ( thirditem
* fourthitem
)
)

Didn't know about that possibility; I though it would assign a one
element tuple. I just read that a one-element tuple is written (x,).
Everything's fine now, thx

Nicolas

 

[Nicolas Fleury]

How about:

parser.StartElementHandler = (lambda name, attrs:
GenericParser.handleElementStart(self, name, attrs))

That's perfect. All my incomprehension was because I didn't know a
one-element tuple is written (x,) and not (x). Thx

Nicolas

 

[Bengt Richter]

Did you know about (...)?

... + "beta"
... + "gamma"
...
... )
'alphabetagamma'

Did you know the tokenizer concatenates white-space-separated string literals into
a single literal? ;-)
.... "beta"
.... "gamma"
.... )
'alphabetagamma'

Note the effect in code:
... + "beta"
... + "gamma"
... ) ... "beta"
... "gamma"
... ) 1 0 LOAD_CONST 1 ('alpha')
3 LOAD_CONST 2 ('beta')
6 BINARY_ADD
7 LOAD_CONST 3 ('gamma')
10 BINARY_ADD
11 RETURN_VALUE 1 0 LOAD_CONST 1 ('alphabetagamma')
3 RETURN_VALUE

Regards,
Bengt Richter

 

[Nicolas Fleury]

Basically, when I need to break an expression over multiple lines, the
odds are that it already has parentheses anyway. And I wouldn't indent
that way anyway, I'd do it as...

a = ( firstitem
+ seconditem
+ ( thirditem
* fourthitem
)
)

But that's indentation anyway. If the rule would be "all lines with a
superior indentation are part of the previous line", would that work?
This way it would not be necessary to add the parenthesis. I wonder if
I'm missing something...

Regards,

Nicolas

 

[Stephen Horne]

But that's indentation anyway. If the rule would be "all lines with a
superior indentation are part of the previous line", would that work?

Probably yes, but it has been discussed before and never generated a
clear enough choice or sufficient will to make the change.

My personal preference would be closer to Haskells offside rule,
allowing me to write something similar to my example above but with
indentation reducing the need for parentheses. But it really isn't an
important issue IMO.

 

[Peter Otten]

Did you know the tokenizer concatenates white-space-separated string
literals into a single literal? ;-)

... "beta"
... "gamma"
... )
'alphabetagamma'

Note the effect in code:

... + "beta"
... + "gamma"
... )
... "beta"
... "gamma"
... )
1 0 LOAD_CONST 1 ('alpha')
3 LOAD_CONST 2 ('beta')
6 BINARY_ADD
7 LOAD_CONST 3 ('gamma')
10 BINARY_ADD
11 RETURN_VALUE
1 0 LOAD_CONST 1 ('alphabetagamma')
3 RETURN_VALUE

No. Or I would have chosen another example

But now you point it out I see it's used quite frequently in the library.

Peter