On Apr 15, 2011, at 05:05 PM, Andreas Röhler wrote: >Am 15.04.2011 13:49, schrieb Barry Warsaw: >> Hi Andreas, >> >> On Apr 15, 2011, at 08:59 AM, Andreas Röhler wrote: >> >>> def foo(): >>> x = dict( >>> a=1, >>> b=2, >>> c=3, >>> ) >>> >>> >>> which looks okay for me. >> >> Except it's a regression from the trunk. > >Hi Barry, > >that might be. Admittingly worked the opposite direction. > >> When the open paren ends a line, >> subsequent lines should get indented only one level, not to the space after >> an >> open paren. > >My understanding here was: when a listing --list, tupel, dict-- starts, >line-breaks doesn't matter semantically, so attention should be laid onto the >colum of list-starter.
This is true, although the rule is more general. Inside any parenthesis,
backslashes are not required for multi-line constructs. So it doesn't have to
be inside a list, tuple, or dict literal, the same is true inside function
call or definition arguments, etc.
In all these cases, if paren is the last thing on the line, subsequent lines
get indented only one level by default. I'm fine if there's a configuration
variable to line them up after the open paren, but it shouldn't be default.
>If you indent just the offset of former line, the column than indicates
>nothing specific, it's a purely graphical indent.
Well, actually *any* indentation inside parens is purely cosmetic. :)
-----snip snip-----
def baz(**kw):
print kw
def foo():
baz(
a=1,
b=2,
c=4)
foo()
-----snip snip-----
$ python foo.py
{'a': 1, 'c': 4, 'b': 2}
>So far at least my conclusion from bug #328842 - more flexible indentation of
>continued lists/tuples/dicts
>
>Seems headed into something wrong :(
I do think they're related issues, and I think it's okay to address bug 328842
but not at the expense of the regression. ;)
>OK, going to re-install the trunks behavior at least as an option/default.
>
>What about `py-indent-honor-listing' - which would be `nil' meeting your
>preferences?
I wonder if there are any other options people could want. If so, or if we
want to future-proof this, then perhaps a variable could be named
py-list-continuation-behavior with two values currently: 'one-indent-level and
'after-open-paren?
Cheers,
-Barry
signature.asc
Description: PGP signature
_______________________________________________ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
