Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #11092 > unrolled thread
| Started by | Yingjie Lan <lanyjie@yahoo.com> |
|---|---|
| First post | 2011-08-09 21:42 -0700 |
| Last post | 2011-08-10 19:26 +0800 |
| Articles | 2 — 2 participants |
Back to article view | Back to comp.lang.python
allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-09 21:42 -0700
Re: allow line break at operators TheSaint <no@nowhere.net.no> - 2011-08-10 19:26 +0800
| From | Yingjie Lan <lanyjie@yahoo.com> |
|---|---|
| Date | 2011-08-09 21:42 -0700 |
| Subject | allow line break at operators |
| Message-ID | <mailman.2083.1312951551.1164.python-list@python.org> |
Hi all,
When writing a long expresion, one usually would like to break it into multiple lines. Currently, you may use a '\' to do so, but it looks a little awkward (more like machine-oriented thing). Therefore I start wondering why not allow line breaking at an operator, which is the standard way of breaking a long expression in publication? Here is an example:
#the old way
x = 1+2+3+4+\
1+2+3+4
#the new way
x = 1+2+3+4+ #line continues as it is clearly unfinished
1+2+3+4
Of course, the dot operator is also included, which may facilitate method chaining:
x = svg.append( 'circle' ).
r(2).cx(1).xy(1).
foreground('black').bkground('white')
Thoughts?
Yingjie
[toc] | [next] | [standalone]
| From | TheSaint <no@nowhere.net.no> |
|---|---|
| Date | 2011-08-10 19:26 +0800 |
| Message-ID | <j1tptg$ahi$1@speranza.aioe.org> |
| In reply to | #11092 |
Yingjie Lan wrote: > #the new way > x = 1+2+3+4+ #line continues as it is clearly unfinished > > 1+2+3+4 > Genrally I prefer this way. > Of course, the dot operator is also included, which may facilitate method > chaining: > > x = svg.append( 'circle' ). Dot-ended is to tiny thing that might cause oversights. *If* it'll be used as a secondary option I think it doesn't matter, otherwise *if* use as a compulsory writing mode I'd say it is pretty mistake prone.
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.python
csiph-web