I would like to carefully suggest a half form of the ternary expression. Currently, you can write code like:
if cond: do_something
However, especially if the condition and action are both really simple, taking two lines feels like a bit of a waste. So I sometimes write:
if cond: do_something
However, this isn't PEP8 compliant, and every linter complains about it. They'd be right if the condition and action were a bit more complicated. I would very much like to write:
do_something if cond
and be done with it. Like a ternary expression but without the else clause. I know this is probably not gonna make it due to "not strong enough pro's, just swallow the linters complaints and roll with the 'if cond: do_something' if you care so much about that 1 line", but I still wanted to make my case. ===Example Usecases=== (inside loop)
continue if x > 50
(logging)
(singleton creation)
cls.inst = super().__new__(cls, *args, **kwargs) if cls.inst is None
(cache)
cache.warm() if cache is None
25.05.18 13:06, Jacco van Dorp пише:
This isn't PEP8 compliant either. I suppose that if this syntax be accepted by the compiler, it will be explicitly disallowed by PEP8 for the same reason as "if cond: do_something". It is easier to pass an option to linter that will silence this warning than introduce a new ambiguous syntax. For example try to interpret "[a for b if c]" if "b if c" be a valid expression.
in jinja, you can do “{{ 'foo' if bar }}”. it evaluates to “'foo'” or an empty string (differently to python’s formatting, “None” expands to an empty string in jinja) similarly I often do “thing = 'foo' if bar else None” and it would be nice if i could shorten that by making “else None” implicit. idk how often other people do that though Serhiy Storchaka <storchaka@gmail.com> schrieb am Fr., 25. Mai 2018 um 12:34 Uhr:
On Fri, May 25, 2018 at 12:06:42PM +0200, Jacco van Dorp wrote:
PEP 8 is not holy writ. Ignore it when your code is better for ignoring it.
I believe there are a number of languages out there which have clauses like this. I'm not going to do a language survey, but two popular choices are: something if condition something unless condition and similar variations. For example, Ruby: http://www.railstips.org/blog/archives/2008/12/01/unless-the-abused-ruby-con...
That's not going to work if this is an *expression*. You can't say: continue if x > 50 else "don't continue" The problem with an expression is, what does this return if the clause is false? So the comparison to the ternary if expression is invalid. This would have to be a statement.
If the logging module already solves this problem in "a much better way", why are you including a much worse way?
(singleton creation)
cls.inst = super().__new__(cls, *args, **kwargs) if cls.inst is None
And this is a problem: that is ambiguous with the if...else ternary expression. Presumably you want that to look like a statement: cls.inst = super().__new__(cls, *args, **kwargs) guarded by an if statement: if cls.inst is None but it can also be interpreted as an assignment: cls.inst = with an incomplete ternary expression: super().__new__(cls, *args, **kwargs) if cls.inst is None else what???? Even if we decide to make it a rule that one interpretation beats the other, we still have to expect people will be confused by it. So we ought to be cautious about syntax which is ambiguous in this way.
(cache)
cache.warm() if cache is None
There are about a zillion things that you can write like this: if condition: do something so the use-cases certainly exist. The only question is a matter of taste and familiarity, whether it nicer to write it as above or like: do something if condition -- Steve
On 25/05/2018 12:38, Steven D'Aprano wrote:
PEP 8 is not holy writ. Ignore it when your code is better for ignoring it.
+1. Not infrequently I judge that my code is easier both to read and to maintain with more than 1 (short) statement on a line, often when it allows similar items to be aligned vertically. A spur-of-the moment, totally invented example: if MON <= day <= FRI: Rate = Normal if day==SAT: Rate = DoubleTime if day==SUN: Rate = TripleTime I also feel no inhibitions about using Jacco's original example: if cond: do_something Rob Cliffe
You cannot have `expression if expression` in a language that also supports `expression if expression else expression` (like Python). Otherwise, you have the dangling else problem: https://en.wikipedia.org/wiki/Dangling_else -- Carl Smith carl.input@gmail.com On 25 May 2018 at 15:21, Rob Cliffe via Python-ideas < python-ideas@python.org> wrote:
2018-05-26 11:24 GMT+02:00 Antoine Rozo <antoine.rozo@gmail.com>:
That won't work, since at other places, I do the same with bools and strings in the same dict. (I read out an online database, which only yields data in json format. I dont want an extra parsing step to transform it to another data structure than dicts. ). Also, empty fields are set to None, no matter actual field type(actually, it doesn't pass empty fields for some godawful reason, so I have a __missing__ that returns None if and only if it's in a list of expected fields. ). As for the dangling else problem, noting a good rule (left to right ?) and a few parens in other cases can't fix. That said, because of the rest of this thread, it seems to me like a statement would be the proper implementation. So the thread title has become misleading. This would remove the dangling else problem unless there's an if/else in the condition, which I can't figure out why you'd need that.
2018-05-25 14:26 GMT+02:00 Kirill Balunov <kirillbalunov@gmail.com>:
If it is an expression, what should `do_something if cond` return on failure? If you don't care you can already use `cond and do_something`.
Duh, forgot to mention. I wouldn't have it return anything. Ternary returns something because you have two options and picks one. This is conditional execution of a statement. I guess it would be a statement, like normal if. I guess cond and do_something would be equivalent, but that's not really the intention of and/or, no matter how much it's used for this sort of thing. Disclaimer: I don't really expect this to be accepted. It's more of a minor gripe i've occasionally had. This afternoon, I wrote: if not article["art_wt"]: article["art_wt"] = 0 if not article["px_pchs"]: article["px_pchs"] = 0 if not article["px_calc"]: article["px_calc"] = 0 if not article["px_sell"]: article["px_sell"] = 0 while preparing a dict for import in accountview. I try not to make a habit of dismissing syntax warnings. I consider the code above abundantly clear (no, I dont know what those keys mean. Since I have no power over that, I dont consider it detrimental to clarity.)
25.05.18 13:06, Jacco van Dorp пише:
This isn't PEP8 compliant either. I suppose that if this syntax be accepted by the compiler, it will be explicitly disallowed by PEP8 for the same reason as "if cond: do_something". It is easier to pass an option to linter that will silence this warning than introduce a new ambiguous syntax. For example try to interpret "[a for b if c]" if "b if c" be a valid expression.
in jinja, you can do “{{ 'foo' if bar }}”. it evaluates to “'foo'” or an empty string (differently to python’s formatting, “None” expands to an empty string in jinja) similarly I often do “thing = 'foo' if bar else None” and it would be nice if i could shorten that by making “else None” implicit. idk how often other people do that though Serhiy Storchaka <storchaka@gmail.com> schrieb am Fr., 25. Mai 2018 um 12:34 Uhr:
On Fri, May 25, 2018 at 12:06:42PM +0200, Jacco van Dorp wrote:
PEP 8 is not holy writ. Ignore it when your code is better for ignoring it.
I believe there are a number of languages out there which have clauses like this. I'm not going to do a language survey, but two popular choices are: something if condition something unless condition and similar variations. For example, Ruby: http://www.railstips.org/blog/archives/2008/12/01/unless-the-abused-ruby-con...
That's not going to work if this is an *expression*. You can't say: continue if x > 50 else "don't continue" The problem with an expression is, what does this return if the clause is false? So the comparison to the ternary if expression is invalid. This would have to be a statement.
If the logging module already solves this problem in "a much better way", why are you including a much worse way?
(singleton creation)
cls.inst = super().__new__(cls, *args, **kwargs) if cls.inst is None
And this is a problem: that is ambiguous with the if...else ternary expression. Presumably you want that to look like a statement: cls.inst = super().__new__(cls, *args, **kwargs) guarded by an if statement: if cls.inst is None but it can also be interpreted as an assignment: cls.inst = with an incomplete ternary expression: super().__new__(cls, *args, **kwargs) if cls.inst is None else what???? Even if we decide to make it a rule that one interpretation beats the other, we still have to expect people will be confused by it. So we ought to be cautious about syntax which is ambiguous in this way.
(cache)
cache.warm() if cache is None
There are about a zillion things that you can write like this: if condition: do something so the use-cases certainly exist. The only question is a matter of taste and familiarity, whether it nicer to write it as above or like: do something if condition -- Steve
On 25/05/2018 12:38, Steven D'Aprano wrote:
PEP 8 is not holy writ. Ignore it when your code is better for ignoring it.
+1. Not infrequently I judge that my code is easier both to read and to maintain with more than 1 (short) statement on a line, often when it allows similar items to be aligned vertically. A spur-of-the moment, totally invented example: if MON <= day <= FRI: Rate = Normal if day==SAT: Rate = DoubleTime if day==SUN: Rate = TripleTime I also feel no inhibitions about using Jacco's original example: if cond: do_something Rob Cliffe
You cannot have `expression if expression` in a language that also supports `expression if expression else expression` (like Python). Otherwise, you have the dangling else problem: https://en.wikipedia.org/wiki/Dangling_else -- Carl Smith carl.input@gmail.com On 25 May 2018 at 15:21, Rob Cliffe via Python-ideas < python-ideas@python.org> wrote:
2018-05-26 11:24 GMT+02:00 Antoine Rozo <antoine.rozo@gmail.com>:
That won't work, since at other places, I do the same with bools and strings in the same dict. (I read out an online database, which only yields data in json format. I dont want an extra parsing step to transform it to another data structure than dicts. ). Also, empty fields are set to None, no matter actual field type(actually, it doesn't pass empty fields for some godawful reason, so I have a __missing__ that returns None if and only if it's in a list of expected fields. ). As for the dangling else problem, noting a good rule (left to right ?) and a few parens in other cases can't fix. That said, because of the rest of this thread, it seems to me like a statement would be the proper implementation. So the thread title has become misleading. This would remove the dangling else problem unless there's an if/else in the condition, which I can't figure out why you'd need that.
2018-05-25 14:26 GMT+02:00 Kirill Balunov <kirillbalunov@gmail.com>:
If it is an expression, what should `do_something if cond` return on failure? If you don't care you can already use `cond and do_something`.
Duh, forgot to mention. I wouldn't have it return anything. Ternary returns something because you have two options and picks one. This is conditional execution of a statement. I guess it would be a statement, like normal if. I guess cond and do_something would be equivalent, but that's not really the intention of and/or, no matter how much it's used for this sort of thing. Disclaimer: I don't really expect this to be accepted. It's more of a minor gripe i've occasionally had. This afternoon, I wrote: if not article["art_wt"]: article["art_wt"] = 0 if not article["px_pchs"]: article["px_pchs"] = 0 if not article["px_calc"]: article["px_calc"] = 0 if not article["px_sell"]: article["px_sell"] = 0 while preparing a dict for import in accountview. I try not to make a habit of dismissing syntax warnings. I consider the code above abundantly clear (no, I dont know what those keys mean. Since I have no power over that, I dont consider it detrimental to clarity.)
participants (9)
-
Antoine Rozo -
Carl Smith -
Elazar -
Jacco van Dorp -
Kirill Balunov -
Philipp A. -
Rob Cliffe -
Serhiy Storchaka -
Steven D'Aprano