Nick Coghlan wrote:
A suggestion was made on c.l.p a while back to have a specific module
dedicated to reductive operations. That is, just as itertools is
oriented towards manipulating iterables and creating iterators, this
module would be oriented towards consuming iterators in a reductive
Not sure this is pertinent but anyway: any and all are often used
as variable names. all especially often and then almost always as a
list of something. It would not be good to add all to the list of
words to watch out for. Also, all is usually thought of as a list of
(all) things. In my mind it
On Fri, 11 Mar 2005 11:30:38 +0100, BJörn Lindqvist [EMAIL PROTECTED] wrote:
Not sure this is pertinent but anyway: any and all are often used
as variable names. all especially often and then almost always as a
list of something. It would not be good to add all to the list of
words to watch
On Fri, 11 Mar 2005, Paul Moore wrote:
Not sure this is pertinent but anyway: any and all are often used
as variable names. all especially often and then almost always as a
list of something. It would not be good to add all to the list of
words to watch out for. Also, all is usually
Peter Astrand wrote:
On Fri, 11 Mar 2005, Paul Moore wrote:
Not sure this is pertinent but anyway: any and all are often used
as variable names. all especially often and then almost always as a
list of something. It would not be good to add all to the list of
words to watch out for. Also, all
And why not use the names already in use in numarray/Numeric ?
They are called sometrue and alltrue ... IMHO, it explicits more
what it means :
alltrue(i5 for i in l)
sometrue(i5 for i in l)
Another point is: as I agree there is already a huge lot of builtins,
shouldn't it be in some module
Peter Astrand wrote:
Personally, I think Python has too many builtins already.
A suggestion was made on c.l.p a while back to have a specific module dedicated
to reductive operations. That is, just as itertools is oriented towards
manipulating iterables and creating iterators, this module would
[ Pierre Barbier de Reuille ]:
They are called sometrue and alltrue ... IMHO, it explicits more
what it means :
alltrue(i5 for i in l)
sometrue(i5 for i in l)
+1
[ from a comment in GvR's blog ]
Why not,
if True in (x 42 for x in S):
instead of any and why not
if not False in (x 42
BTW I definitely expect having to defend removing
map/filter/reduce/lambda with a PEP; that's much more controversial
because it's *removing* something and hence by definition breaking
code.
I suspect that lambda will be the only bone of contention. The reduce()
function can be moved to the
Raymond Hettinger wrote:
BTW I definitely expect having to defend removing
map/filter/reduce/lambda with a PEP; that's much more controversial
because it's *removing* something and hence by definition breaking
code.
+1 on the PEP
-1 on removing those tools - breaks too much code.
I suspect that
On Mar 11, 2005, at 17:28, Guido van Rossum wrote:
PS in the blog responses, a problem with sum() was pointed out --
unless you use the second argument, it will only work for numbers. Now
Why is that a *problem*? It solves the end case (if the sequence is
empty which you mention for any() and
On Mar 11, 2005, at 18:18, Raymond Hettinger wrote:
str.join() is still the best practice for string concatenation.
...except you actually need unicode.join if the strings are of that
kind. Fortunately, ''.join intrinsically compensates:
x=[u'\u0fe0']*2
''.join(x)
u'\u0fe0\u0fe0'
*without*
On Fri, 2005-03-11 at 14:29, Jim Jewett wrote:
Is that so bad?
If you plan to use them often, then
from itertools import any, every
+1
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[Guido van Rossum]
But I realized (1) any() and all() read much better in their natural
context (an if statement), and there's no confusion there;
I do not think builtins should read good in some statement contexts and
bad in the others, or designed to be legible in only a few contexts.
This
Jim Jewett wrote:
Guido van Rossum:
[Why any() and all() shouldn't need to be imported.]
Is that so bad?
If you plan to use them often, then
from itertools import any, every
is reasonable. If you only use them once and weren't expecting it
(and want your imports at the top) ... well how awful
Guido van Rossum wrote:
Here's my take on the key issues brought up:
Alternative names anytrue(), alltrue(): before I posted to my blog I
played with these names (actually anyTrue(), allTrue(), anyFalse(),
allFalse()). But I realized (1) any() and all() read much better in
their natural context
Jim Jewett wrote:
Guido van Rossum:
Whether to segregate these into a separate module: they are really a
very small amount of syntactic sugat, and I expect that in most cases,
instead of importing that module (which totally makes me lose my
context while editing) I would probably just write the
See my blog: http://www.artima.com/forums/flat.jsp?forum=106thread=98196
Do we even need a PEP or is there a volunteer who'll add any() and all() for me?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
See my blog:
http://www.artima.com/forums/flat.jsp?forum=106thread=98196
Do we even need a PEP or is there a volunteer who'll add any() and
all()
for me?
I'll volunteer for this one.
Will leave it open for discussion for a bit so that folks can voice any
thoughts on the design.
Raymond
At 06:38 PM 3/10/05 -0800, Bill Janssen wrote:
Guido,
I think there should be a PEP. For instance, I think I'd want them to be:
def any(S):
for x in S:
if x:
return x
return S[-1]
def all(S):
for x in S:
if not x:
return x
return S[-1]
Or perhaps these should be called
[Bill Janssen]
I think I'd want them to be:
def any(S):
for x in S:
if x:
return x
return S[-1]
def all(S):
for x in S:
if not x:
return x
return S[-1]
Or perhaps these should be called first and last.
-1
Over time, I've gotten feedback about these
Over time, I've gotten feedback about these and other itertools recipes.
No one has objected to the True/False return values in those recipes or
in Guido's version.
Guido's version matches the normal expectation of any/all being a
predicate. Also, it avoids the kind of errors/confusion
On Thu, Mar 10, 2005 at 10:22:45PM -0500, Raymond Hettinger wrote:
[Bill Janssen]
I think I'd want them to be:
def any(S):
for x in S:
if x:
return x
return S[-1]
def all(S):
for x in S:
if not x:
return x
return S[-1]
Or perhaps these
On Thu, Mar 10, 2005, Bill Janssen wrote:
Raymond Hettinger:
Over time, I've gotten feedback about these and other itertools recipes.
No one has objected to the True/False return values in those recipes or
in Guido's version.
Guido's version matches the normal expectation of any/all being
24 matches
Mail list logo
