Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #3003 > unrolled thread

Feature suggestion -- return if true

Back to article view | Back to comp.lang.python

Contents

  Feature suggestion -- return if true zildjohn01 <zildjohn01@gmail.com> - 2011-04-11 16:17 -0700
    Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 10:27 +1000
      Re: Feature suggestion -- return if true Grant Edwards <invalid@invalid.invalid> - 2011-04-12 01:44 +0000
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 12:12 +1000
          Re: Feature suggestion -- return if true Grant Edwards <invalid@invalid.invalid> - 2011-04-12 02:18 +0000
            Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 12:44 +1000
              Re: Feature suggestion -- return if true Grant Edwards <invalid@invalid.invalid> - 2011-04-12 13:42 +0000
              Re: Feature suggestion -- return if true "Martin v. Loewis" <martin@v.loewis.de> - 2011-04-17 12:03 +0200
                Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-18 09:36 +1000
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 12:20 +1000
        Re: Feature suggestion -- return if true Zero Piraeus <schesis@gmail.com> - 2011-04-11 22:43 -0400
        Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-12 12:44 +1000
        Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-12 12:49 +1000
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 12:59 +1000
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 13:01 +1000
          Re: Feature suggestion -- return if true Nobody <nobody@nowhere.com> - 2011-04-12 07:08 +0100
            Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 16:21 +1000
              Re: Feature suggestion -- return if true Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-12 10:52 +0000
              Re: Feature suggestion -- return if true scattered <tooscattered@gmail.com> - 2011-04-12 03:55 -0700
                Re: Feature suggestion -- return if true "Colin J. Williams" <cjw@ncf.ca> - 2011-04-12 10:01 -0400
              Re: Feature suggestion -- return if true Grant Edwards <invalid@invalid.invalid> - 2011-04-12 13:50 +0000
          Re: Feature suggestion -- return if true Grant Edwards <invalid@invalid.invalid> - 2011-04-12 13:44 +0000
        Re: Feature suggestion -- return if true Westley Martínez <anikom15@gmail.com> - 2011-04-12 07:05 -0700
          Re: Feature suggestion -- return if true scattered <tooscattered@gmail.com> - 2011-04-12 07:58 -0700
            Re: Feature suggestion -- return if true Westley Martínez <anikom15@gmail.com> - 2011-04-12 15:45 -0700
            Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-13 08:52 +1000
          Re: Feature suggestion -- return if true zildjohn01 <zildjohn01@gmail.com> - 2011-04-12 11:25 -0700
            Re: Feature suggestion -- return if true Terry Reedy <tjreedy@udel.edu> - 2011-04-12 15:14 -0400
            Re: Feature suggestion -- return if true alex23 <wuwei23@gmail.com> - 2011-04-12 21:05 -0700
      Re: Feature suggestion -- return if true Teemu Likonen <tlikonen@iki.fi> - 2011-04-12 21:00 +0300
        Re: Feature suggestion -- return if true Ian Kelly <ian.g.kelly@gmail.com> - 2011-04-12 12:25 -0600
          Re: Feature suggestion -- return if true Neil Cerutti <neilc@norwich.edu> - 2011-04-12 20:13 +0000
            Re: Feature suggestion -- return if true Neil Cerutti <neilc@norwich.edu> - 2011-04-12 20:16 +0000
        Re: Feature suggestion -- return if true Ian Kelly <ian.g.kelly@gmail.com> - 2011-04-12 12:29 -0600
        Re: Feature suggestion -- return if true Paul Rudin <paul.nospam@rudin.co.uk> - 2011-04-12 19:28 +0100
        Re: Feature suggestion -- return if true Chris Rebert <clp2@rebertia.com> - 2011-04-12 13:26 -0700
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-13 08:34 +1000
        Re: Feature suggestion -- return if true Ethan Furman <ethan@stoneleaf.us> - 2011-04-12 16:06 -0700
          Re: Feature suggestion -- return if true Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-21 12:13 +0200
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-13 09:12 +1000
        Re: Feature suggestion -- return if true Westley Martínez <anikom15@gmail.com> - 2011-04-12 16:15 -0700
        Re: Feature suggestion -- return if true Ethan Furman <ethan@stoneleaf.us> - 2011-04-12 16:48 -0700
          Re: Feature suggestion -- return if true Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-13 00:03 +0000
            Re: Feature suggestion -- return if true Ethan Furman <ethan@stoneleaf.us> - 2011-04-12 19:42 -0700
            Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-13 13:00 +1000
            Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-13 13:28 +1000
        Re: Feature suggestion -- return if true Teemu Likonen <tlikonen@iki.fi> - 2011-04-13 13:58 +0300
    Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-12 10:46 +1000
      Re: Feature suggestion -- return if true Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-17 16:21 +1200
        Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-17 14:31 +1000
        Re: Feature suggestion -- return if true Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-17 08:45 +0000
          Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-17 19:07 +1000
            Re: Feature suggestion -- return if true Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-17 15:23 +0000
          Re: Feature suggestion -- return if true Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-18 12:25 +1200
          Re: Feature suggestion -- return if true Dave Angel <davea@ieee.org> - 2011-04-17 22:04 -0400
          Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-18 12:10 +1000
            Re: Feature suggestion -- return if true Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-19 12:35 +1200
              Re: Feature suggestion -- return if true Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-04-19 09:42 +0300
                Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-19 17:01 +1000
        Re: Feature suggestion -- return if true "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-04-17 08:33 -0400
          Re: Feature suggestion -- return if true Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-17 15:10 +0000
          Re: Feature suggestion -- return if true aahz@pythoncraft.com (Aahz) - 2011-04-18 09:11 -0700
        Re: Feature suggestion -- return if true Greg Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-18 11:09 +1200
    Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-12 10:51 +1000
    Re: Feature suggestion -- return if true Paul Rubin <no.email@nospam.invalid> - 2011-04-11 23:58 -0700
      Re: Feature suggestion -- return if true John Roth <johnroth1@gmail.com> - 2011-04-12 06:16 -0700
      Re: Feature suggestion -- return if true Mel <mwilson@the-wire.com> - 2011-04-12 11:12 -0400

Page 1 of 4  [1] 2 3 4  Next page →

#3003 — Feature suggestion -- return if true

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?

[toc] | [next] | [standalone]

#3008

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

> 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

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

[toc] | [prev] | [next] | [standalone]

#3012

On 2011-04-12, James Mills <prologic@shortcircuit.net.au> wrote:
> On Tue, Apr 12, 2011 at 9:17 AM, zildjohn01 <zildjohn01@gmail.com> 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.
>
>> be expanded to
>>
>> ?? ??_temp = expr
>> ?? ??if _temp: return _temp
>
> 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?

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#3013

On Tue, Apr 12, 2011 at 11:44 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> 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

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

[toc] | [prev] | [next] | [standalone]

#3014

On 2011-04-12, James Mills <prologic@shortcircuit.net.au> wrote:
> On Tue, Apr 12, 2011 at 11:44 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> 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

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

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#3018

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

[toc] | [prev] | [next] | [standalone]

#3045

On 2011-04-12, James Mills <prologic@shortcircuit.net.au> wrote:
> On Tue, Apr 12, 2011 at 12:18 PM, Grant Edwards <invalid@invalid.invalid> 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            

[toc] | [prev] | [next] | [standalone]

#3386

>> be expanded to
>>
>>    _temp = expr
>>    if _temp: return _temp
> 
> This could be simplified to just:
> 
> return expr or None
> """

No, it can't be simplified in this way.
If there is code after that snippet, then
it will get executed in the original version if _temp is
false, but won't get executed in your simplification.

Regards,
Martin

[toc] | [prev] | [next] | [standalone]

#3436

On Sun, Apr 17, 2011 at 8:03 PM, Martin v. Loewis <martin@v.loewis.de> wrote:
> No, it can't be simplified in this way.
> If there is code after that snippet, then
> it will get executed in the original version if _temp is
> false, but won't get executed in your simplification.

Martin, we've been over this! :) And you're a bit late...

You said it yourself "If there is code after that snippet"

cheers
James

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

[toc] | [prev] | [next] | [standalone]

#3015

On Tue, Apr 12, 2011 at 12:18 PM, Jason Swails <jason.swails@gmail.com> 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!

cheers
James

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

[toc] | [prev] | [next] | [standalone]

#3016

:

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

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.

[toc] | [prev] | [next] | [standalone]

#3017

On Tue, Apr 12, 2011 at 12:20 PM, James Mills
<prologic@shortcircuit.net.au> wrote:
> On Tue, Apr 12, 2011 at 12:18 PM, Jason Swails <jason.swails@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#3019

On Tue, Apr 12, 2011 at 12:43 PM, Zero Piraeus <schesis@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#3021

On Tue, Apr 12, 2011 at 12:43 PM, Zero Piraeus <schesis@gmail.com> 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"

[toc] | [prev] | [next] | [standalone]

#3022

On Tue, Apr 12, 2011 at 12:44 PM, Chris Angelico <rosuav@gmail.com> 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"

[toc] | [prev] | [next] | [standalone]

#3027

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.

[toc] | [prev] | [next] | [standalone]

#3028

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

[toc] | [prev] | [next] | [standalone]

#3039

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

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

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

[toc] | [prev] | [next] | [standalone]

#3040

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.

[toc] | [prev] | [next] | [standalone]

#3049

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web