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

[Chris Angelico]

On Wed, 19 Jul 2023 at 11:51, Dom Grigonis  wrote:
>
> Coming back to deferred evaluation,
>
> https://peps.python.org/pep-0671/
> These 2 aren’t really orthogonal in functionality. Maybe in implementation.
> But PEP671 is a certain subset of deferred evaluation as it can achieve the 
> same with 1 extra line at the start of the function’s body.

No, it's not a subset of deferred evaluation, as has been stated
clearly in the PEP and discussed many times in the past.

Deferred evaluation is HARD. It's easy to handwave everything and
pretend that it magically gets evaluated at the exact right time, but
how do you actually define that? What are the scoping rules? Does it
create a closure?

Try creating an actual concrete specification and you may find out why
it hasn't been implemented yet.

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

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

[Dom Grigonis]

Coming back to deferred evaluation,

https://peps.python.org/pep-0671/ 
These 2 aren’t really orthogonal in functionality. Maybe in implementation.
But PEP671 is a certain subset of deferred evaluation as it can achieve the 
same with 1 extra line at the start of the function’s body.

--
Most importantly:
If deferred evaluation had a CONCISE keyword/operator, it would actually solve 
my (and several other) requests/proposals.
def ifelse(cond, if_true, if_false):
return if_true if cond else if_false

IF = ifelse


def __init__(self, a=None, b=None):
self.a = ifelse(a is not None, a, ?Foo())
self.b = IF(b is not None, b, `Bar()`)
hopefully it would not be `later`...

This way users could define their own constructs via callables & control order, 
evaluation and brevity to their liking.

--
https://peps.python.org/pep-0463/  could 
also be achieved with a function.
def trye(expr, err, default):
try:
return expr
except err:
return default

value = trye(`dct[key]`, KeyError, 'No Value')

--
https://peps.python.org/pep-0505/ 
def naw(a, b):
if a is not None:
return a
else:
return b

a = None
naw(a, `expr()`)

# OR Infix operator:
a |naw| `expr()`
It starts to seem that it would solve all of the things I was looking at to a 
satisfactory degree (given a concise keyword obviously...).

--
With certain additions, could even break & continue...
from statements import Break, Continue

def ifelsebc(cond, val, else_break=True):
if cond:
return val
elif else_break:
return `Break(0)`
else:
return `Continue(0)`

a = 0
while True:
a += ifelsebc(a < 5, 1, else_break=True)

print(a)# 5
The issue with lambda is that it has to be handled differently, or code has to 
check for its possibility, while deferred evaluation integrates seamlessly into 
already existing code.

IMO, it would be an excellent addition. And all this would come as a side 
effect, rather than main intent (which is dask.delay functionality if I 
understood correctly).

How likely you think is it going to happen? Given PEP number it doesn’t sound 
very promising...

> On 18 Jul 2023, at 09:45, Chris Angelico  wrote:
> 
> On Tue, 18 Jul 2023 at 16:25, Dom Grigonis  wrote:
>> 
>> Yes, thank you, this would definitely be nice to have.
>> 
>> Although, "A generic system for deferred evaluation has been proposed at 
>> times“ sound better if it was a superset of PEP505. Could you refer me to 
>> any resources about such considered system?
>> 
> 
> Hrm, you'd probably have to scour the archives. It's one of those
> things that comes up periodically and spawns a discussion thread, but
> never really gets to a concrete proposal. The best I can find is this,
> which never even got submitted to the official PEP repository, but
> it's someone's attempt to make something that could potentially become
> one, so it's a start.
> 
> https://github.com/DavidMertz/peps/blob/master/pep-.rst
> 
> The trouble is, it's really REALLY hard to pin down useful semantics
> for deferred evaluation. We already have lambda functions, which cover
> a lot of situations, leaving a lot of uncertainty as to what's being
> handled by this new proposal - and since no proposal ever truly comes
> from a single person, that results in a certain amount of chaos.
> 
> 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/YRGQV3U2GJFHYN2LXLW7PCP7MH22LFWI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Richard Damon]

On 7/18/23 12:03 AM, Dom Grigonis wrote:
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=  valueif  valueis  not  None  else  DefaultClass()
b) 3 nicely readable lines with 1 unnecessary assignment.
self.value=  value
if  valueis  None:
 self.value=  DefaultClass()


or, changing around:

if value is None:

    value = DefaultClass()

self.value = value


since the assignment is fundamental to the operation of the function, 
that is adding 2 lines to implement an optional default, which isn't 
that much to implement the feature.


it could be simplified to one line as

if value is None: value = DefaultClass()

(I think this is legal but against PEP8)



c) 4 lines, no unnecessary assignments with excellent readability.
if  valueis  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.

-


Richard Damon

___
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/TLOWSO7GPUPU4XW2GP6OOW3IN2NFVWCA/
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 19:02, Dom Grigonis  wrote:
>
> Thank you.
>
> I meant “superset of 671, not 505”…
>
> One question:
>
> def bar(a => None);
> return foo(a)
>
> def foo(a => object()):
> return a
>
> How would I force foo’s default from bar’s call?

That's a known-hard problem. The best way is probably to use *a,**kw
and only pass the args you get, but that doesn't always work.

> Would something like this work?
>
> def foo(a => object() if a is None else a):
> return a

Yyes, but now you're defining that a could be None, so you may as
well go with the classic idiom:

def foo(a=None):
if a is None: a = object()

The point of default argument expressions is that you DON'T need to
accept a fake default.

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

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

[Dom Grigonis]

Thank you.

I meant “superset of 671, not 505”…

One question:
def bar(a => None);
return foo(a)

def foo(a => object()):
return a
How would I force foo’s default from bar’s call?

Would something like this work?
def foo(a => object() if a is None else a):
return a


> On 18 Jul 2023, at 09:45, Chris Angelico  wrote:
> 
> On Tue, 18 Jul 2023 at 16:25, Dom Grigonis  wrote:
>> 
>> Yes, thank you, this would definitely be nice to have.
>> 
>> Although, "A generic system for deferred evaluation has been proposed at 
>> times“ sound better if it was a superset of PEP505. Could you refer me to 
>> any resources about such considered system?
>> 
> 
> Hrm, you'd probably have to scour the archives. It's one of those
> things that comes up periodically and spawns a discussion thread, but
> never really gets to a concrete proposal. The best I can find is this,
> which never even got submitted to the official PEP repository, but
> it's someone's attempt to make something that could potentially become
> one, so it's a start.
> 
> https://github.com/DavidMertz/peps/blob/master/pep-.rst
> 
> The trouble is, it's really REALLY hard to pin down useful semantics
> for deferred evaluation. We already have lambda functions, which cover
> a lot of situations, leaving a lot of uncertainty as to what's being
> handled by this new proposal - and since no proposal ever truly comes
> from a single person, that results in a certain amount of chaos.
> 
> 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/XCX54U7H7QWTGHEHUTHCPERW6LVAOUJT/
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 16:25, Dom Grigonis  wrote:
>
> Yes, thank you, this would definitely be nice to have.
>
> Although, "A generic system for deferred evaluation has been proposed at 
> times“ sound better if it was a superset of PEP505. Could you refer me to any 
> resources about such considered system?
>

Hrm, you'd probably have to scour the archives. It's one of those
things that comes up periodically and spawns a discussion thread, but
never really gets to a concrete proposal. The best I can find is this,
which never even got submitted to the official PEP repository, but
it's someone's attempt to make something that could potentially become
one, so it's a start.

https://github.com/DavidMertz/peps/blob/master/pep-.rst

The trouble is, it's really REALLY hard to pin down useful semantics
for deferred evaluation. We already have lambda functions, which cover
a lot of situations, leaving a lot of uncertainty as to what's being
handled by this new proposal - and since no proposal ever truly comes
from a single person, that results in a certain amount of chaos.

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

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

[Dom Grigonis]

Yes, thank you, this would definitely be nice to have.

Although, "A generic system for deferred evaluation has been proposed at times“ 
sound better if it was a superset of PEP505. Could you refer me to any 
resources about such considered system?

> On 18 Jul 2023, at 08:33, Chris Angelico  wrote:
> 
> 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 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/OUYIXJ5ZYQUXJBXR5U554YMKLVU6AAKB/
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 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: 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: 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)

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