@MRAB
It's not that much shorter. You wouldn't be saving much typing or space.
IMO, that's a weak point. The amount of indentation you need doubles, and that is significant. Also, common style guides and best practices recommend no more than 80 chars per line. Losing 5.5% of my available space when I'm already in a method per line is not nothing. With modern editors there is no typing cost to either method. I never claimed this would save typing. But it does clearly save a lot of horizontal space (and 1 vertical line, which is not nothing). @Paul Sokolovsky
but it's proverbial Freudian slip ...
Yes, I made a typo. Try not to judge too harshly because of a dyslexic failure to catch a grammatical issue.
it seems that some people just can't get at peace with Python's indentation-based syntax,
And I'm all on board with indentation based syntax. I'm not typically one to try and make Python work like other languages. My motivation simply stems from the fact that I've been bothered how a with directly after an if costs me 8 spaces instead of 4. I strongly feel like this would be a good change, and I am going to fight at least a little bit to defend the idea, or at least try to advocate for it and help refine the syntax into something better. I do think this new syntax is a lot better than my original proposal, which is admittedly not a good idea, It's possible this could be tweaked more to improve it. Indentation makes beautiful code, but it's not free. The more horizontal space you take --- the more nesting in your code --- the higher its complexity. I don't feel that having a with statement immediately after an if (or a for loop for that matter) is adding much complexity, but if forces double indentation of whatever code was going to be after the for loop. @Iasizoillo
Other thing strange about proposal is: why only with after if?
However isn't the fact that you *can* do if 1: return 1 also weird? I think something like `if [condition] for x in [iterable]` would be reasonable. I also suppose `if [condition] while [other-condtion]` have some use as well. I can also see uses for something like `for var in [iterable] with var:` being useful. I can actually think of a specific case where I would use it. Currently my timerit package requires syntax like: import timerit for timer in timerit.Timerit(num=100, bestof=3, verbose=1): with timer: [code] But that could be simplified to import timerit for timer in timerit.Timerit(num=100, bestof=3, verbose=1) with timer: [code] And free up one level of indentation (very useful if you are trying to keep under 80 chars per line) Perhaps the new syntax rule is as simple as, if a keyword that would normally require a new scope is placed where the colon would be for another statement that defines a new scope, then any code indented afterwords is treated as in the scope of all of the statements. That means you could do something crazy like: if foo if bar or baz with biz if buz: [code] In that example the biz context manager would only trigger if `foo and (bar or baz)` and if it did and buz was true then [code] would execute. Obviously I wouldn't recommend doing something like this stylistically, it would be a "bad code" usage of the proposed syntax (but all syntax has ways that it can be used to write bad code). This example does make me lean slightly more in favor of requiring the colon before the next "scoping" keyword is used, e.g.: if foo: if bar or baz: with biz: if buz: [code] Note that by convention an `else` would need to correspond to the outermost (or alternatively innermost) scoping keyword, so for if foo: if bar or baz: with biz: if buz: [code1] else: [code2] [code2] only executes if `not foo`. On Sun, Feb 7, 2021 at 1:28 AM Paul Sokolovsky <pmiscml@gmail.com> wrote:
Hello,
On Sat, 6 Feb 2021 19:57:33 -0500 Jonathan Crall <erotemic@gmail.com> wrote:
I ran into another case where I wish I had some sort of conditional if.
Right, conditional "if" is exactly what we miss in Python.
Yes, it's a typo, but it's proverbial Freudian slip, shows what stays behind such proposals - un[spell]checked desire to add some tautology to the language.
Wasting that horizontal space is not an option
Reading things like this, it seems that some people just can't get at peace with Python's indentation-based syntax, and would jump in no time to an alternative syntax which allows to smack indentation.
It was also said many times, that it you want some trivial variety on the existing language, pick up your favorite macro package and go ahead, coding trivial macros in trivial.
-- Best regards, Paul mailto:pmiscml@gmail.com
-- -Dr. Jon Crall (him)