If this got to a point where there was a case to revise 2005 decision or introduce an alternative (which I very much doubt can happen any time soon), much more elaborate research and survey would have to be done and all options considered.

I like `IF(cond, true, false)`, even better than `ifelse(cond, true, false)` - shorter. But in python this would indicate a function call, meaning all arguments would need to be evaluated before the expression logic. If evaluation is not costly, one can simply use his own function to do this.

I still feel that compared to list comprehension and other functional and elegant python constructs, python's if-else expression is lacking. I often choose to go multi-line much more verbose code as opposed to more brief constructs just because it becomes unreadable - a more elegant and logically convenient expression would change the decision ratio significantly, at least for me.

Your examples nicely emphasise it.

Another perspective:

# Code becomes easily read when there is a nice alignment in horizontal space. e.g.:

variable = None
length_1 = None
somethin = None

# I often take this into account on variable name selection. Now:

foo = var1 if a == 0 else default
bar = variable2 if a == 0 else default2

# As opposed to

foo = a == 0 ? var1 : default
bar = a == 0 ? variable2 : default2

# Naturally, one can argue: what if condition length differs - same problem.
# But in practice, the number of conditionals is greatly smaller than variables.
# Thus, much more easier to adapt to that.

Although, the argument that python is meant to be read as english is very much valid, but I do not see why it has to be an overarching one if the opportunity cost of it is too great in other dimensions.

Finally, it is always an option to have 2 conditional expressions. Maybe another python expression which is a superset of current `ifelse`. Just not sure what it could be and what other gaps or extensions it could fill.

From what I have gathered, these:

https://peps.python.org/pep-0505/

https://peps.python.org/pep-0463/

, and certain number of proposals in this group at their root are pointing approximately to the same direction. I.e. some things are too verbose (and too many lines of code) given the simplicity of what is needed to be done.

https://peps.python.org/pep-0308/#detailed-results-of-voting

It seems that C’s expression was ranked 2nd most favourable… The decision was 3rd. This kinda suggests that I am not as delusional as I initially thought I might appear to be with this...

The initial proposal wasn’t too bad - I could work with it. Being in line with a sequential logic of multiline `if-else` statement is a plus.

(if <condition>: <expression1> else: <expression2>)

On 18 Jul 2023, at 00:36, Laurent Lyaudet <laurent.lyaudet@gmail.com> wrote:

Hello all,

Please Dom Grigonis add choices :
- "No preference" choice to first question
- "I don't know" or "I can't tell" to third question
And I will answer to your poll and probably other people will feel and
do the same.
I agree that question 2 makes me prefer C syntax.
But C is not the nicest syntax in my point of view.
In MySQL SQL, there is IF(condition, if_result, else_result)
which I find nice.
Moreover, it fits well with black style of formatting:
foo_var = IF(
   this_is_a very_long_condition_expression_which_may_have_nested_parts,
   this_is_a very_long_if_result_expression_which_may_have_nested_parts,
   this_is_a very_long_else_result_expression_which_may_have_nested_parts,
)
to compare with :
foo_var = (
   this_is_a very_long_condition_expression_which_may_have_nested_parts,
   ? this_is_a very_long_if_result_expression_which_may_have_nested_parts,
   : this_is_a very_long_else_result_expression_which_may_have_nested_parts,
)
I can enjoy both, but I prefer the SQL apart from the fact that "IF"
keyword would be ambiguous.
I also enjoy very much :
foo_var = CASE
   WHEN condition THEN if_result
   WHEN condition2 THEN elif_result
   ELSE else_result
END
from SQL.
And CASE is not a reserved keyword and WHEN, THEN, ELSE could have
specific meaning inside of case.
Truly, I would enjoy the following syntax for Python à la black :
foo_var = case(
   when condition then if_result
   when condition2 then elif_result
   else else_result
)
or even more concise and still readable :
foo_var = case(
   condition : if_result,
   condition2 : elif_result,
   else_result,
)

Best regards,
   Laurent Lyaudet

Le lun. 17 juil. 2023 à 22:42, <python-ideas-request@python.org> a écrit :

Message: 2
Date: Mon, 17 Jul 2023 23:41:25 +0300
From: Dom Grigonis <dom.grigonis@gmail.com>
Subject: [Python-ideas] Conditional 1-line expression in python
To: python-ideas <python-ideas@python.org>
Message-ID: <31303E8B-05A4-408B-AF4D-916F805B5966@gmail.com>
Content-Type: multipart/alternative;
       boundary="Apple-Mail=_41C44739-410D-45EA-89FF-6E2F1AF86836"

Hi everyone,

I am not very keen on long discussions on such matter as I do not think there is much to discuss: there is no technical complexity in it and it doesn’t really change or introduce anything new. It is only a matter of opinion & style/design preferences with respect to logical order and brevity of a statement.

So I thought, if anyone can be bothered on such question and instead of writing 3-minute e-mail, would take few seconds to answer 3-question poll.

https://q5yitzu62.supersurvey.com <https://q5yitzu62.supersurvey.com/>

Would be interesting to see if my preference is an outlier or not really.

Kind regards,
D. Grigonis

-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 1499 bytes
Desc: not available

------------------------------

Subject: Digest Footer

_______________________________________________
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/

------------------------------

End of Python-ideas Digest, Vol 200, Issue 34
*********************************************
_______________________________________________
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/F3D6T4AEQLFIK7B3AXTUAJERI3BANMHP/
Code of Conduct: http://python.org/psf/codeofconduct/