[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)

[Chris Angelico]

On Tue, 18 Jul 2023 at 14:07, Dom Grigonis  wrote:
> PEP505 would solve this nicely, but it only applies to None and would not 
> apply to say user-defined sentinels and many other cases where permutations 
> of different conditionals arise.
>

PEP 671 would solve this nicely too.

ChrisA
___
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/R4HVE2MYZT7GJAB6SNKHW6UVC2G4OYYO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)

[Dom Grigonis]

Ok, thanks. I think what I am aiming at is that there is a pool of suggestions 
and PEPs that are pointing towards very similar direction and I find myself 
often wandering in the same space, just trying to figure out what it exactly is.

It sometimes feels more verbose than it could be for what it is in the context 
of how simple python is to use in general.

I am fully well aware that current if-else expression is not going anywhere. 
Chances that another expression is introduced, which does exactly the same 
thing are close to none.

So I am just gauging if it is a matter of conciseness of existing expressions 
or absence of something that could be there. Conditional if-else is just a 
place where I got to naturally. 

Got some useful references to PEPs, python history and opinions. Maybe it will 
become more clear in the future or maybe something new is already being worked 
that is going to fill the gap which I am not aware of.

I haven’t even started any proposal myself, I was just following e-mail 
requests and rejected PEPs that were mentioned here. Combined it with my own 
experience and this is where I got to.

Currently seems like it’s a dead end. Decision’s have been made, opinions taken 
into account, but I still have to write either:

a) awkward 1-liner
self.value = value if value is not None else DefaultClass()
b) 3 nicely readable lines with 1 unnecessary assignment.
self.value = value
if value is None:
self.value = DefaultClass()
c) 4 lines, no unnecessary assignments with excellent readability.
if value is None:
self.value = DefaultClass()
else:
self.value = value

The issue with b) and c) is that if I use those ones, my constructors become 
unbearably long and finally lead to the point where development becomes 
awkward. I would think that for what it does, it shouldn’t be more than 1 line. 
Max - 2. But a) is somewhat awkward. All (well not all, just several things) 
taken into account I ended up at inconvenience of `ifelse` expression, which 
would make a) my natural choice in this case. I am not even suggesting to 
introduce analogous `ifelse` with different syntax, just trying to get some 
ideas, references, opinions or alternatives that I don’t know about.

Maybe I need to spend some time on it and some solution will come out using 
existing python’s functionality or an idea which actually has a chance of being 
considered.

How would you write this? Doesn’t the below feel more verbose than it could be? 
Add 10 more constructor argument and there are 50 lines of code that do pretty 
much nothing. Not very pythonic…? One-line conditionals aren’t very readable 
(to me! I am aware that some might not feel this way) and for longer variable 
names sometimes don’t even fit into 80 characters.
def __init__(self,
 arg1=None,
 argument2=None,
 arg3foo=None,
 ...)
if arg1 is None:
self.arg1 = DefaultClass()
else:
self.arg1 = arg1
if argument2 is None:
self.argument2 = DefaultClass()
else:
self.argument2 = argument2
if arg3foo is None:
self.arg3foo = DefaultClass()
else:
self.arg3foo = arg3foo
...

PEP505 would solve this nicely, but it only applies to None and would not apply 
to say user-defined sentinels and many other cases where permutations of 
different conditionals arise.

Just want to stress out, that I know that this is something very primitive and 
might seem insubstantial to consider, but to me personally, solution to this 
would make a very big difference. I have been stuck on many such decisions of 
best practice and I have found satisfactory solutions to seemingly much more 
complex `problems` and am fairly happy having found optimal ways to do many 
different things in python - makes life easy. But this one is of very few that 
still bother me to this day. And it does seem related to certain queries that 
arise here.

So just trying to see what others think, etc, etc

Ok, I have been repeating myself for a bit, but from certain responses it felt 
like I have failed to convey where I am coming from. Or maybe no-one else has 
issue here, so if I am actually alone that is so bothered about this, it as 
also good information.

> On 18 Jul 2023, at 04:40, Greg Ewing  wrote:
> 
> On 18/07/23 10:30 am, Dom Grigonis wrote:
>> 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.
> 
> It's not overarching. Many things in Python don't read like English,
> and nobody is suggesting changing them to be more English-like.
> 
> I think you've got it backwards here. The fact that it reads like
> English is just a possible explanation of why many people find it more
> readable. The fact that people (well, just Guido at that time) find it
> readable is the reason it was chosen, not beause it's English-like.
> 
> -- 
> Greg
> 
> 

[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)

[Greg Ewing]

On 18/07/23 10:30 am, Dom Grigonis wrote:
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.


It's not overarching. Many things in Python don't read like English,
and nobody is suggesting changing them to be more English-like.

I think you've got it backwards here. The fact that it reads like
English is just a possible explanation of why many people find it more
readable. The fact that people (well, just Guido at that time) find it
readable is the reason it was chosen, not beause it's English-like.

--
Greg

___
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/ZVVK5APG2MI53UZB5NARI3FQMMLJRKCF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)

[Dom Grigonis]

Much of what you respond to me indicates that you did not properly read what I 
have written and did not really understand where I am coming from.

> On 18 Jul 2023, at 04:04, Chris Angelico  wrote:
> 
> On Tue, 18 Jul 2023 at 10:37, Dom Grigonis  wrote:
>> As opposed to
>> 
>> if a == 0:
>>   foo, bar = var1, variable2
>> else:
>>   foo, bar = default, default2
>> 
>> 
>> Again, one is `a == 0`, another is `b == 0`. I didn’t do a good job 
>> conveying this did I… Will try to be more precise and leave less room for 
>> misinterpretation.
> 
> Would you really go through and change all your variable names if it
> turns out that what you actually need is "a == 0" and "b == 15"? This
> sort of alignment is so fragile and unnecessary. Yes, it's nice when
> it works out, but it should never be a high priority.
> 
>> foo = foo3 if foo2 == 0 else default
>> bar = barbarbar if bar2 == 0 else default2
>> 
>> # As opposed to
>> 
>> foo = foo2 == 0 ? foo3 : default
>> bar = bar2 == 0 ? barbarbar : default2
> 
> Extremely artificial. You've shown that, if the conditions are the
> same lengths but the "if-true" expressions aren't, you can align them
> using ?: and can't align them using if-else. It's just as valid to
> show:
> 
> foo = "yes" if foo2 else "no"
> bar = "yes" if barbarbar else "no"
> 
> Like I said, extremely fragile.
> 
>> I don’t think it is that easy to draw the line here.
>> Everything in both of those PEPs can be expressed using current constructs. 
>> So maybe they are about more compact expressions?
> 
> "Can be expressed"? Well, yes. Python is Turing-complete. So is
> Brainf*. Doesn't mean we want to use it though.
> 
> Expressiveness is a spectrum or a scale. You can improve on it without
> the older version being impossible to write. In fact, Python really
> doesn't NEED all the syntax it has. Have a read of this series of blog
> posts:
> 
> https://snarky.ca/tag/syntactic-sugar/
> 
> (Brett Cannon also did a talk on this at PyCon US 2023; not sure if
> that's been made public yet.) There are only a handful of pieces of
> syntax that you really can't do without. But you CAN skip having an
> "if" statement. No kidding - you can eliminate the if statement by
> smart use of the while statement.
> https://snarky.ca/unravelling-if-statements/
> 
> Improvements to expressiveness allow us to write better code, to make
> it clearer what the *programmer's intent* is. Sometimes that aligns
> with compactness; sometimes it doesn't.
> 
>> Was python made for conciseness or expressiveness? Everything it does can 
>> already be done in C isn’t it? So I would argue any abstraction is really 
>> more about conciseness. Expressiveness is more about incorporation of what 
>> is already there, but not in the abstraction, i.e. extension. But python 
>> being interpreted language written in another language, I really FAIL to see 
>> how is all of this NOT about conciseness and modularity?
>> 
> 
> Expressiveness. It's about how well the source code represents the
> programmer's intent. You could write all of your code as a massive
> matrix of logic gates, but that wouldn't improve readability. And
> since you can implement logic gates with water - see
> https://www.youtube.com/watch?v=IxXaizglscw for proof - your program
> source code could be an acrylic sheet with a bunch of buckets glued
> onto it.
> 
> But none of us want to write code like that, and definitely none of us
> want to read code like that.
> 
> ChrisA
> ___
> 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/B5YRPPGSGQTAMM6WOKGULK2SKVR4H7KT/
> 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/HUTXYJC66CYJ7QCLZHEQNMYVUZHLVCQV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)

[Chris Angelico]

On Tue, 18 Jul 2023 at 10:37, Dom Grigonis  wrote:
> As opposed to
>
> if a == 0:
>foo, bar = var1, variable2
> else:
>foo, bar = default, default2
>
>
> Again, one is `a == 0`, another is `b == 0`. I didn’t do a good job conveying 
> this did I… Will try to be more precise and leave less room for 
> misinterpretation.

Would you really go through and change all your variable names if it
turns out that what you actually need is "a == 0" and "b == 15"? This
sort of alignment is so fragile and unnecessary. Yes, it's nice when
it works out, but it should never be a high priority.

> foo = foo3 if foo2 == 0 else default
> bar = barbarbar if bar2 == 0 else default2
>
> # As opposed to
>
> foo = foo2 == 0 ? foo3 : default
> bar = bar2 == 0 ? barbarbar : default2

Extremely artificial. You've shown that, if the conditions are the
same lengths but the "if-true" expressions aren't, you can align them
using ?: and can't align them using if-else. It's just as valid to
show:

foo = "yes" if foo2 else "no"
bar = "yes" if barbarbar else "no"

Like I said, extremely fragile.

> I don’t think it is that easy to draw the line here.
> Everything in both of those PEPs can be expressed using current constructs. 
> So maybe they are about more compact expressions?

"Can be expressed"? Well, yes. Python is Turing-complete. So is
Brainf*. Doesn't mean we want to use it though.

Expressiveness is a spectrum or a scale. You can improve on it without
the older version being impossible to write. In fact, Python really
doesn't NEED all the syntax it has. Have a read of this series of blog
posts:

https://snarky.ca/tag/syntactic-sugar/

(Brett Cannon also did a talk on this at PyCon US 2023; not sure if
that's been made public yet.) There are only a handful of pieces of
syntax that you really can't do without. But you CAN skip having an
"if" statement. No kidding - you can eliminate the if statement by
smart use of the while statement.
https://snarky.ca/unravelling-if-statements/

Improvements to expressiveness allow us to write better code, to make
it clearer what the *programmer's intent* is. Sometimes that aligns
with compactness; sometimes it doesn't.

> Was python made for conciseness or expressiveness? Everything it does can 
> already be done in C isn’t it? So I would argue any abstraction is really 
> more about conciseness. Expressiveness is more about incorporation of what is 
> already there, but not in the abstraction, i.e. extension. But python being 
> interpreted language written in another language, I really FAIL to see how is 
> all of this NOT about conciseness and modularity?
>

Expressiveness. It's about how well the source code represents the
programmer's intent. You could write all of your code as a massive
matrix of logic gates, but that wouldn't improve readability. And
since you can implement logic gates with water - see
https://www.youtube.com/watch?v=IxXaizglscw for proof - your program
source code could be an acrylic sheet with a bunch of buckets glued
onto it.

But none of us want to write code like that, and definitely none of us
want to read code like that.

ChrisA
___
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/B5YRPPGSGQTAMM6WOKGULK2SKVR4H7KT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)

[Dom Grigonis]

>> # Code becomes easily read when there is a nice alignment in horizontal 
>> space. e.g.:
>> 
>> variable = None
>> length_1 = None
>> somethin = None
>> 
> 
> variable = length_1 = somethin = None

Obviously they would not all be None, just chosen None as `any dummy value`, 
mistake on my part - None is not suitable for that.

>> 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
> 
> As opposed to
> 
> if a == 0:
>foo, bar = var1, variable2
> else:
>foo, bar = default, default2

Again, one is `a == 0`, another is `b == 0`. I didn’t do a good job conveying 
this did I… Will try to be more precise and leave less room for 
misinterpretation.
foo = foo3 if foo2 == 0 else default
bar = barbarbar if bar2 == 0 else default2

# As opposed to

foo = foo2 == 0 ? foo3 : default
bar = bar2 == 0 ? barbarbar : default2

>> 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.
> 
> Both of those are about *expressiveness*. This is not the same thing
> as compactness. The two do sometimes align but the purpose is
> different.

I don’t think it is that easy to draw the line here.
Everything in both of those PEPs can be expressed using current constructs. So 
maybe they are about more compact expressions?

Same as proposal regarding more expressive dict.get from which my train of 
thought has started.
Is it a request for:
a) more expressive dict.get?
b) more concise way do what can be done in a several lines of code anyways?

I just can’t see any substance that you are coming from with this…

Was python made for conciseness or expressiveness? Everything it does can 
already be done in C isn’t it? So I would argue any abstraction is really more 
about conciseness. Expressiveness is more about incorporation of what is 
already there, but not in the abstraction, i.e. extension. But python being 
interpreted language written in another language, I really FAIL to see how is 
all of this NOT about conciseness and modularity?

I agree that there are other dimensions, but I always thought python being 
closer to unix than windows...

> On 18 Jul 2023, at 03:08, Chris Angelico  wrote:
> 
> On Tue, 18 Jul 2023 at 08:34, Dom Grigonis  wrote:
>> 
>> 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.
>> 
> 
> You choose to go multi-line because the one-liner becomes less
> readable? Then that's a win for the current system. This is NOT a
> problem to be solved. Everything is working correctly. You have chosen
> the readable option over the compact one!
> 
>> # Code becomes easily read when there is a nice alignment in horizontal 
>> space. e.g.:
>> 
>> variable = None
>> length_1 = None
>> somethin = None
>> 
> 
> variable = length_1 = somethin = None
> 
>> # I often take this into account on variable name selection. Now:
> 
> Poor choice IMO. You could have had more consistent variable names by
> taking advantage of chained assignment.
> 
>> 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
> 
> As opposed to
> 
> if a == 0:
>foo, bar = var1, variable2
> else:
>foo, bar = default, default2
> 
>> 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.
> 
> Both of those are about *expressiveness*. This is not the same thing
> as compactness. The two do sometimes align but the purpose is
> different.
> 
>> 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...
>> 
> 
> Like I said, people who are *already familiar with* C's syntax find it
> more comfortable than those who are not.
> 
> But also - this ship has sailed. There's not a lot of point discussing
> this. If Python had decided against having any conditional expression,
> then maybe you could reopen 

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

On Tue, 18 Jul 2023 at 08:56, Dom Grigonis  wrote:
>
> Just to add, I think your statement actually works in my favour rather than 
> against my proposal.
>
> People from this group are potentially biased and lack objectivity against 
> what I am proposing because they are familiar with python and more 
> experienced ones participated in “carved in stone” decision regarding already 
> existent `ifelse` expression.
>

Of course we're biased. Everyone is biased. If you don't think you're
biased, you just haven't seen your biases yet. A few of mine:

* I have functional eyesight
* I have a US-English layout "qwerty" keyboard
* My internet connection, while decent, is not nearly as fast as some
* I spend many hours a day writing code (as opposed to a novice,
student, or very casual programmer, who all will have other
priorities)
* I use Linux exclusively and have no experience with Windows 11
* And yes, I know C. Also Ruby, Pike, JavaScript, and a ton of others.

Each of these affects my opinions of what's good and what's not. And
those are just the ones I could think of, off the top of my head. Some
of them I actively fight against; others I simply recognize (for
example, when people are discussing a change that would only affect
Windows users, I'll let other people judge, since I can't adequately
assess its impact).

> So I expected that my proposal might even look humorous to some. E.g. In 
> survey I got a comment “to learn python if I want to use it”. I am doing my 
> best, just some parts of it are hard to digest in the context of other parts 
> that are so easily digestible.
>

Humorous? Or just completely pointless? I don't think anyone here has
said that your proposal is a joke.

> Maybe this 20-year late discussion will have some impact on future python 
> expressions. E.g. some new expression will be a superset of `ifelse` and this 
> will be taken into account. Maybe not, but hopefully it had at least a bit of 
> positive value.
>

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

Yet again, an improvement in expressiveness, though not in compactness.

ChrisA
___
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/IO74FWNAU7FQEM646EDCMSLYEHR3SZBT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

On Tue, 18 Jul 2023 at 08:38, Dom Grigonis  wrote:
>
> > Was that really the intention? Because I was there when PEP 572 was
> > written, and I don't recall "beautiful one-liners" as one of the
> > justifying reasons. Use around if/while conditions was a strong
> > reason, and yes, that can save a line, but "beautiful one-liners"
> > hasn't generally been a justifying factor in any Python feature.
>
> Never said about the intention, just stated that I see it as being a part of 
> their construction.
>
> However, in the PEP you have referred and also as I remember reading python’s 
> “what’s new”, list comprehensions and other 1-liners were close to half of 
> all examples.
>

That is very true. Compactness makes for great "what's new" entries.
They want to be easily skimmable, which means they need to be short.
That's a constraint that isn't true of real-world code, and it WILL
cause the what's-new entries to be a bit nonrepresentative.

ChrisA
___
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/543NP3DE7NLWUYKYDII5DDLBOUV6MUJJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)

[Chris Angelico]

On Tue, 18 Jul 2023 at 08:34, Dom Grigonis  wrote:
>
> 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.
>

You choose to go multi-line because the one-liner becomes less
readable? Then that's a win for the current system. This is NOT a
problem to be solved. Everything is working correctly. You have chosen
the readable option over the compact one!

> # Code becomes easily read when there is a nice alignment in horizontal 
> space. e.g.:
>
> variable = None
> length_1 = None
> somethin = None
>

variable = length_1 = somethin = None

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

Poor choice IMO. You could have had more consistent variable names by
taking advantage of chained assignment.

> 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

As opposed to

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

> 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.

Both of those are about *expressiveness*. This is not the same thing
as compactness. The two do sometimes align but the purpose is
different.

> 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...
>

Like I said, people who are *already familiar with* C's syntax find it
more comfortable than those who are not.

But also - this ship has sailed. There's not a lot of point discussing
this. If Python had decided against having any conditional expression,
then maybe you could reopen the discussion (and I'll be honest, it
would have been reopened already by now); but we have a perfectly good
conditional expression, so the chances of getting a duplicate syntax
added are slim to Buckley's. Adding another way of writing the same
thing doesn't materially improve expressiveness.

ChrisA
___
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/DUPGM2O6WWC64XDIMVKJ6OUHTW7KQBM7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

What I meant is that it is not affected by prejudices to such a degree that a 
'challenger' wanted to make it look.

“I find it more readable” is a fair statement. The recognition of subjectivity 
is very transparent in it. In other words, such statement is not trying to be 
bigger than it actually is.

I realise that. I actually sometimes do use conditional `ifelse` and well aware 
of it’s existence. I am just trying to connect dots here.

Some proposals here are answered very clearly and in line with:
"There should be one-- and preferably only one --obvious way to do it.”

And some fall into category “there are workarounds, just deal with it". As I 
said, it seems that (at least to me) there is a big part of them that are 
pointing towards this direction - those that are confused about the elegant and 
simple way of doing certain simple things.

Maybe this 20-year late discussion will have some impact on future python 
expressions. E.g. some new expression will be a superset of `ifelse` and this 
will be taken into account. Maybe not, but hopefully it had at least a bit of 
positive value.

> On 18 Jul 2023, at 01:49, Christopher Barker  wrote:
> 
> On Tue, 18 Jul 2023 at 04:37, Dom Grigonis  > wrote:
> > This is why, I would dare to say that this preference of mine is not 
> > affected by prejudices.
> 
> Of course it's affected by prejudices -- all our preferences are. A sample of 
> one "I find it more readable" is about as useful as any sample of one to 
> represent a population.
> 
> Personally, I find the C syntax completely opaque and the Python syntax 
> totally understandable the first time I saw it -- and it's very much more 
> "Pythonic".
> 
> But that's influenced by my prejudice.
> 
> But anyway, this conversation is 20 (!) years too late[*] -- and it did take 
> place then. It's not going to change now.
> 
> -CHB
> 
> [*] https://peps.python.org/pep-0308/ 
> 
> 
> -- 
> Christopher Barker, PhD (Chris)
> 
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> 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/YQGA4KWF7G4I32GZNYLWQ2EIZOHMEZJY/
> 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/PXQRW6W5GMGOJSS7QJEYBQGBLAIYK274/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

Just to add, I think your statement actually works in my favour rather than 
against my proposal.

People from this group are potentially biased and lack objectivity against what 
I am proposing because they are familiar with python and more experienced ones 
participated in “carved in stone” decision regarding already existent `ifelse` 
expression. 

So I expected that my proposal might even look humorous to some. E.g. In survey 
I got a comment “to learn python if I want to use it”. I am doing my best, just 
some parts of it are hard to digest in the context of other parts that are so 
easily digestible.

> On 17 Jul 2023, at 21:37, Dom Grigonis  wrote:
> 
> This is NOT a good example, my first language was R, second - python, third 
> matlab, etc.
> 
> I only became familiar with C/C++ after several years of coding experience.
> 
> This is why, I would dare to say that this preference of mine is not affected 
> by prejudices.
> 
>> On 17 Jul 2023, at 20:44, Chris Angelico  wrote:
>> 
>> On Tue, 18 Jul 2023 at 03:13, Dom Grigonis  wrote:
>>> 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 is a REALLY good example of how hard it is to be objective about
>> syntax. Being familiar with something really truly does make it
>> immensely better - for you. You're comfortable with the C syntax.
>> That's great! So am I. But that isn't a good indication of how it
>> would be accepted by someone who isn't familiar with either syntax.
>> 
>> The ?: syntax has the advantage that the evaluation order is
>> left-to-right, which is the most common (though far from universal)
>> evaluation order. That is a definite advantage, to be sure, but
>> perhaps not as big as you might think. The if/else syntax is more
>> consistent with other Python syntax by using words, though.
>> 
>> Ultimately, *all* syntax has to be learned.
>> 
>> ChrisA
>> ___
>> 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/NGJ5GH6JXOZZLSTJT323F4TUEH5YXN3V/
>> 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/5IQM3DSGOF25Y4STSTAPHV2H2LBL4GC2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Christopher Barker]

On Tue, 18 Jul 2023 at 04:37, Dom Grigonis  wrote:

> > This is why, I would dare to say that this preference of mine is not
> affected by prejudices.
>

Of course it's affected by prejudices -- all our preferences are. A sample
of one "I find it more readable" is about as useful as any sample of one to
represent a population.

Personally, I find the C syntax completely opaque and the Python syntax
totally understandable the first time I saw it -- and it's very much more
"Pythonic".

But that's influenced by my prejudice.

But anyway, this conversation is 20 (!) years too late[*] -- and it did
take place then. It's not going to change now.

-CHB

[*] https://peps.python.org/pep-0308/


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/YQGA4KWF7G4I32GZNYLWQ2EIZOHMEZJY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

> Was that really the intention? Because I was there when PEP 572 was
> written, and I don't recall "beautiful one-liners" as one of the
> justifying reasons. Use around if/while conditions was a strong
> reason, and yes, that can save a line, but "beautiful one-liners"
> hasn't generally been a justifying factor in any Python feature.

Never said about the intention, just stated that I see it as being a part of 
their construction.

However, in the PEP you have referred and also as I remember reading python’s 
“what’s new”, list comprehensions and other 1-liners were close to half of all 
examples.

> On 18 Jul 2023, at 00:04, Chris Angelico  wrote:
> 
> On Tue, 18 Jul 2023 at 06:40, Dom Grigonis  wrote:
>> 
>> We even got a new operator “:=“ to help us with those beautiful one-liners 
>> (or not) to move towards aesthetics and brevity.
>> 
> 
> Was that really the intention? Because I was there when PEP 572 was
> written, and I don't recall "beautiful one-liners" as one of the
> justifying reasons. Use around if/while conditions was a strong
> reason, and yes, that can save a line, but "beautiful one-liners"
> hasn't generally been a justifying factor in any Python feature.
> 
> ChrisA
> ___
> 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/MJI5UNLOCJK4WTFBFNC2YFBE7PXHRAL7/
> 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/EIG4E2OCQONZVDOKJIABAQTPB44BJEIC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)

[Dom Grigonis]

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-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 :  else: )


> On 18 Jul 2023, at 00:36, Laurent Lyaudet  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,  a écrit :
>> 
>> Message: 2
>> Date: Mon, 17 Jul 2023 23:41:25 +0300
>> From: Dom Grigonis 
>> Subject: [Python-ideas] Conditional 1-line expression in python
>> To: python-ideas 
>> Message-ID: <31303e8b-05a4-408b-af4d-916f805b5...@gmail.com>

[Python-ideas] Re: Conditional 1-line expression in python

[Dom Grigonis]

A bit disappointing, but very much expected. I just though a bit of effort is 
worth even for 0.1% probability of success. At least from where I stand, such 
change would make a fairly big impact on the things I do, given my expected 
relationship with python.

I haven’t studied much of a history of python and I know how much I do not know.

I always let go when there is a conviction it is a right thing to do. :)

Thank you for your reply. PEPs that get referred to in this group are always 
informative to me.

Maybe I will spend some time going through PEPs to get a bit more familiar.

> On 18 Jul 2023, at 00:23, David Mertz, Ph.D.  wrote:
> 
> This ship has sailed and the ternary operator isn't going to change.  
> Seriously, let it go.
> 
> I forget the PEP, but this was well discussed long ago when the ternary was 
> added.  In general, Python prefers words to punctuation symbols for most of 
> its constructs.  So the decision was consistent with that.  I do believe that 
> such a choice is friendlier for people learning a first programming language, 
> since it resembles English prose.  While I like the C-style operator as well, 
> I think the Python version does the right thing by emphasizing the DEFAULT by 
> putting it first, and leaving the predicate and fallback until later in the 
> expression (right for Pythonic code, not right for other languages 
> necessarily).
> 
> Either way, the question is moot.
> 
> On Mon, Jul 17, 2023 at 4:42 PM Dom Grigonis  > wrote:
> 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 
> 
> Would be interesting to see if my preference is an outlier or not really.
> 
> 
> Kind regards,
> D. Grigonis
> 
> 
> ___
> 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/NZVLR56BFMBJXE6GN2GWRXIG6ZVAAWZZ/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 
> 
> 
> -- 
> The dead increasingly dominate and strangle both the living and the 
> not-yet born.  Vampiric capital and undead corporate persons abuse 
> the lives and control the thoughts of homo faber. Ideas, once born, 
> become abortifacients against new conceptions.

___
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/GWR63MIEGSRZTL2BU5MGQQUCTFZZIBG4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)

[Laurent Lyaudet]

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,  a écrit :
>
> Message: 2
> Date: Mon, 17 Jul 2023 23:41:25 +0300
> From: Dom Grigonis 
> Subject: [Python-ideas] Conditional 1-line expression in python
> To: python-ideas 
> 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 
>
> 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] Re: Conditional 1-line expression in python

[David Mertz, Ph.D.]

I found the original discussion about the ternary addition, FWIW:
https://mail.python.org/pipermail/python-dev/2005-September/056846.html.

I don't see myself participating in the discussion (maybe it's in a
different thread), but I'm delighted to remember that the message Guido
posted a couple hours earlier than that announcement was about a talk I
gave back then.

On Mon, Jul 17, 2023 at 5:23 PM David Mertz, Ph.D. 
wrote:

> This ship has sailed and the ternary operator isn't going to change.
> Seriously, let it go.
>
> I forget the PEP, but this was well discussed long ago when the ternary
> was added.  In general, Python prefers words to punctuation symbols for
> most of its constructs.  So the decision was consistent with that.  I do
> believe that such a choice is friendlier for people learning a first
> programming language, since it resembles English prose.  While I like the
> C-style operator as well, I think the Python version does the right thing
> by emphasizing the DEFAULT by putting it first, and leaving the predicate
> and fallback until later in the expression (right for Pythonic code, not
> right for other languages necessarily).
>
> Either way, the question is moot.
>
> On Mon, Jul 17, 2023 at 4:42 PM Dom Grigonis 
> wrote:
>
>> 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
>>
>> Would be interesting to see if my preference is an outlier or not really.
>>
>>
>> Kind regards,
>> D. Grigonis
>>
>>
>> ___
>> 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/NZVLR56BFMBJXE6GN2GWRXIG6ZVAAWZZ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/MPS2NUFKCNGL2CCOJ5K66FK2RXVJYNZO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python

[Oleg Broytman]

On Tue, Jul 18, 2023 at 07:09:54AM +1000, Chris Angelico  
wrote:
> On Tue, 18 Jul 2023 at 06:43, Dom Grigonis  wrote:
[skip]
> > https://q5yitzu62.supersurvey.com
> 
> Your second example needs a "both are abhorrently unreadable" option.

   +1

[skip]
> ChrisA

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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/ZTUMD42IEQX5ATX7TXUB4Y2PEKA74W3D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

> Never said C was your first language, only that you're familiar with
> it.

But that is more like an obvious fact about everything rather than a 
counter-argument. Your e-mail, at least how I interpreted it, was a fairly 
straight forward accent on my strong bias with a flavour of making it an 
example for everyone to note.

It would supposedly hold as an argument if I was used to C more than python, 
which would indicate my strong bias. While now, I am mostly interested in 
python and it’s long term trajectory, given I suspect I will be using it in 2 
or 3 years time. If I see a pseudocode of a non-existent language and I get an 
idea how to make python nicer, I will use it. But the argument that I am 
familiar with something that others are not is not really a counter-argument 
(to anything).

Except maybe serves to emphasise a general human aversion to change, which is 
naturally less for someone who is a bit familiar. So yes, I am less averse to 
such change because of 2 factors:
1. I am familiar with expression that I am proposing
2. This is my proposal

But neither 1 nor 2 are valid counter-arguments against what I am proposing.

And yes, 

> On 17 Jul 2023, at 23:57, Chris Angelico  wrote:
> 
> On Tue, 18 Jul 2023 at 04:37, Dom Grigonis  wrote:
>> 
>> This is NOT a good example, my first language was R, second - python, third 
>> matlab, etc.
>> 
>> I only became familiar with C/C++ after several years of coding experience.
>> 
>> This is why, I would dare to say that this preference of mine is not 
>> affected by prejudices.
>> 
> 
> Never said C was your first language, only that you're familiar with
> it. And that familiarity inevitably WILL affect your perception, as
> per what I said.
> 
> ChrisA
> ___
> 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/ZC2O5RFH6VC2IVJVV5IFA2YWQAH7XOH5/
> 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/XMZ3TUJKSKGIZKIGNDLKUD3JAYR4HUGL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python

[David Mertz, Ph.D.]

This ship has sailed and the ternary operator isn't going to change.
Seriously, let it go.

I forget the PEP, but this was well discussed long ago when the ternary was
added.  In general, Python prefers words to punctuation symbols for most of
its constructs.  So the decision was consistent with that.  I do believe
that such a choice is friendlier for people learning a first programming
language, since it resembles English prose.  While I like the C-style
operator as well, I think the Python version does the right thing by
emphasizing the DEFAULT by putting it first, and leaving the predicate and
fallback until later in the expression (right for Pythonic code, not right
for other languages necessarily).

Either way, the question is moot.

On Mon, Jul 17, 2023 at 4:42 PM Dom Grigonis  wrote:

> 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
>
> Would be interesting to see if my preference is an outlier or not really.
>
>
> Kind regards,
> D. Grigonis
>
>
> ___
> 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/NZVLR56BFMBJXE6GN2GWRXIG6ZVAAWZZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/GCHOB3V4X7Z766NHVI2V74EBXIBFHFDB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python

[Chris Angelico]

On Tue, 18 Jul 2023 at 06:43, Dom Grigonis  wrote:
>
> 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
>

Your second example needs a "both are abhorrently unreadable" option.
But if you've studied anything whatsoever about the history of the
conditional expression in Python, you would know that a survey is
actually pretty non-indicative here. We've already seen a much more
rigorous survey than this, and the results were preserved for
posterity.

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

ChrisA
___
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/FDN6ICOTIHOL7QWJS3CIZBXDQAEZ6MA7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

On Tue, 18 Jul 2023 at 06:40, Dom Grigonis  wrote:
>
> We even got a new operator “:=“ to help us with those beautiful one-liners 
> (or not) to move towards aesthetics and brevity.
>

Was that really the intention? Because I was there when PEP 572 was
written, and I don't recall "beautiful one-liners" as one of the
justifying reasons. Use around if/while conditions was a strong
reason, and yes, that can save a line, but "beautiful one-liners"
hasn't generally been a justifying factor in any Python feature.

ChrisA
___
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/MJI5UNLOCJK4WTFBFNC2YFBE7PXHRAL7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

On Tue, 18 Jul 2023 at 04:37, Dom Grigonis  wrote:
>
> This is NOT a good example, my first language was R, second - python, third 
> matlab, etc.
>
> I only became familiar with C/C++ after several years of coding experience.
>
> This is why, I would dare to say that this preference of mine is not affected 
> by prejudices.
>

Never said C was your first language, only that you're familiar with
it. And that familiarity inevitably WILL affect your perception, as
per what I said.

ChrisA
___
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/ZC2O5RFH6VC2IVJVV5IFA2YWQAH7XOH5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Conditional 1-line expression in python

[Dom Grigonis]

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 

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


Kind regards,
D. Grigonis


___
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/NZVLR56BFMBJXE6GN2GWRXIG6ZVAAWZZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

> 
> Why are we trying to write one-liners in the first place?  Conditional 
> expressions are a rare spice that should be used sparingly. No matter the 
> syntax, three of them nested together isn't readable code, it's a puzzle.
> 
Why are they a rare spice that should be used sparingly? Is it in line with 
python best practices? Anything to support this?

I think python list comprehensions is a direct antithesis to what you are 
saying. I thought they are considered to be a good and preferable practice, 
even nested cases.

We even got a new operator “:=“ to help us with those beautiful one-liners (or 
not) to move towards aesthetics and brevity.

Also, I disagree that the referred code isn’t readable. My point is exactly 
that such code is not readable and is a puzzle if current conditional 
expression is used. While having a more elegant if-else expression, this would 
not be a case.

Combination of list comprehensions, “:=“ operator and good conditional 1-liners 
could be an excellent toolkit to do complex things in simple, readable and 
brief manner. Now I think all is there, except if-else expression does not 
satisfy in either of those dimensions, namely brevity & readability (maybe it 
is better readable than C's for someone with major in languages…?).

So I am just trying to gauge if anyone else feels this way. 

As I already said, my code would look fairly differently if anything similar to 
what I am proposing existed.

And I do not have a bias towards C or C++, 99% of what I do is python so if 
anything I am biased towards how python does things, not the other way round.

Is there any place 


> On 17 Jul 2023, at 23:09, Ned Batchelder  wrote:
> 
> On 7/17/23 1:10 PM, Dom Grigonis wrote:
>> 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.
>> 
> Why are we trying to write one-liners in the first place?  Conditional 
> expressions are a rare spice that should be used sparingly. No matter the 
> syntax, three of them nested together isn't readable code, it's a puzzle.
> 
> --Ned.
> 
> 
> 
>> 
>> 
>> 
>> 
>>> On 17 Jul 2023, at 18:09, Rob Cliffe >> > 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/ 
>> 
> ___
> 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/IBDNP5LCVXRO5FXMCGD75J5OVO7BCGQW/
> 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/DD3RDWQVU7C6RQLKWJ6GNLHBYTFMYKJR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Ned Batchelder]

On 7/17/23 1:10 PM, Dom Grigonis wrote:

This whole thing started from dict’s `get` extension:
def  get_substitute(self, key, default=None, subs=()):
 return  keyin  self  ?  (self[key] :=  valin  subs?  subs[val] : val) : 
default
I dare you to do a 1-liner with current if-else.

Why are we trying to write one-liners in the first place? Conditional 
expressions are a rare spice that should be used sparingly. No matter 
the syntax, three of them nested together isn't readable code, it's a 
puzzle.


--Ned.








On 17 Jul 2023, at 18:09, Rob Cliffe  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 topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/Q4HZ5ME6V473L25AV33BA6C7JMXTI2PJ/
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/IBDNP5LCVXRO5FXMCGD75J5OVO7BCGQW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

This is NOT a good example, my first language was R, second - python, third 
matlab, etc.

I only became familiar with C/C++ after several years of coding experience.

This is why, I would dare to say that this preference of mine is not affected 
by prejudices.

> On 17 Jul 2023, at 20:44, Chris Angelico  wrote:
> 
> On Tue, 18 Jul 2023 at 03:13, Dom Grigonis  wrote:
>> 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 is a REALLY good example of how hard it is to be objective about
> syntax. Being familiar with something really truly does make it
> immensely better - for you. You're comfortable with the C syntax.
> That's great! So am I. But that isn't a good indication of how it
> would be accepted by someone who isn't familiar with either syntax.
> 
> The ?: syntax has the advantage that the evaluation order is
> left-to-right, which is the most common (though far from universal)
> evaluation order. That is a definite advantage, to be sure, but
> perhaps not as big as you might think. The if/else syntax is more
> consistent with other Python syntax by using words, though.
> 
> Ultimately, *all* syntax has to be learned.
> 
> ChrisA
> ___
> 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/NGJ5GH6JXOZZLSTJT323F4TUEH5YXN3V/
> 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/FEQF6QW4RPGTWUZWVHKE34ANJX5HOO73/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

On Tue, 18 Jul 2023 at 03:13, Dom Grigonis  wrote:
> 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 is a REALLY good example of how hard it is to be objective about
syntax. Being familiar with something really truly does make it
immensely better - for you. You're comfortable with the C syntax.
That's great! So am I. But that isn't a good indication of how it
would be accepted by someone who isn't familiar with either syntax.

The ?: syntax has the advantage that the evaluation order is
left-to-right, which is the most common (though far from universal)
evaluation order. That is a definite advantage, to be sure, but
perhaps not as big as you might think. The if/else syntax is more
consistent with other Python syntax by using words, though.

Ultimately, *all* syntax has to be learned.

ChrisA
___
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/NGJ5GH6JXOZZLSTJT323F4TUEH5YXN3V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[MRAB]

On 2023-07-17 18:10, Dom Grigonis wrote:


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=  (cif  celse  d)if  aelse  (dif  delse  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  keyin  self  ?  (self[key] :=  valin  subs?  subs[val] : val) : 
default

I dare you to do a 1-liner with current if-else.


def get_substitute(self, key, default=None, subs=()):
return (self[key] := subs[val] if val in subs else val) if key in 
self else default


Where does 'val' come from?

[snip]

___
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/ZSTKPJCB4TZCEE2UGPXT5QKLISGORPDK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

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