Feature suggestion -- return if true

[Grant Edwards]

This is _not_ what I said.

Quoting from my earlier post:

"""

This syntax does not fit well within python ideology.


This could be simplified to just:

return expr or None
"""

You just said it again: that the OP's "return? expr" is the same as
"return exrp or None". It isn't. The OP's construct didn't return
if expr wasn't true. Your construt does.

Please read carefully before putting words in my mouth.

I wasn't putting words in your mouth. You said the same thing again
in the post to whic I'm replying.

I stated very clear y that return? expr didn't seem fitting
in the python ideology as syntax for this behavior.

I don't care about syntax. What you proposed doesn't have the same
_semantics_ as what the OP proposed.

 

[Grant Edwards]

The OP did not state this at all.
There was never any mention of early termination
of the function iif expr was True.

The OP said he wanted something with the semantics of

_temp_ = expr
if _temp_: return _temp_

That code snippet does not return if expr is false. What you proposed
returns None when expr is false.

 

[Grant Edwards]

Uggh come on guys. We've been over this.
You cannot make that assumption.

You most certain can. Try it yourself in an interpreter. The
OP's code snippit will not return if expr is false, rather it will
continue executing in the current context:
.... __temp__ = expr # these two lines are
.... if __temp__: return __temp__ # the OP's code snippet
.... print "the code snippet did not return"
....the code snippet did not return
None

 

[Colin J. Williams]

I'm puzzled as to why you seem to be parsing the OP's statements
different from everybody else. The only assumption that people other
than you seem to be making is that they are assuming that the OP meant
what he said. He *gave* a definition of what he meant by return? and
the definition he actually gave has the property that it terminates
the function only when the condition is true, whereas your suggested
translation *always* terminates the function call. I agree with
"Nobody" that the OP's intention was "abundantly clear". Your "return
expr or None" suggestion was not an unreasonable try - but it doesn't
provide something which is equivalent to what the OP gave. On the
other hand, your persistence in defending your original statement as a
plausible translation of return? after the difference has been pointed
out by various posters *is* starting to become unreasonable.

In my view, the suggestion would add complexity to the language without
sufficient benefit.

Colin W.

 

[Westley Martínez]

That's still not equivalent. "return expr or None" will always
terminate the function. The OP's request was for something which would
terminate the function if and only if expr is non-false.

Chris Angelico

def bs(x):
while not x:
<modify x>
return x

Am I wrong here?

 

[scattered]

def bs(x):
    while not x:
        <modify x>
    return x

Am I wrong here?- Hide quoted text -

- Show quoted text -

I don't think that this is equivalent. The OP's original idea doesn't
involve a loop, but this does - how could that be equivalent?

 

[Mel]

I'm trying to figure out a context where you'd even want that, and I'm
thinking that maybe it's some version of a repeat-until loop? Python
doesn't have repeat-until and it's been proposed a few times.

I can imagine

return? tree_node.left
return? tree_node.right

although my real code would probably be more like

if tree_node.left is not None:
return "left", tree_node.left
if tree_node.right is not None:
return "right", tree_node.right

where adding the "left" and "right" markers makes the return? feature
impossible to use.

The proposed feature reminds me of the `zod` function (was that the actual
name?) that returned 0 rather than bringing on a ZeroDivideError. It would
cement a strange corner-case into the language.

Mel.

 

[Teemu Likonen]

Maybe this is more appropriare for the python-ideas list ?


This syntax does not fit well within python ideology.

I'm a simple Lisp guy who wonders if it is be possible to add some kind
of macros to the language. Then features like this could be added by
anybody. Lisp people do this all the time and there is no need for
feature requests or any discussions.

(with-returns
;; some code
(return-if foo)
;; more code
(return-if bar))

 

[zildjohn01]

Wow. Two dozen replies, the majority of which are arguing over whether
the end of my snippet is reachable. I thought the behavior of if
statements was well-established by this point.

Regardless of James Mills's coding prowess, I suppose I should follow
his advice and repost this to the python-ideas list instead.

 

[Ian Kelly]

I'm a simple Lisp guy who wonders if it is be possible to add some kind
of macros to the language. Then features like this could be added by
anybody. Lisp people do this all the time and there is no need for
feature requests or any discussions.

   (with-returns
      ;; some code
      (return-if foo)
      ;; more code
      (return-if bar))

Flow-control macros were suggested as part of PEP 343, but they were
rejected by Guido based on this rant:

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/06/347666.aspx

 

[Paul Rudin]

I'm a simple Lisp guy who wonders if it is be possible to add some kind
of macros to the language...

As a (now somewhat lapsed) long-time lisp programmer I sympathise with
the sentiment, but suspect that it's not going to gain serious traction
in python circles.

 

[Ian Kelly]

Flow-control macros were suggested as part of PEP 343, but they were
rejected by Guido based on this rant:

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/06/347666.aspx

Sorry, that should have been PEP 340, which was rejected in favor of 343.

 

[Terry Reedy]

Wow. Two dozen replies, the majority of which are arguing over whether
the end of my snippet is reachable. I thought the behavior of if
statements was well-established by this point.

Regardless of James Mills's coding prowess, I suppose I should follow
his advice and repost this to the python-ideas list instead.

I would not. I am 99.99% sure both the syntax (introducing '?') and the
idea will be rejected.

 

[Neil Cerutti]

Flow-control macros were suggested as part of PEP 343, but they
were rejected by Guido based on this rant:

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/06/347666.aspx

Flow control macros don't seem to create problems that exceptions
didn't already create. Were context managers in existence at the
time?

 

[Neil Cerutti]

Flow control macros don't seem to create problems that
exceptions didn't already create. Were context managers in
existence at the time?

Oops! Exceedingly ignorant question considering the actual
content of PEP 343.

 

[James Mills]

Paraphrasing liberally from his review of Far Cry 2:
"Letting the [programmer] create their own [language constructs is]
always done at the expense of proper [orthogonality, elegance, and
coherence]. Maybe sometimes I don't want to create my own [programming
language] experience. Maybe I want to have an experience that's been
carefully crafted by professional [language] designers and
[architects]. But [a] delusion has arisen that absolutely anyone can
contribute something valid, regardless of qualifications. In TV news
for example, you'll often see them pause to hear the opinion of a
seventy-five-year-old housebound racist from Lemington. And now you
get [languages] like [Lisp] that rely heavily on user-made [language
constructs]. Which I prophesise doom for, because most people are not
[language] designers, and you're just going to end up with oceans of
slurry, as indeed we have. It's like giving someone a stack of paper
and a [pen] and claiming that that's as good as the latest [New York
Times] bestseller."

IOW, a language is usually better for having such discussions and
having a fairly coherent worldview enforced by the existence of a
managing authority.

Are we done with this discussion yet ?
*sigh* It was a slow day yesterday and I have
a funny feeling it's going to be the same today!

Regardless of anyone's subjective opinions as to what
was clear - I still stand by what I said.

Nice comments btw Chris

cheers
James

 

[Westley Martínez]

I don't think that this is equivalent. The OP's original idea doesn't
involve a loop, but this does - how could that be equivalent?

Not OP's idea, Angelico's.

 

[Chris Angelico]

Not OP's idea, Angelico's.

I didn't actually advocate a loop, but that method could work too. It
all depends on the actual code being executed. I'd still be in favour
of shor-circuit Or operators for this, although it does cost
readability.

Side point: Interesting that I'm referred to by surname here. Seems
there's a large number of people here named Chris - fits my theory
that geeks are often named Chris, and vice versa!

Chris Angelico
aka Rosuav

 

[Ethan Furman]

Are we done with this discussion yet ?
*sigh* It was a slow day yesterday and I have
a funny feeling it's going to be the same today!

Regardless of anyone's subjective opinions as to what
was clear - I still stand by what I said.

I think I see your point -- the OP said:
--> _temp = expr
--> if _temp: return _temp

which is where you're getting
--> return _temp or None

However, most everyone ('cept you, it seems! understood that there
would be more lines of code such that if bool(expr) == False no return
is executed and the function keeps going merrily along. Like this:
--> def func():
--> var1 = something()
--> var2 = something_else('this')
--> return? var1.hobgle(var2)
--> var3 = last_resort(var1)
--> return var3.wiglat(var2)


Looking back at the whole post now, I see nothing there to concretely
make that point except the question mark on the return.

Hope this helps.

~Ethan~

 

[James Mills]

I think I see your point -- the OP said:
-->    _temp = expr
-->    if _temp: return _temp

which is where you're getting
-->    return _temp or None

However, most everyone ('cept you, it seems! understood that there would
be more lines of code such that if bool(expr) == False no return is executed
and the function keeps going merrily along.  Like this:
--> def func():
-->     var1 = something()
-->     var2 = something_else('this')
-->     return? var1.hobgle(var2)
-->     var3 = last_resort(var1)
-->     return var3.wiglat(var2)


Looking back at the whole post now, I see nothing there to concretely make
that point except the question mark on the return.

Ethan I actually really appreciate your comments. Thank you!

Yes I do understand there is probably more code that
follows the return? - but I made an assumption and I'm
not going back on it

Thanks for making the two sides obviously clear!

cheers
James