@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
IMO this syntax probably should be limited to the particular case where
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. 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. On Mon, Feb 8, 2021 at 3:50 AM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Brendan Barnwell writes:
let the editor (as configured by the reader) choose how to map that [long logical line] onto a visual display.
I think your editor must be the first example of true intelligence in a machine. I don't know any editors that reliably do this readably, let alone to my taste. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BMAMYL... Code of Conduct: http://python.org/psf/codeofconduct/
-- -Dr. Jon Crall (him)