I think the discussion should separate numeric calculation and truth
value calculation.
Numeric calculation need to run through all elements, with the order
possibly important.
Truth value calculation (as per any() and all()) may terminate before
all elements have been seen.
Finally, any(), all(
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 fash
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 ex
Hello Folks,
I've been lurking here for several months. I've been using Python for
several years for prototyping fun. And I'm one of the architects of
its extensive use in research, engineering development, and testing on
a large, commercial speech-recognition system. I know a lot about
modelin
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 (an
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]
> 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
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 l
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'
*withou
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 a
On Fri, 2005-03-11 at 12:40, M.-A. Lemburg wrote:
> While I'm no fan of lambdas either, the removal would break too
> much code (e.g. I have 407 hits in the code base I use regularly
> alone).
We /are/ talking Python 3000 here, right? I'm expecting all manner of
code breakage in moving from Pyth
On Fri, 2005-03-11 at 12:18, Raymond Hettinger wrote:
> I suspect that lambda will be the only bone of contention. The reduce()
> function can be moved to the functional module. The map() and filter()
> functions are already covered by the itertools module.
I'm fine seeing reduce() eventually g
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 la
> 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
On Fri, 2005-03-11 at 06:43, Peter Astrand wrote:
> Even though you can use them as variables (and shadow the builtins), you
> will still get warnings from "pychecker". The code will also be harder to
> read: When you see "all" in the middle of some code, you don't know if
> it's referring to the
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 (an if statement), and the
On Fri, 11 Mar 2005 07:19:56 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> > Personally, I think Python has too many builtins already.
>
> It has fewer than most dynamic languages; and remember that I'm
> trading product(), any(), all() for reduce(), map() and filter().
> There are others s
> Even though you can use them as variables (and shadow the builtins), you
> will still get warnings from "pychecker".
So?
> The code will also be harder to
> read: When you see "all" in the middle of some code, you don't know if
> it's referring to the builtin or a variable.
Yes you do. Builtin
Rodrigo Dias Arruda Senra wrote:
OFF-TOPIC:
It is curious though that we choose to read an *implicit*
True in [all(), any()] instead of an implicit False.
Actually, I think it's predicate logic's fault:
if p(x) for any x then conclusion 1
if q(x) for all x then conclusion 2
Cheers,
Nick.
--
Nic
[ Pierre Barbier de Reuille ]:
They are called "sometrue" and "alltrue" ... IMHO, it explicits more
what it means :
alltrue(i<5 for i in l)
sometrue(i<5 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
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 b
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(i<5 for i in l)
sometrue(i<5 for i in l)
Another point is: as I agree there is already a huge lot of builtins,
shouldn't it be in some m
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
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"
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
> word
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
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 a
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[
> 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/confus
[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 feed
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
> See my blog:
http://www.artima.com/forums/flat.jsp?forum=106&thread=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.
Raymon
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 "first" and "last".
Bill
_
33 matches
Mail list logo
