Ah, I can’t do that post-publish. This will have to suffice for now. 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-0505/> https://peps.python.org/pep-0463/ <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 <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.lyau...@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-requ...@python.org> a écrit : >> >> Message: 2 >> Date: Mon, 17 Jul 2023 23:41:25 +0300 >> From: Dom Grigonis <dom.grigo...@gmail.com> >> Subject: [Python-ideas] Conditional 1-line expression in python >> To: python-ideas <python-ideas@python.org> >> Message-ID: <31303e8b-05a4-408b-af4d-916f805b5...@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-le...@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-le...@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/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/YLZC6GQQHLGFNS2APYOIXMK6JE36JPUR/ Code of Conduct: http://python.org/psf/codeofconduct/
