Re: [Python-3000] Python 3000 Status Update (Long!)

On 21 Jun 2007, at 21:21, Bill Janssen wrote: >>> It should amount to "map(+, operands)". >> >> Or, to be pedantic, this: >> >> reduce(lambda x, y: x.__add__(y), operands) > > Don't you mean: > >reduce(lambda x, y: x.__add__(y), operands[1:], operands[0]) In the absence of a "start" val

Re: [Python-3000] Python 3000 Status Update (Long!)

On 22-Jun-07, at 2:44 PM, Jean-Paul Calderone wrote: > On Fri, 22 Jun 2007 14:28:12 -0700, Alex Martelli > <[EMAIL PROTECTED]> wrote: > > Could be. I don't find many of my programs to be bottlenecked on > compilation time or import time, so these optimizations look like > pure lose to me. Nor

Re: [Python-3000] Python 3000 Status Update (Long!)

On Fri, 22 Jun 2007 14:28:12 -0700, Alex Martelli <[EMAIL PROTECTED]> wrote: >On 6/22/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > ... >>This is more reasonable, but it's still a new rule (and I personally >>find rules which include undefined behavior to be distasteful -- but >>your sugge

Re: [Python-3000] Python 3000 Status Update (Long!)

On 6/22/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: ... > This is more reasonable, but it's still a new rule (and I personally > find rules which include undefined behavior to be distasteful -- but > your suggestion could be modified so that the name change is never > respected to achieve

Re: [Python-3000] Python 3000 Status Update (Long!)

On Fri, 22 Jun 2007 14:06:07 -0700, Alex Martelli <[EMAIL PROTECTED]> wrote: >On 6/22/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > ... >> >> Calling abs() could change locals()['abs'], in which case a different >> >> function would be called the next time through. You lookup 'abs' each >

Re: [Python-3000] Python 3000 Status Update (Long!)

On 6/22/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: ... > >> Calling abs() could change locals()['abs'], in which case a different > >> function would be called the next time through. You lookup 'abs' each > >> time just in case it's changed. > >> > > > >I can't think of a reason to allo

Re: [Python-3000] Python 3000 Status Update (Long!)

On Fri, 22 Jun 2007 14:13:39 -0600, Neil Toronto <[EMAIL PROTECTED]> wrote: >Andrew McNabb wrote: >> On Fri, Jun 22, 2007 at 01:32:42PM -0600, Neil Toronto wrote: >> (imap is faster in this case because the built-in name 'abs' is looked up only once -- in the genexp, it's looked up each t

Re: [Python-3000] Python 3000 Status Update (Long!)

Andrew McNabb wrote: > On Fri, Jun 22, 2007 at 01:32:42PM -0600, Neil Toronto wrote: > >>> (imap is faster in this case because the built-in name 'abs' is looked >>> up only once -- in the genexp, it's looked up each time, sigh -- >>> possibly the biggest "we should REALLY tweak the language to

Re: [Python-3000] Python 3000 Status Update (Long!)

On Fri, Jun 22, 2007 at 01:32:42PM -0600, Neil Toronto wrote: > > (imap is faster in this case because the built-in name 'abs' is looked > > up only once -- in the genexp, it's looked up each time, sigh -- > > possibly the biggest "we should REALLY tweak the language to let this > > be optimized se

Re: [Python-3000] Python 3000 Status Update (Long!)

Alex Martelli wrote: > $ python -mtimeit -s'import itertools as it' -s'L=range(-7,17)' 'for x > in it.imap(abs,L): pass' > 10 loops, best of 3: 3 usec per loop > $ python -mtimeit -s'import itertools as it' -s'L=range(-7,17)' 'for x > in (abs(y) for y in L): pass' > 10 loops, best of 3: 4.4

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Greg Ewing <[EMAIL PROTECTED]> wrote: > The word "add" has a wider connotation in English > than > "sum". [...] Just to elaborate on the point... And, likewise, symbolic operators have a wider connotation in programming languages than do keywords. Keywords can, and should, be more specifica

Re: [Python-3000] Python 3000 Status Update (Long!)

On Fri, Jun 22, 2007 at 07:11:14PM +1000, Nick Coghlan wrote: > Bill Janssen wrote: > >>> It should amount to "map(+, operands)". > >> Or, to be pedantic, this: > >> > >> reduce(lambda x, y: x.__add__(y), operands) > > > > Don't you mean: > > > >reduce(lambda x, y: x.__add__(y), operand

Re: [Python-3000] Python 3000 Status Update (Long!)

Bill Janssen wrote: >>> It should amount to "map(+, operands)". >> Or, to be pedantic, this: >> >> reduce(lambda x, y: x.__add__(y), operands) > > Don't you mean: > >reduce(lambda x, y: x.__add__(y), operands[1:], operands[0]) This is a nice illustration of a fairly significant issue w

Re: [Python-3000] Python 3000 Status Update (Long!)

Bill Janssen wrote: > It should be > > sum(*operands) That would incur copying of the sequence. It would be justifiable only if the vast majority of use cases involved passing the operands as separate arguments, which I don't think is true. -- Greg _

Re: [Python-3000] Python 3000 Status Update (Long!)

Andrew McNabb wrote: > I think you're technically right, but I frequently find myself using the > phrase "add together a list of strings" when it would be more accurate > to say "concatenate a list of strings." The word "add" has a wider connotation in English than "sum". Consider the following tw

Re: [Python-3000] Python 3000 Status Update (Long!)

Steve Howell wrote: > --- Ron Adam <[EMAIL PROTECTED]> wrote: > >> >> Bill Janssen wrote: I think you were missing my point, which is that >> sum doesn't and shouldn't necessarily have the same semantics as map(+). >>> It's not that I don't understand your argument, >> Steve. >>>

Re: [Python-3000] Python 3000 Status Update (Long!)

> > It should amount to "map(+, operands)". > > Or, to be pedantic, this: > > reduce(lambda x, y: x.__add__(y), operands) Don't you mean: reduce(lambda x, y: x.__add__(y), operands[1:], operands[0]) Bill ___ Python-3000 mailing list Python-3

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Ron Adam <[EMAIL PROTECTED]> wrote: > > > Bill Janssen wrote: > >> I think you were missing my point, which is that > sum > >> doesn't and shouldn't necessarily have the same > >> semantics as map(+). > > > > It's not that I don't understand your argument, > Steve. > > > > I just don't fi

Re: [Python-3000] Python 3000 Status Update (Long!)

Bill Janssen wrote: >> I think you were missing my point, which is that sum >> doesn't and shouldn't necessarily have the same >> semantics as map(+). > > It's not that I don't understand your argument, Steve. > > I just don't find it effective. If we are going to distinguish > between "arithm

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Andrew McNabb <[EMAIL PROTECTED]> wrote: > > I agree that on its own, it's not the most natural > method. However, > once you've already used the + operator to join two > strings, you are > much more likely to consider sum() for concatenating > a list of strings. > I remember being confused

Re: [Python-3000] Python 3000 Status Update (Long!)

On Thu, Jun 21, 2007 at 10:33:41AM -0700, Steve Howell wrote: > > Nope, and I wouldn't throw the grammar book at you if you did. But if > you said a compound word is a "sum" of smaller words, I might look at > you a little funny. :) It wouldn't be the first time someone looked at me a little fu

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Bill Janssen <[EMAIL PROTECTED]> wrote: > > My other concern with sum() is just the common > pitfall > > that you do sum(line_of_numbers.split(',')) and > get > > '35' when you intended to write code to get 8. > I'd > > rather have that fail obviously than subtlely. > > Common pitfall? I

Re: [Python-3000] Python 3000 Status Update (Long!)

> I think you were missing my point, which is that sum > doesn't and shouldn't necessarily have the same > semantics as map(+). It's not that I don't understand your argument, Steve. I just don't find it effective. If we are going to distinguish between "arithmetic addition" and "concatenation",

Re: [Python-3000] Python 3000 Status Update (Long!)

> It should be > > sum(*operands) > > not > > sum(operands, initialvalue=?) > > It should amount to "map(+, operands)". Or, to be pedantic, this: reduce(lambda x, y: x.__add__(y), operands) Joel ___ Python-3000 mailing list Python-3000@p

Re: [Python-3000] Python 3000 Status Update (Long!)

> My other concern with sum() is just the common pitfall > that you do sum(line_of_numbers.split(',')) and get > '35' when you intended to write code to get 8. I'd > rather have that fail obviously than subtlely. Common pitfall? I doubt it. Possible pitfall? Sure. Bill __

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Andrew McNabb <[EMAIL PROTECTED]> wrote: > > I think you're technically right, but I frequently > find myself using the > phrase "add together a list of strings" when it > would be more accurate > to say "concatenate a list of strings." I can't say > I feel bad when I > use this terminology

Re: [Python-3000] Python 3000 Status Update (Long!)

On 6/21/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > The real problem with "sum", I think, is that the parameter list is > ill-conceived (perhaps because it was added before variable length > parameter lists were?). It should be > sum(*operands) > not > sum(operands, initialvalue=?) Is th

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Bill Janssen <[EMAIL PROTECTED]> wrote: > > Multiple additions (with "+") mean "sum" in > > arithmetic, but you can't generalize that to > strings > > and text processing. The "+" operator for any two > > strings is not about adding--it's about > > joining/concatenating. So multiple applica

Re: [Python-3000] Python 3000 Status Update (Long!)

> Multiple additions (with "+") mean "sum" in > arithmetic, but you can't generalize that to strings > and text processing. The "+" operator for any two > strings is not about adding--it's about > joining/concatenating. So multiple applications of > "+" on strings aren't a sum. They're just a lo

Re: [Python-3000] Python 3000 Status Update (Long!)

On Thu, Jun 21, 2007 at 02:49:46AM -0700, Steve Howell wrote: > > "Sum" should sum stuff. You can't sum strings. It makes no sense in > English. I think you're technically right, but I frequently find myself using the phrase "add together a list of strings" when it would be more accurate to say

Re: [Python-3000] Python 3000 Status Update (Long!)

Gareth McCaughan wrote: > That is: if you're writing code that expects sum() to do something > sensible with lists of strings, you'll usually need it to do something > sensible with *empty* lists of strings -- but that isn't possible, > because there's only one empty list and it has to serve as the

Re: [Python-3000] Python 3000 Status Update (Long!)

Thomas Wouters wrote: > > > On 6/20/07, *Nick Coghlan* <[EMAIL PROTECTED] > > wrote: > > Strings are explicitly disallowed (because Guido doesn't want a second > way to spell ''.join(seq), as far as I know): > > > More importantly, because it has positively a

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Bill Janssen <[EMAIL PROTECTED]> wrote: > [...] It's more important to make things work > consistently than to only > have "one way". "sum" should concatenate strings. > "Sum" should sum stuff. You can't sum strings. It makes no sense in English. You can concatenate strings, or you can

Re: [Python-3000] Python 3000 Status Update (Long!)

Christian Heimes wrote: > IIRC map and filter are a bit slower than list comprehensive But isn't that true only when the function passed is a Python function? Or are LCs faster now even for C functions? -- Greg Ewing, Computer Science Dept, +--+ University of

Re: [Python-3000] Python 3000 Status Update (Long!)

Nicko van Someren wrote: > perhaps the sum() function could be made properly polymorphic > so as to remove one more class of use cases for reduce(). That's unlikely to happen. As I remember things, sum() was deliberately restricted to numbers so as not to present an attractive nuisance as an ine

Re: [Python-3000] Python 3000 Status Update (Long!)

On Wednesday 20 June 2007 18:12, Nicko van Someren wrote (about summing strings, etc.):: > The need to have an explicit 'start' value just seems wrong. It's > horribly inconsistent. Things that can be added to integers work > without initialisers but things that can be added to each other (for >

Re: [Python-3000] Python 3000 Status Update (Long!)

Christian Heimes schrieb: > Alex Martelli wrote: >> No, in 3.0 they'll return iterables -- you really SHOULD read Guido's >> blog entry referred to at the top of this thread, >> , before >> discussing Python 3.0 issues. > > I read it. I als

Re: [Python-3000] Python 3000 Status Update (Long!)

> It looks like an ordinary list to me. There are many things to implement yet. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archi

Re: [Python-3000] Python 3000 Status Update (Long!)

Alex Martelli wrote: > No, in 3.0 they'll return iterables -- you really SHOULD read Guido's > blog entry referred to at the top of this thread, > , before > discussing Python 3.0 issues. I read it. I also wasn't sure if map returns a speci

Re: [Python-3000] Python 3000 Status Update (Long!)

On 6/20/07, Christian Heimes <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > > Because (str(x) for x in seq) is not an improvement over map(str, x) - > > applying a single existing function to a sequence is a very common > > operation. > > > > map() accepts any function (given an appropriate num

Re: [Python-3000] Python 3000 Status Update (Long!)

On 20 Jun 2007, at 15:44, Nick Coghlan wrote: > Nicko van Someren wrote: >> >>> sum(['a','b','c']) >> Traceback (most recent call last): >>File "", line 1, in >> TypeError: unsupported operand type(s) for +: 'int' and 'str' >> >>> sum([["a"],[u'b'],[3]]) >> Traceb

Re: [Python-3000] Python 3000 Status Update (Long!)

> Strings are explicitly disallowed (because Guido doesn't want a second > way to spell ''.join(seq), as far as I know): Isn't "map(str, x)" just a second way to write "[str(x) for x in y]"? This "second way" argument is another often-heard bogon. There are lots of second-way and third-way tech

Re: [Python-3000] Python 3000 Status Update (Long!)

Nick Coghlan wrote: > Because (str(x) for x in seq) is not an improvement over map(str, x) - > applying a single existing function to a sequence is a very common > operation. > > map() accepts any function (given an appropriate number of sequences), > and thus has wide applicability. > > filte

Re: [Python-3000] Python 3000 Status Update (Long!)

On 6/20/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: Strings are explicitly disallowed (because Guido doesn't want a second way to spell ''.join(seq), as far as I know): More importantly, because it has positively abysmal performance, just like the reduce() solution (and, in fact, many reduce

Re: [Python-3000] Python 3000 Status Update (Long!)

Nicko van Someren wrote: > >>> sum(['a','b','c']) > Traceback (most recent call last): > File "", line 1, in > TypeError: unsupported operand type(s) for +: 'int' and 'str' > >>> sum([["a"],[u'b'],[3]]) > Traceback (most recent call last): > File "", l

Re: [Python-3000] Python 3000 Status Update (Long!)

On 19 Jun 2007, at 21:53, Mike Klaas wrote: > ... > Stats from _any_ large python project is better than anecdotes. > Perhaps it would be better to turn to the stdlib (367289 lines)? ... >reduce(lambda a, b: (0, a[1] + b[1]), items)[1] > > (which could be written sum(x[1] for x in items) O

Re: [Python-3000] Python 3000 Status Update (Long!)

Christian Heimes wrote: > Bill Janssen wrote: >> Though, from the standpoint of pragmatism, removing "reduce" from the >> built-in space will break code (*my* code, among others), and leaving >> it in will not affect "purity", as both "map" and "reduce" are being >> left in. So leaving it alone se

Re: [Python-3000] Python 3000 Status Update (Long!)

+1 on deciding on keeping builtins built in based on populuarity within actual source code. Stats will never be perfect, and nobody can practically sample all Python code ever written, but anybody who measures a large codebase to argue for keeping a builtin built in gets a +1 from me. Regarding m

Re: [Python-3000] Python 3000 Status Update (Long!)

On 19-Jun-07, at 12:13 PM, Bill Janssen wrote: >> map (especially the new iterized version) is a frequently-used >> builtin, while reduce is a rarely-used builtin that requires some >> head-wrapping. It makes sense to me to move it out of builtins. > > I've never understood this kind of argument

Re: [Python-3000] Python 3000 Status Update (Long!)

Bill Janssen wrote: > Though, from the standpoint of pragmatism, removing "reduce" from the > built-in space will break code (*my* code, among others), and leaving > it in will not affect "purity", as both "map" and "reduce" are being > left in. So leaving it alone seems the more Pythonic response

Re: [Python-3000] Python 3000 Status Update (Long!)

> map (especially the new iterized version) is a frequently-used > builtin, while reduce is a rarely-used builtin that requires some > head-wrapping. It makes sense to me to move it out of builtins. I've never understood this kind of argument. Because most people don't program in Python, we

Re: [Python-3000] Python 3000 Status Update (Long!)

On 19-Jun-07, at 10:51 AM, Bill Janssen wrote: > > Though, from the standpoint of pragmatism, removing "reduce" from the > built-in space will break code (*my* code, among others), and leaving > it in will not affect "purity", as both "map" and "reduce" are being > left in. So leaving it alone se

Re: [Python-3000] Python 3000 Status Update (Long!)

And, while I'm at it, why isn't there a built-in function called "output()", which matches "input()", that is, it's equivalent to import sys sys.stdout.write(MESSAGE) It could be easily implemented in terms of the built-in function called "print". The fact that it's not there is going

Re: [Python-3000] Python 3000 Status Update (Long!)

> > Shouldn't "reduce" stay in the 'built-in' space, while the other two > > move to "functools"? Or move them all to "functools"? Bizarre > > recombination, IMO. > > Arguing from the standpoint of purity, that, "these functions are > builtins, why not this other one" isn't going to get you very

Re: [Python-3000] Python 3000 Status Update (Long!)

On 6/19/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > > > written using list-comprehensions.. so why _reduce_? > > > > Don't worry, it wasn't complete removed. Reduce was moved to functools > > Though, really, same question! There are functional equivalents (list > comprehensions) for "map" and "

Re: [Python-3000] Python 3000 Status Update (Long!)

> > written using list-comprehensions.. so why _reduce_? > > Don't worry, it wasn't complete removed. Reduce was moved to functools Though, really, same question! There are functional equivalents (list comprehensions) for "map" and "filter", but not for "reduce". Shouldn't "reduce" stay in the

Re: [Python-3000] Python 3000 Status Update (Long!)

On 6/19/07, Gábor Farkas <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I've written up a comprehensive status report on Python 3000. Please read: > > http://www.artima.com/weblogs/viewpost.jsp?thread=208549 > why does map and filter stay, but reduce leaves? > i understand that some pe

Re: [Python-3000] Python 3000 Status Update (Long!)

Gábor Farkas wrote: > why does map and filter stay, but reduce leaves? > > i understand that some people think that an explicit for-loop is more > understandable, but also many people claim that list-comprehensions are > more understandable than map/filter.., and map/filter can be trivially > w

Re: [Python-3000] Python 3000 Status Update (Long!)

Guido van Rossum wrote: > I've written up a comprehensive status report on Python 3000. Please read: > > http://www.artima.com/weblogs/viewpost.jsp?thread=208549 > why does map and filter stay, but reduce leaves? i understand that some people think that an explicit for-loop is more understanda

[Python-3000] Python 3000 Status Update (Long!)

I've written up a comprehensive status report on Python 3000. Please read: http://www.artima.com/weblogs/viewpost.jsp?thread=208549 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org htt