A desperate lunge for on-topic-ness

[Joshua Landau]

On 18 October 2012 12:05, Tim Chase <python.list at tim.thechases.com> wrote:

> On 10/18/12 04:33, wxjmfauth at 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 ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121018/661be94a/attachment.html>