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

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)

2023-07-18 Thread 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)

2023-07-18 Thread 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)

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

Maybe could be a part of https://peps.python.org/pep-0463/ 

Maybe if it was more expressive, e.g. covering the case such as you suggesting, 
it would go through?

Also, I still don't see why changing analogous statement order when making 
1-line expressions is a good idea.

E.g. there was a statement:
# Statement
try:
expression1
except Exception:
expression2
except Exception:
expression1
el
finally:
expression6
It’s analogous expression then could be:

val = try expr1() except Exception ? expr2() el finally expr5()

Simple if-else statement would be everything in between <> in both statement 
and expression.

Functional, consistent, expressive, in line with what is already there. Both 
“continue” and “break" would also be used in expressions same place as the 
statement. Maybe something else instead of “?”, but it doesn’t matter much to 
me, “?” would be just fine.

This would also partly cover my “rant” about C’s conditional expression. I.e. 
The order. Which probably has more weight in my aversion than it’s verbosity.

* Now argument that expressions read more naturally in this order raises a 
question "Why then isn’t it the same in statements?”.
* And argument that it’s easier for someone to learn without programming 
background also fails as even they would probably prefer “consistency" as 
opposed to "inconsistency, but 1 part reads like english."

I personally find it easier to learn when I understand and I understand when 
things make sense and follow patterns. Can it be that too much of this is being 
sacrificed for the sake of factors which are not as important?

> On 18 Jul 2023, at 09:08, Stephen J. Turnbull 
>  wrote:
> 
> David Mertz, Ph.D. writes:
> 
>> 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).
> 
> Aside: I think that's true for Pythonic scripting, but in general I
> think you're just as likely to find that it's a genuine choice, and
> that the condition is as interesting as either choice.
> 
> Variation on the theme of conditional expression: I'd often like to
> write
> 
>var = computed() if cond() else break
> 
> or
> 
>var = computed() if cond() else continue
> 
> I wonder if that syntax has legs, or if it's too cute to stand.
> 

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

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

2023-07-18 Thread 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)

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

2023-07-18 Thread Stephen J. Turnbull

David Mertz, Ph.D. writes:

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

Aside: I think that's true for Pythonic scripting, but in general I
think you're just as likely to find that it's a genuine choice, and
that the condition is as interesting as either choice.

Variation on the theme of conditional expression: I'd often like to
write

var = computed() if cond() else break

or

var = computed() if cond() else continue

I wonder if that syntax has legs, or if it's too cute to stand.

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

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

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)

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)

2023-07-17 Thread 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)

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)

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)


>> # 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)

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)

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

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)

2023-07-17 Thread 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

2023-07-17 Thread 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

2023-07-17 Thread 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: Conditional 1-line expression in python

2023-07-17 Thread 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