> result = bar or default
I used to do this, but dropped this habit. Just to be on the safe side if in
the future I extend bar to take value for which truth test evaluates to False.
And for consistency across the codebase.
___
Python-ideas mailing
> I think that's reasonable. But I don't think Python is the language
> for that. There are too much existing contrasts, such as loop vs.
> comprehension and conditional statement vs. ternary expression. Guido
> deliberately chose to vary those expression syntaxes from their
> statement equival
On Thu, Jul 20, 2023, 01:19 Rob Cliffe via Python-ideas <
python-ideas@python.org> 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:
>
Dom Grigonis writes:
> The thing I am not content with (to make it common practice in my
> coding style) is inconsistencies between a) order of terms
> and b) functionality, of statements and their analogous
> expressions.
I think that's reasonable. But I don't think Python is the language
f
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 a
I understand.
As I have already said, I am not exactly proposing more terse if-else
expression. It’s just where I got to going down the path of several PEPs,
proposals and my own 'struggles’.
My point was more along the lines, that these are the examples, where several
users and PEP writers th
