Reduce need of backslash

[Pettersen, Bjorn S]

> From: John Roth [mailto:newsgroups at jhrothjr.com] 
> 
> "Nicolas Fleury" <nid_oizo at yahoo.com_remove_the_> wrote in message
> news:MI_cb.75294$PD3.4794043 at nnrp1.uunet.ca...
> > Peter Otten wrote:
> >
> > > Nicolas Fleury wrote:
> > >
> > >
> > >>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 (...)?
> >
> > 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.  

"I know that long lines are bad, help me do it more conveniently in
Python?" <wink>.

Seriously though, long lines are a sure sign that you're doing too much
per line. The obvious solution is to pull out subexpressions and assign
them to meaningful temporary variable names until you're within 25x80.
When someone wants to fix a bug in your code a year from now it will
also be easier for them to figure out what you were trying to do
(potentially saving you time :-)

> > 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))

A lambda that doesn't fit on one line is way to obscure... It needs a
comment to justify it's existence, so might as well do it right <wink>:

  def startElementCallback(tagname, attrs):
      GenericParser.handleElementStart(self, tagname, attrs))

  parser.StartElementHandler = startElementCallback

No contortions, I'm explicitly saying what the purpose of the funciton
is, I can add comments/asserts/logging without spending time on code
"layout" issues, and I can write tests explicitly for
'startElementCallback' without considering the rest of the fn's
functionality (it might be trivial here, but code grows... ;-)

-- bjorn