> It does exactly the same as the C version and is more readable. Or am I
> missing something?
My point is exactly that it is not easily readable compared to C version. Also,
unnecessarily verbose. The order of components is rather awkward.
I came to this, because people seem to want one-liners for certain things and
what I came up with is that maybe more concise if-else expression could help.
# Fairly reasonable case.
def foo(a: bool, c: float, d: float)
val = a ? (c ? c : d) : (d ? d : c)
return val
# Comapred to
def bar(a: bool, c: float, d: float)
val = (c if c else d) if a else (d if d else c)
return val
Maybe for someone who majored in languages python’s if-else is more easily
understood. To me, personally, 2nd one is unbearable, while 1st one is fairly
pleasant and satisfying.
This whole thing started from dict’s `get` extension:
def get_substitute(self, key, default=None, subs=()):
return key in self ? (self[key] := val in subs ? subs[val] : val) : default
I dare you to do a 1-liner with current if-else.
Also, https://peps.python.org/pep-0505/ <https://peps.python.org/pep-0505/>
Why was it even considered if it doesn’t introduce any new functionality? I
also dare you go through that PEP’s examples and re-write them with current
if-else expression.
So maybe, just maybe, making already existing expression more readable can also
be a valid suggestion?
As I said, in my opinion it would solve many existing queries and requests,
just because certain things would become very pleasant and obvious how to do in
simple one-liners.
Simpler and more logically convenient if-else combined with other elegant
python expressions would potentially fill that gap.
From where I currently stand it just seems fairly happy middle solution
between: very concise narrow functionality requests and very verbose ways of
how they need to be done at the moment.
I fully appreciate how likely what I am proposing is going to be even
considered. But I really think it should be.
> On 17 Jul 2023, at 18:09, Rob Cliffe <rob.cli...@btinternet.com> wrote:
>
>
>
> On 15/07/2023 21:08, Dom Grigonis wrote:
>> Just to add. I haven’t thought about evaluation. Thus, to prevent evaluation
>> of unnecessary code, introduction of C-style expression is needed anyways:
>>> 1. result = bar is None ? default : bar
>>
>> The below would have to evaluate all arguments, thus not achieving benefits
>> of PEP505.
>>> 2. result = ifelse(bar is None, default, bar)
>>
>>
>> So I would vote for something similar to:
>>> result = bar is None ? default : bar
>>
>>
>> Where default and bar is only evaluated if needed. Although not to the
>> extent as initially intended, it would offer satisfiable solutions to
>> several proposals.
>>
> Well, default is only evaluated if needed; bar is always evaluated.
> What is wrong with the Python equivalent
>
> result = default if bar is None else bar
> or if you prefer
> result = bar if bar is not None else default
>
> Perhaps you didn't know about this construction?
> Best wishes
> Rob Cliffe
_______________________________________________
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/Q4HZ5ME6V473L25AV33BA6C7JMXTI2PJ/
Code of Conduct: http://python.org/psf/codeofconduct/
