On 18 October 2012 12:05, Tim Chase <python.l...@tim.thechases.com> wrote:
> On 10/18/12 04:33, wxjmfa...@gmail.com wrote:
> > I use a "double indentation".
> >
> >>>> if 'asdf' and 'asdf' and 'asdf' \
> > ... 'asdf' and 'asdf' and \
> > ... 'asdf' and 'asdf':
> > ... print('do if')
> > ... s = 'asdf'
> > ... ss = 'asdf'
> > ...
> > do if
> >>>> if looks_like_it_might_be_spam(
> > ... some_longer_variables,
> > ... here_and_here, and_here_also):
> > ... logger.notice("might be spam")
> > ... move_to_spam_folder(some_longer_variables)
> > ... update_spam_statistics(here_and_here)
>
> I lean towards double-indent as well, though I favor parens/brackets
> vs. trailing backslashes. My conditions usually go one-per-line,
> too. I also tend to put my closing paren+colon on a stand-alone line:
>
> if (
> something
> or something_else
> or yet_other_stuff
> ):
> do_thing1()
> do_thing2()
>
> It's not quite as nice with pure parens, working better with
> function-calls. However, it makes my git/svn diffs easier to read
> when conditions get added/removed because only that line (usually)
> changes, rather than having the noise of the paren moving around.
>
> In 2.5 and later, I like to write that as
>
> if any([
> something,
> something_else,
> yet_other_stuff,
> ]):
> do_thing1()
> do_thing2()
>
> where each item is uniform (one trailing comma, rather than one item
> being special without a comma/or/and) so I don't have the diff noise
> for "or"/"and" bouncing around either.
>
> Making my diffs easy to read is pretty important to me.
>
I'm of the opinion that:
cheese_cake = bake(
self_raising_flour(),
sour_lemons(),
milky_cheese(),
)
is the nicest format for normal overflow, but I'm really irked at the sight
of *any* overflow in an "if x:" statement or anything that starts more
indentation. All indentation *and* outdentation should be meaningful:
"group" or "end group" respectively. If you indent and then outdent *to a
new indentation*, it's confusing and obfuscating. The outdent is not "end
group", as before, but something else.
The neat thing about:
> foobars = inversed_word_order(
barfoo(),
raboof(
inverse_mode="letters",
hidden_lettuce=GGE_RETSAE
),
not foobar()
)
is that it is consistent with this world-view.
My lines often go past 120 characters without splitting*, so I rarely have
this problem, but when I do the solution is *invariably*:
all_can_be_baked = all(
can_be_baked(ingredient)
for ingredient in [
self_raising_flour(),
sour_lemons(),
milky_cheese(),
]
)
if all_can_be_baked:
There is not a situation in the world where a suitable intermediate name
can not be found: you are doing something for a reason, after all.
* I use 8-space tabs, so it's not that hard ;)
--
http://mail.python.org/mailman/listinfo/python-list
