@Iasizoillo

> Only if you don't setup vars like official example* or not calc some statistic after timered block

I wrote the official docs, so I'm aware of that case. In the case where setup
variables are required it make sense to me to have an extra level of
indentation. It just bothers me that I still need extra indentation when I
*don't* need setup variables.

> In your example this is true by luck,

Yes, but I also chose a verbose and explicit invocation of `Timerit` because
people may not be familiar with what the default arguments are. I'm also not
opposed to line wrapping e.g.

import timerit
class MyClass:
def myfunc():
# Next line is 79 chars long, at limit of restricted pep8
for timer in timerit.Timerit(
num=100, bestof=3, verbose=1): with timer:
[code]

Although, at this point I would have refactored the code to look like this:

import timerit
class MyClass:
def myfunc():
ti = timerit.Timerit(num=100, bestof=3, verbose=1)
for timer in ti: with timer:
[code]

Furthermore, having one line that is over the character limit (whether it be
79, 99, or whatever), is a lot easier to deal with than multiple lines in the
[code] block.

@Greg Ewing

> I don't know why some people seem to be so afraid of indentation levels

There are a few reasons for me. I don't like when my linter yells at me. But
more importantly: I don't like when lines wrap around (or I have to
horizontally scroll) when I have two files open on a portrait monitor in
vertical split mode and lines wrap around. On my 4K setup, I have 97 characters
of horizontal space to play with in the best case (it's worse if I have a
NerdTree sidebar open). On my older monitor this situation is worse.

> Remember, you don't *have* to indent by 4 spaces. I often write Python with
> 2-space indents, which is quite readable and gives me twice as many
> indentation levels to play with.

This is a good point, and one I have considered. I know I *could*, and I don't
have a great argument against this point. It feels wrong though. Perhaps in the
same way that `if [cond]: with [obj]:` feels wrong to others? Or maybe its the
more grounded facts that (1) I prefer a consistent indentation level and (2) I
set my editor to use a 4 space indentation level and mixing and matching 2 or 4
space indentations mess with that. I do think this is one of the best arguments
against my idea, but at the same time I feel like the idea has enough merit
where this argument against it doesn't kill it.

@Stephen J Turnbull
> A big issue for me is that "with" doesn't commute with "if".

That would be a huge problem if "if" commuted with "with"!

The order of nesting *should* be the order of appearance. Your example:

for line in f with open('file') as f:
process(line)

Should be rewritten as:

with open('file') as f: for line in f:
process(line)

The other way around, the with would happen in every iteration of the loop.

> Notice that once you combine them into a single statement, you can choose either semantics, which is a bug magnet

To be fair, coding is a bug magnet. And yes, there would need to be a rule that
defines semantics. Again, I would propose that "the order of appearance is the
order of nesting" should be that rule.

> IMO this syntax probably should be limited to the particular case where there's a context manager

Having considered this more, I prefer the style where the grammar effectively
allows chaining of nesting statements. It seems a lot more elegant and
consistent than constraining this to just conditionals. If implemented, I
personally would likely only use this for the context manager case, but I know
people like Jeremy Howard would have a field day with it.

@David Mertz

> Code is READ far more often than it is written!

Yes! I find myself reading my double indented context blocks / non-contiguous
caching logic a lot and wishing they were smaller / contiguous.

> I don't like the actual proposal. It weirdly combines almost orthogonal
> concepts into the same block statement.

This is a good point. I think the syntax -- as with any other programming
construct -- should be used judiciously. I envision it used in cases like the
ones I mentioned where the `if` and `with` deal with correlated information.
`if stamp.expired():` and `with stamp:` are not orthogonal.

@Christopher Barker

> Are you suggesting that we add syntax to Python that makes it easier to keep the number of levels of indentation down?

Yes, I think the core essence of this proposal is a way to keep indentation
down. Especially in cases where there are multiple levels of (short) nesting
statements with no other logic in between. This is a fairly common case, and
having the option to reduce required indentation seems like it might be nice.
Obviously this isn't critical for the Python grammar, but at this point what
is? It's such a beautiful language already! Almost anything added now is going
to be for convenience (e.g. format strings).

> However, if you are talking about the readability of and individual not-so
> long line, then I'd say you can ignore the 8 spaces that got you into the
> method, and we're now at a 88 char line :-)

While many modern monitors can deal with this, I often run into cases
(especially when working with split panes) where horizontal space is still
limited. As an analogy, just because we have 12 TB hard drives, doesn't mean we
no longer need to care about file compression.