«

On Tue, Apr 12, 2011 at 12:18 PM, Grant Edwards <> wrote:
> 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

--
-- James Mills
--
-- "Problems are solved by method"

On Tue, Apr 12, 2011 at 12:43 PM, Zero Piraeus <> wrote:
> *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

On Tue, Apr 12, 2011 at 12:43 PM, Zero Piraeus <> wrote:
> 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
--
-- "Problems are solved by method"

On Tue, Apr 12, 2011 at 12:44 PM, Chris Angelico <> wrote:
> 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

--
-- James Mills
--
-- "Problems are solved by method"

On Tue, 12 Apr 2011 13:01:43 +1000, James Mills wrote:

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

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.

On Tue, Apr 12, 2011 at 4:08 PM, Nobody <> wrote:
> 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


--
-- James Mills
--
-- "Problems are solved by method"

zildjohn01 <> writes:
> _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.

On Tue, 12 Apr 2011 16:21:43 +1000, James Mills wrote:

> On Tue, Apr 12, 2011 at 4:08 PM, Nobody <> wrote:
>> 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.

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.



--
Steven

On Apr 12, 2:21*am, James Mills <prolo...@shortcircuit.net.au> wrote:
> On Tue, Apr 12, 2011 at 4:08 PM, Nobody <nob...@nowhere.com> wrote:
> > 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
>
> --
> -- James Mills
> --
> -- "Problems are solved by method"

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.

On Apr 12, 12:58*am, Paul Rubin <no.em...@nospam.invalid> wrote:
> zildjohn01 <zildjoh...@gmail.com> writes:
> > * * _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.

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