«

On 2011-04-12, James Mills <> wrote:
> 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
> """

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 grant.b.edwards Yow! I'd like MY data-base
at JULIENNED and stir-fried!
gmail.com

On 2011-04-12, James Mills <> wrote:
> 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.

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 grant.b.edwards Yow! Well, I'm INVISIBLE
at AGAIN ... I might as well
gmail.com pay a visit to the LADIES
ROOM ...

On 2011-04-12, 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.

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:

>>> def foo(expr):
.... __temp__ = expr # these two lines are
.... if __temp__: return __temp__ # the OP's code snippet
.... print "the code snippet did not return"
....
>>> print foo(9)
9
>>>
>>> print foo(0)
the code snippet did not return
None
>>>

--
Grant Edwards grant.b.edwards Yow! One FISHWICH coming
at up!!
gmail.com

On 12-Apr-11 06:55 AM, scattered wrote:
> 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.

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

Colin W.

On Tue, 2011-04-12 at 12:44 +1000, Chris Angelico wrote:
> On Tue, Apr 12, 2011 at 12:20 PM, James Mills
> <> wrote:
> > On Tue, Apr 12, 2011 at 12:18 PM, Jason Swails <> wrote:
> >> 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!
>
> 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?

On Apr 12, 10:05*am, Westley Martínez <aniko...@gmail.com> wrote:
> On Tue, 2011-04-12 at 12:44 +1000, Chris Angelico wrote:
> > On Tue, Apr 12, 2011 at 12:20 PM, James Mills
> > <prolo...@shortcircuit.net.au> wrote:
> > > On Tue, Apr 12, 2011 at 12:18 PM, Jason Swails <jason.swa...@gmail.com> wrote:
> > >> This is only true if n < 5. *Otherwise, the first returns None andthe
> > >> second returns False.
>
> > > 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
>
> 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?

Paul Rubin wrote:

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

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.

* 2011-04-12T10:27:55+10:00 * James Mills wrote:

> On Tue, Apr 12, 2011 at 9:17 AM, zildjohn01 <> wrote:
>> 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.

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

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.

On Tue, Apr 12, 2011 at 12:00 PM, Teemu Likonen <> wrote:
> 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/...06/347666.aspx