"return if <expression>"
So yeah, we can "if <expression>: return", but why not? Examples: def some_function(a, b): return if a == b # That will return None return a * b print(some_function(2,2)) # None print(some_function(5,2)) # 10 def some_function_2(a, b): return if a > b or a == b return if a == 1 and b == 1 return a*b print(some_function_2(2,2)) # None print(some_function_2(1,1)) # None print(some_function_2(1,2)) # 2 print(some_function_2(5, 10)) # 50
On Wed, 17 Jun 2020 at 10:44, artem6191
So yeah, we can "if <expression>: return", but why not?
That's the wrong question. The correct question is "why is this needed, and is the need sufficiently pressing to justify the change to the language?" You're talking about allowing "return EXPR if CONDITION" as an exact equivalent of "if CONDITION: return EXPR". There isn't even a benefit of "it saves a line of code", so it's very hard to see a justification. Paul
On 17/06/2020 10:42, artem6191 wrote:
So yeah, we can "if <expression>: return", but why not?
Because without a decent reason otherwise, status quo ante wins. When I was writing a lot of Perl, I used the "<stmt> if <cond>;" form quite a lot to start with. Partly that was the novelty of it, part was that it reads naturally in English, and part was that I was used to writing ARM assembler (and I do mean ARM, not Thumb) so applying condition codes to every line was a natural if misdirected thing to me. Once the novelty wore off, I found I only used that form when the statement needed serious thought (usually because of a regex) and the condition was an afterthought. For anything I actually cared about, I wanted the visible structuring with line breaks and all. -- Rhodri James *-* Kynesim Ltd
On 6/17/20 5:42 AM, artem6191 wrote:
So yeah, we can "if <expression>: return", but why not?
From Pep 20 (The Zen) There should be one-- and preferably only one --obvious way to do it. We don't add a second way to do something just because we can, there needs to be some clear need that the existing way doesn't handle. -- Richard Damon
I love the do_stuff if cond syntax in Ruby and in perl. It's very natural to real, much more to follow than if cond: do_stuff But still I don't think that it is enough to demand a language change. Something near this is to have a default of none for A if B else None So we can ommit the else None part, but this goes against the explicit is better than implicit Em qua, 17 de jun de 2020 07:42, Paul Moore
On Wed, 17 Jun 2020 at 10:44, artem6191
wrote: So yeah, we can "if <expression>: return", but why not?
That's the wrong question. The correct question is "why is this needed, and is the need sufficiently pressing to justify the change to the language?"
You're talking about allowing "return EXPR if CONDITION" as an exact equivalent of "if CONDITION: return EXPR". There isn't even a benefit of "it saves a line of code", so it's very hard to see a justification.
Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/PHB2VW... Code of Conduct: http://python.org/psf/codeofconduct/
To read*
Em qui, 18 de jun de 2020 09:30, Daniel.
I love the do_stuff if cond syntax in Ruby and in perl. It's very natural to real, much more to follow than if cond: do_stuff
But still I don't think that it is enough to demand a language change.
Something near this is to have a default of none for
A if B else None
So we can ommit the else None part, but this goes against the explicit is better than implicit
Em qua, 17 de jun de 2020 07:42, Paul Moore
escreveu: On Wed, 17 Jun 2020 at 10:44, artem6191
wrote: So yeah, we can "if <expression>: return", but why not?
That's the wrong question. The correct question is "why is this needed, and is the need sufficiently pressing to justify the change to the language?"
You're talking about allowing "return EXPR if CONDITION" as an exact equivalent of "if CONDITION: return EXPR". There isn't even a benefit of "it saves a line of code", so it's very hard to see a justification.
Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/PHB2VW... Code of Conduct: http://python.org/psf/codeofconduct/
On 18 Jun 2020, at 13:30, Daniel.
wrote: I love the do_stuff if cond syntax in Ruby and in perl. It's very natural to real, much more to follow than if cond: do_stuff
I on the other hand hate that syntax and find it harder to read. Why put the code out of sequence? if read_this_1st: read_this_2nd() vs. this that I think of as out of sequence order read_this_2nd() if not read_this_1st Barry
But still I don't think that it is enough to demand a language change.
Something near this is to have a default of none for
A if B else None
So we can ommit the else None part, but this goes against the explicit is better than implicit
Em qua, 17 de jun de 2020 07:42, Paul Moore
mailto:p.f.moore@gmail.com> escreveu: On Wed, 17 Jun 2020 at 10:44, artem6191 mailto:artem129871@gmail.com> wrote: So yeah, we can "if <expression>: return", but why not?
That's the wrong question. The correct question is "why is this needed, and is the need sufficiently pressing to justify the change to the language?"
You're talking about allowing "return EXPR if CONDITION" as an exact equivalent of "if CONDITION: return EXPR". There isn't even a benefit of "it saves a line of code", so it's very hard to see a justification.
Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org mailto:python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org mailto:python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.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/PHB2VW... https://mail.python.org/archives/list/python-ideas@python.org/message/PHB2VW... Code of Conduct: http://python.org/psf/codeofconduct/ http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/WEK6CT... Code of Conduct: http://python.org/psf/codeofconduct/
This is very personal preference I don't feel it pythonic but... Ruby make
return keywork optional so is very idiomatic (in Ruby) to have multiple
onliner early return with this kind of guards at beginning of methods and a
"main" case below
For me this is just eye preference, we have eyes trained to extract what is
important when reading code. There is no absolute more readable that works
for everyone
IMHO return if cond is more scannable than
if cond:
return
Which need eye to scroll to next line
Here is an example of the use case that I'm talking about
def foo():
if a:
return
if B:
return
if C:
return
do_stuff()
Vs
def foo():
return if a
return if B
return if C
do_stuff
The second is much more compact
And
if A: return
Well, I'm strongly against these non-indented blocks in python
Em qui, 18 de jun de 2020 13:36, Barry Scott
On 18 Jun 2020, at 13:30, Daniel.
wrote: I love the do_stuff if cond syntax in Ruby and in perl. It's very natural to real, much more to follow than if cond: do_stuff
I on the other hand hate that syntax and find it harder to read.
Why put the code out of sequence?
if read_this_1st: read_this_2nd()
vs. this that I think of as out of sequence order
read_this_2nd() if not read_this_1st
Barry
But still I don't think that it is enough to demand a language change.
Something near this is to have a default of none for
A if B else None
So we can ommit the else None part, but this goes against the explicit is better than implicit
Em qua, 17 de jun de 2020 07:42, Paul Moore
escreveu: On Wed, 17 Jun 2020 at 10:44, artem6191
wrote: So yeah, we can "if <expression>: return", but why not?
That's the wrong question. The correct question is "why is this needed, and is the need sufficiently pressing to justify the change to the language?"
You're talking about allowing "return EXPR if CONDITION" as an exact equivalent of "if CONDITION: return EXPR". There isn't even a benefit of "it saves a line of code", so it's very hard to see a justification.
Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/PHB2VW... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/WEK6CT... Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, Jun 18, 2020 at 10:00 AM Daniel.
def foo(): if a: return if B: return if C: return
do_stuff()
Vs
def foo(): return if a return if B return if C do_stuff
The second is much more compact
is compact good ?!?
if A: return
Well, I'm strongly against these non-indented blocks in python
But why? you nseem to theink the more compact Ruby version is better, so why not the more compact Python version -- the only difference is a colon, and the order: def foo(): if a: return if B: return if C: return which is equally compact, and puts the "meat" of the code up front, which feels more clear and obvious to me. I do use this form myself, in just this situation, where there are multiple cases, and it is compact enough that the return doesn't get lost. That is, I would not do: if ( A and B) or (this > that) and (something in everything): return in that case, the return gets lost out at the end -- even if you don't go beyond 72 chars. anyway, even if it's a slight be more readable to some, it is not worth changing Python over. -CHB
Em qui, 18 de jun de 2020 13:36, Barry Scott
escreveu: On 18 Jun 2020, at 13:30, Daniel.
wrote: I love the do_stuff if cond syntax in Ruby and in perl. It's very natural to real, much more to follow than if cond: do_stuff
I on the other hand hate that syntax and find it harder to read.
Why put the code out of sequence?
if read_this_1st: read_this_2nd()
vs. this that I think of as out of sequence order
read_this_2nd() if not read_this_1st
Barry
But still I don't think that it is enough to demand a language change.
Something near this is to have a default of none for
A if B else None
So we can ommit the else None part, but this goes against the explicit is better than implicit
Em qua, 17 de jun de 2020 07:42, Paul Moore
escreveu: On Wed, 17 Jun 2020 at 10:44, artem6191
wrote: So yeah, we can "if <expression>: return", but why not?
That's the wrong question. The correct question is "why is this needed, and is the need sufficiently pressing to justify the change to the language?"
You're talking about allowing "return EXPR if CONDITION" as an exact equivalent of "if CONDITION: return EXPR". There isn't even a benefit of "it saves a line of code", so it's very hard to see a justification.
Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/PHB2VW... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/WEK6CT... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/3QILG6... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
it is not worth changing Python over.
I agreed here, is doesn't make that difference
Em qui, 18 de jun de 2020 14:25, Christopher Barker
On Thu, Jun 18, 2020 at 10:00 AM Daniel.
wrote: def foo(): if a: return if B: return if C: return
do_stuff()
Vs
def foo(): return if a return if B return if C do_stuff
The second is much more compact
is compact good ?!?
if A: return
Well, I'm strongly against these non-indented blocks in python
But why? you nseem to theink the more compact Ruby version is better, so why not the more compact Python version -- the only difference is a colon, and the order:
def foo(): if a: return if B: return if C: return
which is equally compact, and puts the "meat" of the code up front, which feels more clear and obvious to me.
I do use this form myself, in just this situation, where there are multiple cases, and it is compact enough that the return doesn't get lost. That is, I would not do:
if ( A and B) or (this > that) and (something in everything): return
in that case, the return gets lost out at the end -- even if you don't go beyond 72 chars.
anyway, even if it's a slight be more readable to some, it is not worth changing Python over.
-CHB
Em qui, 18 de jun de 2020 13:36, Barry Scott
escreveu: On 18 Jun 2020, at 13:30, Daniel.
wrote: I love the do_stuff if cond syntax in Ruby and in perl. It's very natural to real, much more to follow than if cond: do_stuff
I on the other hand hate that syntax and find it harder to read.
Why put the code out of sequence?
if read_this_1st: read_this_2nd()
vs. this that I think of as out of sequence order
read_this_2nd() if not read_this_1st
Barry
But still I don't think that it is enough to demand a language change.
Something near this is to have a default of none for
A if B else None
So we can ommit the else None part, but this goes against the explicit is better than implicit
Em qua, 17 de jun de 2020 07:42, Paul Moore
escreveu: On Wed, 17 Jun 2020 at 10:44, artem6191
wrote: So yeah, we can "if <expression>: return", but why not?
That's the wrong question. The correct question is "why is this needed, and is the need sufficiently pressing to justify the change to the language?"
You're talking about allowing "return EXPR if CONDITION" as an exact equivalent of "if CONDITION: return EXPR". There isn't even a benefit of "it saves a line of code", so it's very hard to see a justification.
Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/PHB2VW... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/WEK6CT... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/3QILG6... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
18.06.20 15:30, Daniel. пише:
I love the do_stuff if cond syntax in Ruby and in perl. It's very natural to real, much more to follow than if cond: do_stuff
But still I don't think that it is enough to demand a language change.
Something near this is to have a default of none for
A if B else None
So we can ommit the else None part, but this goes against the explicit is better than implicit
Only around 10% of "if" expressions have "else None" part. It is not enough to justify a new syntax (even if ignore other objections).
You can already do compact conditional returns with the current syntax:
def foo(a, b):
return (a != b or None) and a * b
or even:
foo = (lambda a, b: (a != b or None) and a * b)
both return:
foo(2, 5) # 10
foo(1, 1) # None
... but clarity would be better.
On Fri, Jun 19, 2020 at 4:20 AM Serhiy Storchaka
18.06.20 15:30, Daniel. пише:
I love the do_stuff if cond syntax in Ruby and in perl. It's very natural to real, much more to follow than if cond: do_stuff
But still I don't think that it is enough to demand a language change.
Something near this is to have a default of none for
A if B else None
So we can ommit the else None part, but this goes against the explicit is better than implicit
Only around 10% of "if" expressions have "else None" part. It is not enough to justify a new syntax (even if ignore other objections). _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/5E6JG6... Code of Conduct: http://python.org/psf/codeofconduct/
On 2020-06-20 02:22, Robert DeLanghe wrote:
You can already do compact conditional returns with the current syntax:
def foo(a, b): return (a != b or None) and a * b
or even:
foo = (lambda a, b: (a != b or None) and a * b)
both return:
foo(2, 5) # 10 foo(1, 1) # None
... but clarity would be better.
That can be written more clearly: def foo(a, b): return a * b if a != b else None
On Fri, Jun 19, 2020 at 4:20 AM Serhiy Storchaka
mailto:storchaka@gmail.com> wrote: 18.06.20 15:30, Daniel. пише: > I love the do_stuff if cond syntax in Ruby and in perl. It's very > natural to real, much more to follow than if cond: do_stuff > > But still I don't think that it is enough to demand a language change. > > Something near this is to have a default of none for > > A if B else None > > So we can ommit the else None part, but this goes against the explicit > is better than implicit
Only around 10% of "if" expressions have "else None" part. It is not enough to justify a new syntax (even if ignore other objections).
On Sat, 20 Jun 2020 at 04:02, MRAB
On 2020-06-20 02:22, Robert DeLanghe wrote:
You can already do compact conditional returns with the current syntax:
def foo(a, b): return (a != b or None) and a * b
or even:
foo = (lambda a, b: (a != b or None) and a * b)
both return:
foo(2, 5) # 10 foo(1, 1) # None
... but clarity would be better.
That can be written more clearly:
def foo(a, b): return a * b if a != b else None
I find the non-compact version to be clearer: def foo(a, b): if a != b: return a*b return None
On Fri, Jun 19, 2020 at 4:20 AM Serhiy Storchaka
mailto:storchaka@gmail.com> wrote: 18.06.20 15:30, Daniel. пише: > I love the do_stuff if cond syntax in Ruby and in perl. It's very > natural to real, much more to follow than if cond: do_stuff > > But still I don't think that it is enough to demand a language change. > > Something near this is to have a default of none for > > A if B else None > > So we can ommit the else None part, but this goes against the explicit > is better than implicit
Only around 10% of "if" expressions have "else None" part. It is not enough to justify a new syntax (even if ignore other objections).
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/J7TH3N... Code of Conduct: http://python.org/psf/codeofconduct/
participants (11)
-
artem6191
-
Barry Scott
-
Christopher Barker
-
Daniel.
-
MRAB
-
Paul Moore
-
Rhodri James
-
Richard Damon
-
Robert DeLanghe
-
Serhiy Storchaka
-
Vegard Stikbakke