Feature suggestion -- return if true

[zildjohn01]

This is an idea I've had bouncing around in my head for a long time
now. I propose the following syntax:

return? expr

be expanded to

_temp = expr
if _temp: return _temp

It's a pattern I use all the time in my code, and although it's a bit
unorthodox, IMO it's concise, readable, and easily understandable.

Thoughts?

 

[James Mills]

This is an idea I've had bouncing around in my head for a long time
now. I propose the following syntax:

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

   return? expr

This syntax does not fit well within python ideology.

be expanded to

   _temp = expr
   if _temp: return _temp

This could be simplified to just:

return expr or None

And more to the point... If your calee is relying
on the result of this function, just returning the
evaluation of "expr" is enough.

cheers
James

 

[Chris Angelico]

This could be simplified to just:

return expr or None

And more to the point... If your calee is relying
on the result of this function, just returning the
evaluation of "expr" is enough.

I'm thinking here that that's not a solution; he'll have more code to
follow. An example of what I think he's trying to do:

def fac(n):
# attempt to get from a cache
return? cache[n]
# not in cache, calculate the value
ret=1 if n<=1 else fac(n-1)*n
# and cache and return it
cache[n]=ret; return ret

If the rest of the function can be implemented as an expression, it
might be possible to use:

return expr or other_expr

But in the example of a lookup cache, that wouldn't work so easily -
assignment isn't an expression. If 'x=y' had a value as it does in C,
the above function could become:

def fac(n):
return cache[n] or (cache[n]=1 if n<=1 else fac(n-1)*n)

which is a reasonable one-liner, albeit not the most efficient
factorial implementation. Is there a simple and Pythonic way to do
this?

BTW, assume for the purposes of discussion that the return? expr is a
complex one, such that it's well worth evaluating only once (maybe
even has side effects).

Chris Angelico

 

[Chris Angelico]

def fac(n):
   return cache[n] or (cache[n]=1 if n<=1 else fac(n-1)*n)

Hmm. The function-call version of dictionary assignment IS legal in an
expression, but it's getting stupid...

def fac(n):
return cache.get(n) or (cache.__setitem__(n,1 if n<=1 else
fac(n-1)*n) or cache[n])

Chris Angelico

 

[Grant Edwards]

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


This syntax does not fit well within python ideology.


This could be simplified to just:

return expr or None

How is that the same?

return? something() return something() or None
return? somethingelse() return somethingelse() or None
log("didn't find an answer") log("didn't find an answer")
raise ValueError raise ValueError

Are you saying the two snippets above are equivalent?

 

[James Mills]

How is that the same?

 return? something()                  return something() or None
 return? somethingelse()              return somethingelse() or None
 log("didn't find an answer")         log("didn't find an answer")
 raise ValueError                     raise ValueError

Are you saying the two snippets above are equivalent?

def foo(n):
x = n < 5
if x:
return x

is functionally equivalent to:

def foo(n):
return n < 5

 

[Grant Edwards]

def foo(n):
x = n < 5
if x:
return x

is functionally equivalent to:

def foo(n):
return n < 5

That's not what I asked.

You stated that

return? <expr>

was equivalent to

return <expr> or None

If that was the case then the two code snippets _I_ posted should be
equivalent:

return? something() return something() or None
return? somethingelse() return somethingelse() or None
log("didn't find an answer") log("didn't find an answer")
raise ValueError raise ValueError

If the two snipped above are not equivalent, then

return? <expr>

is isn't equivalent to

return <expr> or None

 

[James Mills]

This is only true if n < 5.  Otherwise, the first returns None and the
second returns False.

Which is why I said:

return expr or None

But hey let's argue the point to death!

cheers
James

 

[Zero Piraeus]

:

Which is why I said:

return expr or None

But hey let's argue the point to death!

Ok ;-)

I think the point is that OP doesn't want to return *at all* if expr
is False - presumably because there are further statements after the
proposed 'conditional' return.

Anyway,

return? expr

isn't very pythonic - so how about one of these?

return expr if True
return expr else continue

I kid, I kid ...

-[]z.

 

[Chris Angelico]

Which is why I said:

return expr or None

But hey let's argue the point to death!

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

 

[James Mills]

You stated that

 return? <expr>

was equivalent to

 return <expr> or None

This is _not_ what I said.

Quoting from my earlier post:

"""

return? expr

This syntax does not fit well within python ideology.

be expanded to

_temp = expr
if _temp: return _temp

This could be simplified to just:

return expr or None
"""

Please read carefully before putting words in my mouth.

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

cheers
James

 

[Chris Angelico]

 return? expr

isn't very pythonic - so how about one of these?

 return expr if True
 return expr else continue

I kid, I kid ...

Or:

if expr:
return it

Actually, I'm not sure how stupid an idea that is. Inside an if, 'it'
is the value of the condition. Might actually be useful in a few
places.... Naw, I think it's still a stupid idea.

Chris Angelico

 

[James Mills]

I think the point is that OP doesn't want to return *at all* if expr
is False - presumably because there are further statements after the
proposed 'conditional' return.

If that's the case then we're all making assumptions
about what the OP intended. Perhaps OPs should be more
clear ?

kid!

cheers
James

 

[James Mills]

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.

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

Sorry :/ I'm not picking on your comprehension skills here
but you didn't read what the OP wrote (which he/she may not have
been clear about in the first place( nor what I said in reply.

Have a nice day,

cheers
James

 

[Nobody]

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

What the OP actually said was:

I propose the following syntax:

return? expr

be expanded to

_temp = expr
if _temp: return _temp

It should be abundantly clear that this only returns if the expression is
considered true, otherwise it continues on to the following statements.

 

[James Mills]

It should be abundantly clear that this only returns if the expression is
considered true, otherwise it continues on to the following statements.

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

cheers
James

 

[Paul Rubin]

_temp = expr
if _temp: return _temp

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.

 

[Steven D'Aprano]

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

The code snippet is absolutely clear. It is ordinary Python code:

_temp = expr
if _temp: return _temp

You should notice the lack of "else: return None" in that code snippet.

The only assumption being made is that the OP means what he says.

I suppose you can assume that he means something else if you like, but
then you have no possible way of knowing what he actually means ("well, I
*said* conditional return, but I *meant* BEGIN and END delimiters like in
Pascal...").

Personally, I like the idea of a conditional return, but I *hate* the
proposed syntax. But I don't think it's useful enough to deserve a new
keyword either.

 

[scattered]

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

cheers
James

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.

 

[John Roth]

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've wanted that a few times, frequently in a situation where I'm
doing validity checking, and I either want to continue after calling a
validity check or return immediately with some kind of error object.
For example:

returnif self.isitaboojum(snark)

This works nicely if the checking routine either returns False or an
error object.

It also works if the method is doing some kind of a ladder evaluation
of several distinct conditions, and it wants to return the first one
it finds.

Also, I wouldn't want a returnif in a loop. Following on with this
idea, loop control would be more of a breakif or continueif statement.

John Roth