Re: Feature suggestion: "Using declarations" i.e. context managers ("with" blocks) tied to scope/lifetime of the variable rather than to nesting

On 21/02/2019 19:35, mnl.p...@gmail.com wrote: > (I sent this a few days ago but got bounced without a reason—don’t see it > posted, so I’m trying one more time.) No, it got through. And it's in the archive: https://mail.python.org/pipermail/python-list/2019-February/739548.html -- https://mail

Re: Feature suggestion: "Using declarations" i.e. context managers ("with" blocks) tied to scope/lifetime of the variable rather than to nesting

On 21/02/2019 18:35, mnl.p...@gmail.com wrote: (I sent this a few days ago but got bounced without a reason—don’t see it posted, so I’m trying one more time.) It was posted, and commented on. You can see the thread in the mailing list archives, if you don't believe me: https://mail.python.or

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

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, an

Re: Feature suggestion -- return if true

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 conditio

Re: Feature suggestion -- return if true

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)

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

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 functi

Re: Feature suggestion -- return if true

In article , D'Arcy J.M. Cain wrote: >On Sun, 17 Apr 2011 16:21:53 +1200 >Gregory Ewing 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 >

Re: Feature suggestion -- return if true

On Mon, Apr 18, 2011 at 12:04 PM, Dave Angel wrote: > On 01/-10/-28163 02:59 PM, Chris Angelico wrote: >> >>   >> >> 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 intege

Re: Feature suggestion -- return if true

On 01/-10/-28163 02:59 PM, Chris Angelico wrote: 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

Re: Feature suggestion -- return if true

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 d

Re: Feature suggestion -- return if true

On Sun, Apr 17, 2011 at 8:03 PM, Martin v. Loewis 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 yo

Re: Feature suggestion -- return if true

D'Arcy J.M. Cain wrote: On Sun, 17 Apr 2011 16:21:53 +1200 Gregory Ewing 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 needless

Re: Feature suggestion -- return if true

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:

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

On Sun, 17 Apr 2011 16:21:53 +1200 Gregory Ewing 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 needl

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

On Sun, Apr 17, 2011 at 6:45 PM, Steven D'Aprano 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

Re: Feature suggestion -- return if true

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; retu

Re: Feature suggestion -- return if true

On Sun, Apr 17, 2011 at 2:21 PM, Gregory Ewing 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

Re: Feature suggestion -- return if true

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_cach

Re: Feature suggestion -- return if true

* 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 > ha

Re: Feature suggestion -- return if true

zildjohn01 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

Re: Feature suggestion -- return if true

On Wed, Apr 13, 2011 at 1:00 PM, Chris Angelico 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 m

Re: Feature suggestion -- return if true

On Wed, Apr 13, 2011 at 12:42 PM, Ethan Furman 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 inden

Re: Feature suggestion -- return if true

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_

Re: Feature suggestion -- return if true

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_res

Re: Feature suggestion -- return if true

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 progra

Re: Feature suggestion -- return if true

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 cle

Re: Feature suggestion -- return if true

On Wed, Apr 13, 2011 at 9:06 AM, Ethan Furman 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

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

On Wed, Apr 13, 2011 at 8:45 AM, Westley Martínez 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 a

Re: Feature suggestion -- return if true

On Tue, 2011-04-12 at 07:58 -0700, scattered wrote: > On Apr 12, 10:05 am, Westley Martínez wrote: > > 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:

Re: Feature suggestion -- return if true

On Wed, Apr 13, 2011 at 6:26 AM, Chris Rebert 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 creat

Re: Feature suggestion -- return if true

On Tue, Apr 12, 2011 at 11:00 AM, Teemu Likonen wrote: > * 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

Re: Feature suggestion -- return if true

On 2011-04-12, Neil Cerutti wrote: > On 2011-04-12, Ian Kelly 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 crea

Re: Feature suggestion -- return if true

On 2011-04-12, Ian Kelly 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 cr

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

Teemu Likonen 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. -- htt

Re: Feature suggestion -- return if true

On Tue, Apr 12, 2011 at 12:25 PM, Ian Kelly wrote: > 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 ti

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

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 dis

Re: Feature suggestion -- return if true

* 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

Re: Feature suggestion -- return if true

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 tim

Re: Feature suggestion -- return if true

On Apr 12, 10:05 am, Westley Martínez wrote: > 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

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

On 2011-04-12, James Mills wrote: > On Tue, Apr 12, 2011 at 12:18 PM, Grant Edwards > wrote: >> You stated that >> >> ??return? >> >> was equivalent to >> >> ??return or None > > This is _not_ what I said. > > Quoting from my earlier post: > > """ >>return? expr > > This syntax does not fi

Re: Feature suggestion -- return if true

On Apr 12, 12:58 am, 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 b

Re: Feature suggestion -- return if true

On Apr 12, 2:21 am, 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 cann

Re: Feature suggestion -- return if true

On Tue, 12 Apr 2011 16:21:43 +1000, James Mills wrote: > On Tue, Apr 12, 2011 at 4:08 PM, Nobody wrote: >> It should be abundantly clear that this only returns if the expression >> is considered true, otherwise it continues on to the following >> statements. > > Uggh come on guys. We've been ove

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

On Tue, Apr 12, 2011 at 4:08 PM, Nobody wrote: > It should be abundantly clear that this only returns if the expression is > considered true, otherwise it continues on to the following statements. Uggh come on guys. We've been over this. You cannot make that assumption. cheers James -- -- Jam

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

On Tue, Apr 12, 2011 at 12:43 PM, Zero Piraeus wrote: > I think the point is that OP doesn't want to return *at all* if expr > is False - presumably because there are further statements after the > proposed 'conditional' return. If that's the case then we're all making assumptions about what the

Re: Feature suggestion -- return if true

On Tue, Apr 12, 2011 at 12:43 PM, Zero Piraeus wrote: >  return? expr > > isn't very pythonic - so how about one of these? > >  return expr if True >  return expr else continue > > I kid, I kid ... Or: if expr: return it Actually, I'm not sure how stupid an idea that is. Inside an if, 'it' is

Re: Feature suggestion -- return if true

On Tue, Apr 12, 2011 at 12:18 PM, Grant Edwards wrote: > You stated that > >  return? > > was equivalent to > >  return 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

Re: Feature suggestion -- return if true

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 dea

Re: Feature suggestion -- return if true

: >> 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 beca

Re: Feature suggestion -- return if true

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! cheers James -- -- James Mills -- -- "Problems are solved by

Re: Feature suggestion -- return if true

On 2011-04-12, James Mills wrote: > On Tue, Apr 12, 2011 at 11:44 AM, Grant Edwards > wrote: >> How is that the same? >> >> ??return? something() ?? ?? ?? ?? ?? ?? ?? ?? ??return something() or None >> ??return? somethingelse() ?? ?? ?? ?? ?? ?? ??return somethingelse() or None >> ??log("didn't

Re: Feature suggestion -- return if true

On Mon, Apr 11, 2011 at 7:12 PM, James Mills wrote: > > > 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 ret

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

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

Re: Feature suggestion -- return if true

On Tue, Apr 12, 2011 at 10:46 AM, Chris Angelico 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

Re: Feature suggestion -- return if true

On Tue, Apr 12, 2011 at 10:27 AM, James Mills 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 solutio

Re: Feature suggestion -- return if true

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

Re: Feature suggestion: math.zod for painlessly avoiding ZeroDivisionError

On 4/11/2011 10:10 AM, Natan Yellin wrote: Hey everyone, This is my first posting to python-list, so be gentle. I propose the following function for the math module (which can, of course, be rewritten in C): zod = lambda a, b: b and a / b This is way too trivial to add. zod, the zero

Re: Feature suggestion: math.zod for painlessly avoiding ZeroDivisionError

On Mon, Apr 11, 2011 at 5:20 PM, Chris Angelico wrote: > On Tue, Apr 12, 2011 at 12:10 AM, Natan Yellin wrote: > > Hey everyone, > > This is my first posting to python-list, so be gentle. > > I propose the following function for the math module (which can, of > course, > > be rewritten in C): >

Re: Feature suggestion: sum() ought to use a compensated summationalgorithm

"Terry Reedy" <[EMAIL PROTECTED]> wrote: > > "Szabolcs Horvát" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >| Gabriel Genellina wrote: >| > >| > Python doesn't require __add__ to be associative, so this should >| > not be > used as a general sum replacement. >| >| It does not

Re: Feature suggestion: sum() ought to use a compensated summationalgorithm

On May 8, 3:09 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "Szabolcs Horvát" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED]| Gabriel Genellina wrote: > > | > > | > Python doesn't require __add__ to be associative, so this should not be > used as a general sum replacement. > | >

Re: Feature suggestion: sum() ought to use a compensated summationalgorithm

"Szabolcs Horvát" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Gabriel Genellina wrote: | > | > Python doesn't require __add__ to be associative, so this should not be used as a general sum replacement. | | It does not _require_ this, but using an __add__ that is not commutative

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

En Mon, 05 May 2008 05:08:15 -0300, Raymond Hettinger <[EMAIL PROTECTED]> escribió: On May 3, 9:50 am, Szabolcs Horvát <[EMAIL PROTECTED]> wrote: I did the following calculation:  Generated a list of a million random numbers between 0 and 1, constructed a new list by subtracting the mean valu

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

En Mon, 05 May 2008 11:08:02 -0300, Szabolcs <[EMAIL PROTECTED]> escribió: On May 5, 12:24 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: Szabolcs <[EMAIL PROTECTED]> wrote: > On May 5, 9:37 am, Szabolcs Horvát <[EMAIL PROTECTED]> wrote: >> Gabriel Genellina wrote: >> > Python doesn't require __a

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

Gabriel Genellina wrote: Python doesn't require __add__ to be associative, so this should not be used as a general sum replacement. But if you know that you're adding floating point numbers you can use whatever algorithm best fits you. Or use numpy arrays; I think they implement Kahan summatio

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On May 3, 4:31 pm, Thomas Dybdahl Ahle <[EMAIL PROTECTED]> wrote: > On Sat, 2008-05-03 at 21:37 +, Ivan Illarionov wrote: > > On Sat, 03 May 2008 20:44:19 +0200, Szabolcs Horvát wrote: > > > > Arnaud Delobelle wrote: > > > >> sum() works for any sequence of objects with an __add__ method, not >

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On May 5, 12:24 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > Szabolcs <[EMAIL PROTECTED]> wrote: > > On May 5, 9:37 am, Szabolcs Horvát <[EMAIL PROTECTED]> wrote: > >> Gabriel Genellina wrote: > > >> > Python doesn't require __add__ to be associative, so this should > >> > not be > > used as a gen

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

Szabolcs <[EMAIL PROTECTED]> wrote: > On May 5, 9:37 am, Szabolcs Horvát <[EMAIL PROTECTED]> wrote: >> Gabriel Genellina wrote: >> >> > Python doesn't require __add__ to be associative, so this should >> > not be > used as a general sum replacement. >> >> It does not _require_ this, but using an

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

"Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > En Sun, 04 May 2008 12:58:25 -0300, Duncan Booth > <[EMAIL PROTECTED]> escribió: > >> Szabolcs Horvát <[EMAIL PROTECTED]> wrote: >> >>> I thought that it would be very nice if the built-in sum() function >>> used this algorithm by default. Has th

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On May 5, 9:37 am, Szabolcs Horvát <[EMAIL PROTECTED]> wrote: > Gabriel Genellina wrote: > > > Python doesn't require __add__ to be associative, so this should not be > > used as a general sum replacement. > > It does not _require_ this, but using an __add__ that is not commutative > and associati

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

> > > However I find the seccond argument hack ugly. Does the sum way have any > > > performance advantages over the reduce way? > > > Yes, sum() is faster: ... > Not really; you measure the import and the attribute access time in > the second case. sum() is 2x faster for adding numbers only: Try

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On May 3, 9:50 am, Szabolcs Horvát <[EMAIL PROTECTED]> wrote: > I did the following calculation:  Generated a list of a million random > numbers between 0 and 1, constructed a new list by subtracting the mean > value from each number, and then calculated the mean again. > > The result should be 0,

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

Gabriel Genellina wrote: Python doesn't require __add__ to be associative, so this should not be used as a general sum replacement. It does not _require_ this, but using an __add__ that is not commutative and associative, or has side effects, would qualify as a serious misuse, anyway. So I

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

Duncan Booth wrote: Szabolcs Horvát <[EMAIL PROTECTED]> wrote: I thought that it would be very nice if the built-in sum() function used this algorithm by default. Has this been brought up before? Would this have any disadvantages (apart from a slight performance impact, but Python is a high

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

En Sun, 04 May 2008 12:58:25 -0300, Duncan Booth <[EMAIL PROTECTED]> escribió: > Szabolcs Horvát <[EMAIL PROTECTED]> wrote: > >> I thought that it would be very nice if the built-in sum() function used >> this algorithm by default. Has this been brought up before? Would this >> have any disadvan

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

Szabolcs Horvát <[EMAIL PROTECTED]> wrote: > I thought that it would be very nice if the built-in sum() function used > this algorithm by default. Has this been brought up before? Would this > have any disadvantages (apart from a slight performance impact, but > Python is a high-level languag

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On May 3, 7:05 pm, sturlamolden <[EMAIL PROTECTED]> wrote: > On May 3, 10:13 pm, hdante <[EMAIL PROTECTED]> wrote: > > >  I believe that moving this to third party could be better. What about > > numpy ? Doesn't it already have something similar ? > > Yes, Kahan summation makes sence for numpy arra

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On Sat, 03 May 2008 17:43:57 -0700, George Sakkis wrote: > On May 3, 7:12 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote: >> On Sun, 04 May 2008 00:31:01 +0200, Thomas Dybdahl Ahle wrote: >> > On Sat, 2008-05-03 at 21:37 +, Ivan Illarionov wrote: >> >> On Sat, 03 May 2008 20:44:19 +0200, Szabol

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On Sun, 04 May 2008 00:31:01 +0200, Thomas Dybdahl Ahle wrote: > On Sat, 2008-05-03 at 21:37 +, Ivan Illarionov wrote: >> On Sat, 03 May 2008 20:44:19 +0200, Szabolcs Horvát wrote: >> >> > Arnaud Delobelle wrote: >> >> >> >> sum() works for any sequence of objects with an __add__ method, not

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On May 3, 7:12 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote: > On Sun, 04 May 2008 00:31:01 +0200, Thomas Dybdahl Ahle wrote: > > On Sat, 2008-05-03 at 21:37 +, Ivan Illarionov wrote: > >> On Sat, 03 May 2008 20:44:19 +0200, Szabolcs Horvát wrote: > > >> > Arnaud Delobelle wrote: > > >> >> sum

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On Sat, 2008-05-03 at 21:37 +, Ivan Illarionov wrote: > On Sat, 03 May 2008 20:44:19 +0200, Szabolcs Horvát wrote: > > > Arnaud Delobelle wrote: > >> > >> sum() works for any sequence of objects with an __add__ method, not > >> just floats! Your algorithm is specific to floats. > > > > Thi

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On May 3, 10:13 pm, hdante <[EMAIL PROTECTED]> wrote: > I believe that moving this to third party could be better. What about > numpy ? Doesn't it already have something similar ? Yes, Kahan summation makes sence for numpy arrays. But the problem with this algorithm is optimizing compilers. The

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On Sat, 03 May 2008 20:44:19 +0200, Szabolcs Horvát wrote: > Arnaud Delobelle wrote: >> >> sum() works for any sequence of objects with an __add__ method, not >> just floats! Your algorithm is specific to floats. > > This occurred to me also, but then I tried > > sum(['abc', 'efg'], '') Inter

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

Torsten Bronger wrote: No, the above expression should yield ''+'abc'+'efg', look for the signature of sum in the docs. You're absolutely right, I misread it. Sorry about that. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && A

Re: Feature suggestion: sum() ought to use a compensated summation algorithm

Hallöchen! Erik Max Francis writes: > Szabolcs Horvát wrote: > >> Arnaud Delobelle wrote: >>> >>> sum() works for any sequence of objects with an __add__ method, not >>> just floats! Your algorithm is specific to floats. >> >> This occurred to me also, but then I tried >> >> sum(['abc', 'efg'],

  1   2   >