Re: Feature suggestion -- return if true

[Ian Kelly]

On Mon, Aug 21, 2017 at 8:39 AM, alister via Python-list
 wrote:
> On Mon, 21 Aug 2017 05:44:53 -0700, jek wrote:
>> This is a very old post, but since I just though I would like a
>> conditional return like this, and checked for previous proposals, I
>> thought I'd give my opinion.
>>
>> Unfortunately only about 8 of the 67 replies actually answer the
>> question, and there isn't any overwhelming consensus to if a conditional
>> return would be good or not. Most (if not all) people dislike the syntax
>> though, and I agree.
>>
>> So, my proposal would be the syntax:
>>
>> return if 
>>
>> That is more pythonic than return?, does not involve a new keyword, and
>> is "human readable" in a way similar to e.g the ternary statement.
>>
>> //jek
>>
>> tue 12 apr 2011 zildjohn01 wrote:
>>> I propose the following syntax:
>>>
>>> return? expr
>>>
>>> be expanded to
>>>
>>> _temp = expr if _temp: return _temp
>>
>> As a side note, for the syntax of a cache, that was discussed a bit, I
>> sometimes to use:
>>
>> try:
>>   return cache[key]
>> except KeyError:
>>   ret = cache[key] = compute(key)
>>   return ret
>>
>> In my limited test it is a bit quicker than both "if x in cache" and
>> "v=cache.get(x)" (~ 0.9, 1.1 and 1.3 seconds) Though it might depend on
>> the hash complexity and the number of cache hits vs misses, so I guess
>> either syntax would do fine.
>
> how does this syntax enable you to specify the value to be returned?
> What new benefits would this addition provide beyond what is already
> available?

The value to be returned is the same as the value of the condition. In
my view that is the only benefit of this syntax: it provides a natural
way to specify that without evaluating the return value twice. If you
want to return a different value, there's already a great way to do
that:

if :
return 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[alister via Python-list]

On Mon, 21 Aug 2017 05:44:53 -0700, jek wrote:

> This is a very old post, but since I just though I would like a
> conditional return like this, and checked for previous proposals, I
> thought I'd give my opinion.
> 
> Unfortunately only about 8 of the 67 replies actually answer the
> question, and there isn't any overwhelming consensus to if a conditional
> return would be good or not. Most (if not all) people dislike the syntax
> though, and I agree.
> 
> So, my proposal would be the syntax:
> 
> return if 
> 
> That is more pythonic than return?, does not involve a new keyword, and
> is "human readable" in a way similar to e.g the ternary statement.
> 
> //jek
> 
> tue 12 apr 2011 zildjohn01 wrote:
>> I propose the following syntax:
>> 
>> return? expr
>> 
>> be expanded to
>> 
>> _temp = expr if _temp: return _temp
> 
> As a side note, for the syntax of a cache, that was discussed a bit, I
> sometimes to use:
> 
> try:
>   return cache[key]
> except KeyError:
>   ret = cache[key] = compute(key)
>   return ret
> 
> In my limited test it is a bit quicker than both "if x in cache" and
> "v=cache.get(x)" (~ 0.9, 1.1 and 1.3 seconds) Though it might depend on
> the hash complexity and the number of cache hits vs misses, so I guess
> either syntax would do fine.

how does this syntax enable you to specify the value to be returned?
What new benefits would this addition provide beyond what is already 
available?



-- 
My father was a saint, I'm not.
-- Indira Gandhi
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[jek]

This is a very old post, but since I just though I would like a conditional 
return like this, and checked for previous proposals, I thought I'd give my 
opinion.

Unfortunately only about 8 of the 67 replies actually answer the question, and 
there isn't any overwhelming consensus to if a conditional return would be good 
or not. Most (if not all) people dislike the syntax though, and I agree.

So, my proposal would be the syntax:

return if 

That is more pythonic than return?, does not involve a new keyword, and is 
"human readable" in a way similar to e.g the ternary statement.

//jek

tue 12 apr 2011 zildjohn01 wrote:
> I propose the following syntax:
> 
> return? expr
> 
> be expanded to
> 
> _temp = expr
> if _temp: return _temp

As a side note, for the syntax of a cache, that was discussed a bit, I 
sometimes to use:

try:
  return cache[key]
except KeyError:
  ret = cache[key] = compute(key)
  return ret

In my limited test it is a bit quicker than both "if x in cache" and 
"v=cache.get(x)" (~ 0.9, 1.1 and 1.3 seconds) Though it might depend on the 
hash complexity and the number of cache hits vs misses, so I guess either 
syntax would do fine.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Thomas Rachel]

Am 13.04.2011 01:06, schrieb Ethan Furman:


-- def func():
-- var1 = something()
-- var2 = something_else('this')
-- return? var1.hobgle(var2)
-- var3 = last_resort(var1)
-- return var3.wiglat(var2)


This makes me think of a decorator which can mimic the wantend behaviour:

def getfirst(f):
from functools import wraps
@wraps(f)
def func(*a, **k):
for i in f(*a, **k):
if i: return i
return func

# [BTW: a kind of return decorator would be nice here ;-)]

@getfirst
def func():
var1 = something()
var2 = something_else('this')
yield var1.hobgle(var2)
var3 = last_resort(var1)
yield var3.wiglat(var2)
yield Even that did not work.

This has the advantage of being flexible about which condition to 
evaluate: maybe the func does return tuples of which only the 2nd part 
is relevant concerning the check. Then just do



def getfirst(f):
from functools import wraps
@wraps(f)
def func(*a, **k):
for i in f(*a, **k):
if i[1]: return i
return func

@getfirst
def func():
var1 = something()
var2 = something_else('this')
yield first try, var1.hobgle(var2)
var3 = last_resort(var1)
yield second try, var3.wiglat(var2)
yield default value, Even that did not work.


Disclaimer: Untested, but you should get the idea.

Thomas
--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Jussi Piitulainen]

Gregory Ewing writes:
 Chris Angelico wrote:
 
  Question: How many factorial functions are implemented because a
  program needs to know what n! is, and how many are implemented to
  demonstrate recursion (or to demonstrate the difference between
  iteration and recursion)? :)

(I can't get to the parent directly, so I follow up indirectly.)

Factorials become an interesting demonstration of recursion when done
well. There's a paper by Richard J. Fateman, citing Peter Luschny:

http://www.cs.berkeley.edu/~fateman/papers/factorial.pdf
http://www.luschny.de/math/factorial/FastFactorialFunctions.htm

Fateman's major conclusion is that you should probably not use the
'naive' factorial programs for much of anything. I take this to
include their use as examples of recursion, unless the purpose is to
make the idea of recursion look bad.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Angelico]

On Tue, Apr 19, 2011 at 4:42 PM, Jussi Piitulainen
jpiit...@ling.helsinki.fi wrote:
 Factorials become an interesting demonstration of recursion when done
 well. There's a paper by Richard J. Fateman, citing Peter Luschny:

 http://www.cs.berkeley.edu/~fateman/papers/factorial.pdf
 http://www.luschny.de/math/factorial/FastFactorialFunctions.htm

 Fateman's major conclusion is that you should probably not use the
 'naive' factorial programs for much of anything. I take this to
 include their use as examples of recursion, unless the purpose is to
 make the idea of recursion look bad.


And here is an algorithm which nobody needs, for the Simple-Minded only:
long factorial(long n) { return n = 1 ? 1 : n * factorial(n-1); }  Do
not use it if n  12.


I suppose the n  12 issue is based on the assumption that
sizeof(long)==4. That's not an algorithmic question, that's a return
type issue... not to mention a rather naive assumption. 64-bit
integers let you go to n == 20 (iirc), and if you go bignum, even that
simple algorithm will be fine for up to n == 500 or so without stack
issues.

But sometimes you need a simple and well-known algorithm to
demonstrate a language feature with. Maybe we should switch to
Fibonacci instead... Anyone for caramel sauce?

http://www.dangermouse.net/esoteric/chef_fib.html

(As a side point, I have become somewhat noted around the house for
always saying Fibonacci whenever caramel sauce is mentioned...)

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Aahz]

In article mailman.461.1303043638.9059.python-l...@python.org,
D'Arcy J.M. Cain da...@druid.net wrote:
On Sun, 17 Apr 2011 16:21:53 +1200
Gregory Ewing greg.ew...@canterbury.ac.nz wrote:
 My idiom for fetching from a cache looks like this:
 
def get_from_cache(x):
  y = cache.get(x)
  if not y:
y = compute_from(x)
cache[x] = y
  return y

I prefer not to create and destroy objects needlessly.

 def get_from_cache(x):
   if not x in cache:
 cache[x] = compute_from(x)
   return cache[x]

Aside from Steven's entirely appropriate pointed question, I find this
more readable:

if x not in cache:

Without testing, I'm not sure, but I believe it's more efficient, too
(creates fewer bytecodes).
-- 
Aahz (a...@pythoncraft.com)   * http://www.pythoncraft.com/

At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-03-22
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Gregory Ewing]

Chris Angelico wrote:


Question: How many factorial functions are implemented because a
program needs to know what n! is, and how many are implemented to
demonstrate recursion (or to demonstrate the difference between
iteration and recursion)? :)


A related question is how often factorial functions are even
*used* in real code.

I can think of two uses for factorials off the top of my
head:

* Coefficients of polynomials resulting from Taylor expansions.
In that case you probably have a loop that's calculating the
numerators and denominators iteratively, and the factorial
is folded into that. Or you're looking up the coefficients in
a table and not calculating factorials at all.

* Combinations and permutations -- again, the factorials are
probably folded into a loop that calculates the result in a
more direct and efficient way.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Steven D'Aprano]

On Sun, 17 Apr 2011 16:21:53 +1200, Gregory Ewing wrote:

 Chris Angelico wrote:
 
 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
 
 My idiom for fetching from a cache looks like this:
 
def get_from_cache(x):
  y = cache.get(x)
  if not y:
y = compute_from(x)
cache[x] = y
  return y
 
 which doesn't require any conditional returns.


I'm sure you realise that that snippet needlessly recalculates any cached 
result that happens to be false, but others reading might not.

If the compute_from function is expensive (and it better be, otherwise 
why are you bothering with a cache?), that could be expensive:

compute_from = is_prime_number
get_from_cache(253590421923456781012937340348512751108342137327 *
   195789732345627381015532937340363481051277321451)

:)

A better way is to explicitly test for the sentinel:

y = cache.get(x)
if y is not None:
...




-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Angelico]

On Sun, Apr 17, 2011 at 6:45 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 On Sun, 17 Apr 2011 16:21:53 +1200, Gregory Ewing wrote:

 Chris Angelico wrote:

 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

 My idiom for fetching from a cache looks like this:

    def get_from_cache(x):
      y = cache.get(x)
      if not y:
        y = compute_from(x)
        cache[x] = y
      return y

 which doesn't require any conditional returns.


 I'm sure you realise that that snippet needlessly recalculates any cached
 result that happens to be false, but others reading might not.

Sure. In my (somewhat contrived) example of factorials, that's going
to be true (apart from 0! = 0); and if the function returns a string
or other object rather than an integer, same thing. If there's the
possibility of _ANY_ value coming back from the computation, then it
would need to be done as:

if x in cache: return cache[x]

or as:

try:
  return cache[x]
except KeyError:
  # calculate etc

Obviously, as with everything, you need to know your own code and your own data.

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Martin v. Loewis]

 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[D'Arcy J.M. Cain]

On Sun, 17 Apr 2011 16:21:53 +1200
Gregory Ewing greg.ew...@canterbury.ac.nz wrote:
 My idiom for fetching from a cache looks like this:
 
def get_from_cache(x):
  y = cache.get(x)
  if not y:
y = compute_from(x)
cache[x] = y
  return y

I prefer not to create and destroy objects needlessly.

 def get_from_cache(x):
   if not x in cache:
 cache[x] = compute_from(x)
   return cache[x]

-- 
D'Arcy J.M. Cain da...@druid.net |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Steven D'Aprano]

On Sun, 17 Apr 2011 08:33:47 -0400, D'Arcy J.M. Cain wrote:

 On Sun, 17 Apr 2011 16:21:53 +1200
 Gregory Ewing greg.ew...@canterbury.ac.nz wrote:
 My idiom for fetching from a cache looks like this:
 
def get_from_cache(x):
  y = cache.get(x)
  if not y:
y = compute_from(x)
cache[x] = y
  return y
 
 I prefer not to create and destroy objects needlessly.
 
  def get_from_cache(x):
if not x in cache:
  cache[x] = compute_from(x)
return cache[x]

What object(s) do you think are being created and destroyed needlessly?

(This is not a rhetorical question.)


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Steven D'Aprano]

On Sun, 17 Apr 2011 19:07:03 +1000, Chris Angelico wrote:

 If there's the
 possibility of _ANY_ value coming back from the computation, then it
 would need to be done as:
 
 if x in cache: return cache[x]

Or you can create a sentinel value that is guaranteed to never appear 
anywhere else:


SENTINEL = object()
obj = cache.get(x, SENTINEL)
if obj is SENTINEL:
   obj = calculate(x)
   cache[x] = obj
return obj

You can create the sentinel once, at the start of your program, rather 
than each time.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Greg Ewing]

D'Arcy J.M. Cain wrote:

On Sun, 17 Apr 2011 16:21:53 +1200
Gregory Ewing greg.ew...@canterbury.ac.nz wrote:


  def get_from_cache(x):
y = cache.get(x)
if not y:
  y = compute_from(x)
  cache[x] = y
return y


I prefer not to create and destroy objects needlessly.


How does that create objects needlessly?


 def get_from_cache(x):
   if not x in cache:
 cache[x] = compute_from(x)
   return cache[x]


That looks up the cache *twice* for every access. Mine
only does one lookup when the item is already in the
cache.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

On Sun, Apr 17, 2011 at 8:03 PM, Martin v. Loewis mar...@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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Gregory Ewing]

Steven D'Aprano wrote:

I'm sure you realise that that snippet needlessly recalculates any cached 
result that happens to be false, but others reading might not.


I only use it as written when I'm dealing with types that
don't have false values. If I did need to cache such a
type, I would use a different test, such as 'if y is None'.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Dave Angel]

On 01/-10/-28163 02:59 PM, Chris Angelico wrote:

 snip

Sure. In my (somewhat contrived) example of factorials, that's going
to be true (apart from 0! = 0); and if the function returns a string
or other object rather than an integer, same thing. If there's the


Just to be pedantic, by any reasonable definition, 0! == one, not zero.

One reference:  http://en.wikipedia.org/wiki/Factorial
3rd sentence.

More interestingly, There is a gamma function defined for lots of real 
and complex numbers, which for all non-negative integers matches the 
factorial:


   gamma(n) = (n-1)!

The gamma function has the same value (1) for one and two, so to be 
consistent, factorial should have that value for both zero and one.


DaveA
--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Angelico]

On Mon, Apr 18, 2011 at 12:04 PM, Dave Angel da...@ieee.org wrote:
 On 01/-10/-28163 02:59 PM, Chris Angelico wrote:

  snip

 Sure. In my (somewhat contrived) example of factorials, that's going
 to be true (apart from 0! = 0); and if the function returns a string
 or other object rather than an integer, same thing. If there's the

 Just to be pedantic, by any reasonable definition, 0! == one, not zero.

 One reference:  http://en.wikipedia.org/wiki/Factorial
 3rd sentence.

Hm! I never thought to check the definition... I just coded it up
quickly, and didn't even consider the possibility of a zero return
until the cache's loophole was challenged. Guess with a more correct
definition of factorial, it's even safer in the cache.

Question: How many factorial functions are implemented because a
program needs to know what n! is, and how many are implemented to
demonstrate recursion (or to demonstrate the difference between
iteration and recursion)? :)

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Gregory Ewing]

Chris Angelico wrote:


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


My idiom for fetching from a cache looks like this:

  def get_from_cache(x):
y = cache.get(x)
if not y:
  y = compute_from(x)
  cache[x] = y
return y

which doesn't require any conditional returns.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Angelico]

On Sun, Apr 17, 2011 at 2:21 PM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
 My idiom for fetching from a cache looks like this:

  def get_from_cache(x):
    y = cache.get(x)
    if not y:
      y = compute_from(x)
      cache[x] = y
    return y

 which doesn't require any conditional returns.

There's not a lot of difference between conditionally returning and
conditionally executing all the code between here and the return,
except that when you string three conditional returns together by your
method, it gets three indentations.

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Teemu Likonen]

* 2011-04-12T13:26:48-07:00 * Chris Rebert wrote:

 I think Ben Yahtzee Croshaw's comments on open-world sandbox video
 games (of all things) have a lot of applicability to why allowing
 full-on macros can be a bad idea.

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

Thanks for the info. That's a strange view, and I must disagree. Lisp
people certainly love the power they have. But different language,
different philosophy, I guess.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Nobody]

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.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Paul Rubin]

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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Steven D'Aprano]

On Tue, 12 Apr 2011 16:21:43 +1000, James Mills 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.

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[scattered]

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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[John Roth]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Grant Edwards]

On 2011-04-12, James Mills prolo...@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.edwardsYow! I'd like MY data-base
  at   JULIENNED and stir-fried!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Grant Edwards]

On 2011-04-12, James Mills prolo...@shortcircuit.net.au wrote:
 On Tue, Apr 12, 2011 at 12:44 PM, Chris Angelico ros...@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.

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.edwardsYow! Well, I'm INVISIBLE
  at   AGAIN ... I might as well
  gmail.compay a visit to the LADIES
   ROOM ...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Grant Edwards]

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

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.edwardsYow! One FISHWICH coming
  at   up!!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Colin J. Williams]

On 12-Apr-11 06:55 AM, scattered wrote:

On Apr 12, 2:21 am, James Millsprolo...@shortcircuit.net.au  wrote:

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



--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Westley Martínez]

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[scattered]

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 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?- 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?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Mel]

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Teemu Likonen]

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

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

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))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Ian Kelly]

On Tue, Apr 12, 2011 at 12:00 PM, Teemu Likonen tliko...@iki.fi 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/archive/2005/01/06/347666.aspx
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Ian Kelly]

On Tue, Apr 12, 2011 at 12:25 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Tue, Apr 12, 2011 at 12:00 PM, Teemu Likonen tliko...@iki.fi 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/archive/2005/01/06/347666.aspx

Sorry, that should have been PEP 340, which was rejected in favor of 343.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Paul Rudin]

Teemu Likonen tliko...@iki.fi writes:

 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Terry Reedy]

On 4/12/2011 2:25 PM, zildjohn01 wrote:

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.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Neil Cerutti]

On 2011-04-12, Ian Kelly ian.g.ke...@gmail.com wrote:
 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Neil Cerutti]

On 2011-04-12, Neil Cerutti ne...@norwich.edu wrote:
 On 2011-04-12, Ian Kelly ian.g.ke...@gmail.com wrote:
 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?

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

-- 
Neil Cerutti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Rebert]

On Tue, Apr 12, 2011 at 11:00 AM, Teemu Likonen tliko...@iki.fi wrote:
 * 2011-04-12T10:27:55+10:00 * James Mills wrote:
 On Tue, Apr 12, 2011 at 9:17 AM, zildjohn01 zildjoh...@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.

 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.

I think Ben Yahtzee Croshaw's comments on open-world sandbox video
games (of all things) have a lot of applicability to why allowing
full-on macros can be a bad idea.

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.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

On Wed, Apr 13, 2011 at 6:26 AM, Chris Rebert c...@rebertia.com wrote:
 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

-- 
-- James Mills
--
-- Problems are solved by method
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Westley Martínez]

On Tue, 2011-04-12 at 07:58 -0700, scattered wrote:
 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 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?- 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?

Not OP's idea, Angelico's.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Angelico]

On Wed, Apr 13, 2011 at 8:45 AM, Westley Martínez aniko...@gmail.com wrote:
 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.

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Ethan Furman]

James Mills wrote:

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~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

On Wed, Apr 13, 2011 at 9:06 AM, Ethan Furman et...@stoneleaf.us wrote:
 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

-- 
-- James Mills
--
-- Problems are solved by method
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Westley Martínez]

On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:
 James Mills wrote:
  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~

The question mark makes the programmer look like he wasn't sure of what
he was doing at the time.  Hmm, should I return this object or not?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Ethan Furman]

Westley Martínez wrote:

On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:

-- def func():
-- var1 = something()
-- var2 = something_else('this')
-- return? var1.hobgle(var2)
-- var3 = last_resort(var1)
-- return var3.wiglat(var2)


The question mark makes the programmer look like he wasn't sure of what
he was doing at the time.  Hmm, should I return this object or not?



Yeah, I'm definitely -1 on the ?, as well as -1 on the idea.  All other 
major flow control uses indentation, and this does not.


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Steven D'Aprano]

On Tue, 12 Apr 2011 16:48:31 -0700, Ethan Furman wrote:

 Westley Martínez wrote:
 On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:
 -- def func():
 -- var1 = something()
 -- var2 = something_else('this') -- return?
 var1.hobgle(var2)
 -- var3 = last_resort(var1)
 -- return var3.wiglat(var2)
 
 The question mark makes the programmer look like he wasn't sure of what
 he was doing at the time.  Hmm, should I return this object or not?
 
 
 Yeah, I'm definitely -1 on the ?, as well as -1 on the idea.  All other
 major flow control uses indentation, and this does not.

Neither return nor raise use indentation, and you don't get much more 
major than those. Nor do list comps or generator expressions.

Indentation is not appropriate here because it doesn't involve a block of 
code. The whole point is that it just involves a single expression.

But in any case, I'm -1 on any syntax involving ? in Python, and +0 on 
the concept on a conditional return. I suspect it's too specialised to be 
worth special syntax or a keyword, but I can definitely see some uses for 
it.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Ethan Furman]

Steven D'Aprano wrote:

On Tue, 12 Apr 2011 16:48:31 -0700, Ethan Furman wrote:


Westley Martínez wrote:

On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:

-- def func():
-- var1 = something()
-- var2 = something_else('this') -- return?
var1.hobgle(var2)
-- var3 = last_resort(var1)
-- return var3.wiglat(var2)

The question mark makes the programmer look like he wasn't sure of what
he was doing at the time.  Hmm, should I return this object or not?



Yeah, I'm definitely -1 on the ?, as well as -1 on the idea.  All other
major flow control uses indentation, and this does not.


Neither return nor raise use indentation, and you don't get much more 
major than those. Nor do list comps or generator expressions.


The indentation for return and raise is the next coded line.  List comps 
and gen exps are basically uber-functions, and regardless of how you 
categorize them when they finish it is easy to see where control goes to 
next because of indentation.  With this idea flow can leave the function 
with no indentation clue, making it easy to miss (assuming, of course, 
it's not some bright syntax highlighted color).


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Angelico]

On Wed, Apr 13, 2011 at 12:42 PM, Ethan Furman et...@stoneleaf.us wrote:
 The indentation for return and raise is the next coded line.  List comps and
 gen exps are basically uber-functions, and regardless of how you categorize
 them when they finish it is easy to see where control goes to next because
 of indentation.  With this idea flow can leave the function with no
 indentation clue, making it easy to miss (assuming, of course, it's not some
 bright syntax highlighted color).

So if I have a function that can early-abort, I should indent after that?

def foo(param):
resource=malloc(5) # Shtarker, zis is Python! We don't malloc here!
if not resource: return 0
resource[param]=5
del resource
return 1

Now, this pattern of attempt to acquire resource, return if unable
to is probably better recoded as acquire resource and have it throw
an error if it can't; but if you're eyeballing for control-flow
changes, a called function throwing an error is even less obvious than
an if: return.

Where should the indentation go?

As I understand it, Python uses indents the way C uses braces - to
delimit blocks of code. The only reason to indent in foo() above would
be if the if has an else:

if not resource: return 0
else:
resource[param]=5
del resource
return 1

or, flipping that the other way around:

if resource:
resource[param]=5
del resource
return 1
return 0

but both of these are grossly inferior to:

def foo(param):
resource=generate_resource()
resource.dosomething(param,5)
return 1

However, what's to tell you that generate_resource() will throw a
KaosError if Siegfried is around?

(Oh, and apologies to all for picking a different comedy source for my
references. Sometimes even a python has to get smart...)

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

On Wed, Apr 13, 2011 at 1:00 PM, Chris Angelico ros...@gmail.com wrote:
 def foo(param):
    resource=malloc(5) # Shtarker, zis is Python! We don't malloc here!
    if not resource: return 0
    resource[param]=5
    del resource
    return 1

In Python this can probably be done and perhaps is slightly more
readble with the with statement and a context manager:

def foo(param):
   try:
  with ResourceAllocator(5) as resource:
 resource[param] = 5
 return 1
   except:
  return 0

Now I know I'm only adding to the discussion (argument) but
hey it's all in good fun until someone looses an eyeball!

cheers
James

-- 
-- James Mills
--
-- Problems are solved by method
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[alex23]

zildjohn01 zildjoh...@gmail.com wrote:
 Regardless of James Mills's coding prowess[...]

James is the sole dev of a very handy  elegant event framework:
https://bitbucket.org/prologic/circuits/ Can you point out any
equivalent achievements so we can compare?

And make sure to carry that attitude of smug superiority over to
python-ideas, they love it there.

-- 
http://mail.python.org/mailman/listinfo/python-list

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?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

On Tue, Apr 12, 2011 at 9:17 AM, zildjohn01 zildjoh...@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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Angelico]

On Tue, Apr 12, 2011 at 10:27 AM, James Mills
prolo...@shortcircuit.net.au wrote:
 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Angelico]

On Tue, Apr 12, 2011 at 10:46 AM, Chris Angelico ros...@gmail.com wrote:
 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Grant Edwards]

On 2011-04-12, James Mills prolo...@shortcircuit.net.au wrote:
 On Tue, Apr 12, 2011 at 9:17 AM, zildjohn01 zildjoh...@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


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Jason Swails]

On Mon, Apr 11, 2011 at 7:12 PM, James Mills
prolo...@shortcircuit.net.auwrote:


  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


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

 def foo(n):
... x = n  5
... if x: return x
...
 def foo1(n):
... return n  5
...
 foo(4)
True
 foo1(4)
True
 foo(6)
 foo1(6)
False


--Jason
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Grant Edwards]

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


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

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 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Zero Piraeus]

:

 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Angelico]

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 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[Chris Angelico]

On Tue, Apr 12, 2011 at 12:43 PM, Zero Piraeus sche...@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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

On Tue, Apr 12, 2011 at 12:43 PM, Zero Piraeus sche...@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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Feature suggestion -- return if true

[James Mills]

On Tue, Apr 12, 2011 at 12:44 PM, Chris Angelico ros...@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
-- 
http://mail.python.org/mailman/listinfo/python-list