Re: [Python-Dev] Adding any() and all()

2005-03-13 Thread Eric Nieuwland
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(), and perhaps some should apply to sets as well.

--eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-12 Thread Greg Ewing
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 fashion.
Is there really any need for another module just for this?
The distinction between reductive and non-reductive operations
on iterators seems rather too fine to me to deserve a whole
new module.
Why not just put them all in itertools?
[1] While any()/all() read well in the context of an if statement, I 
think anytrue()/alltrue() better convey the reductive nature of the 
operations, read nearly as well in the if context, and read 
significantly better when isolated from the if context (e.g. assigned to 
a variable).
I don't agree. I think 'any' and 'all' are fine names for
boolean-valued functions in any context. Including 'true'
in their names smacks of the same kind of redundancy as
  if blarg == True:
...
which is widely regarded as a naive-newbie style blunder
in any language.
+1 on 'any' and 'all'
-1 on any names including 'true' or 'false'
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Brett C.
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 extra line that
it takes to get the same effect with an explicit for loop and if
statement.

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 is it to have 
an extra line or two in your code?

Basically the question (at least in my mind) when it comes to built-ins is 
whether the usage is so basic and fundamental that sticking them in a module is 
done more for rigid organization than for convenience.  Personally, I think 
any() and all() meet this requirement.  With their ties to basic boolean 
testing they should be built into the language and not just a part of the 
stdlib.  If I am banging something out at a interpreter prompt I will want 
these functions easily accessible and I won't think of them as something to 
import.  This probably comes off as wishy-washy, but it is just what my mind is 
spitting out at the moment.

They also have the feeling as something that could be useful as a syntax 
(although I am just suggesting syntactic support!).  Which could be an even 
better way to measure whether something should be a built-in.  Would the 
function be useful as a syntactic addition to the language, but just can't 
quite reach the need of a new keyword?  Once again any() and all() feel like 
that to me.

These aren't *really* replacing map/filter/reduce because you're
adding the new functions now, but the old-function removal is 
waiting until (forever?)

Even if Python 3000 comes out a while from now, why wait?  Two more is not that 
much.  Besides, it isn't like we are adding functions as some crazy rate.  And 
Guido has stated that the 2.x branch stops once 2.9 (if it goes that long) 
comes out.  So at worst you only have to worry about 5 more releases to worry.  =)

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Hugh Secker-Walker
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
modeling mammalian auditory physiology.  And I have a relatively-large
collection of photos of Tim Peters.


> Raymond Hettinger:
> Will leave it open for discussion for a bit so that folks can voice
> any thoughts on the design.

Ignoring the important naming issues, I have two comments about the
any() and all() ideas:

1. I'm surprised that no one has suggested adding supporting unary
   methods to object, returning a boolean.  If __any__ and __all__
   existed, then containers that observed that their contents were
   immutable could rely on a single counter, self._numtrue, to
   implement the any and all operations in O(0) time via appropriate
   comparisons with __len__() (plus the amortized cost of maintaining
   self._numtrue).  Of course builtin containers could or will do this
   anyway.

2. In an offline discussion about using any() and all() a couple of us
   noticed their similarity to the containment operator 'in'.  Taking
   this idea as far as it can go in Python as we know it, you could
   introduce new keywords, 'any' and 'all', and corresponding byte
   codes dispatching to __any__ and __all__, giving the emminently
   readable usages:

   if any x:
   ...

   if not all y:
   ...

   This latter idea may be far-fetched.  But if there's any chance it
   would happen, it adds a twist to the naming issue.  Were this
   syntax introduced after any() and all() were available as builtins,
   simple use of 'any(blah)' would still work, but references to the
   no-longer-rare tokens 'any' and 'all', e.g. as functional objects,
   would, of course, no longer compile.

-Hugh

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread M.-A. Lemburg
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 if statement), and there's no confusion
there; (2) anyFalse() and allFalse() are redundant, so there's no need
to distinguish between anyTrue() and anyFalse(). (To the person who
wondered why we default to True: because 'if' tests for True, duh. :-)
I've been using exists() and forall() in mxTools for years.
The names originate from math usage, where you often
use these qualifiers.
A note on builtins: Most tools in mxTools automatically
get registered as builtins when you load the module. The
motivation for this was that wanted to have easy access
to these often used APIs.
However, a few years down the line I realized that this
kind of usage just causes confusion when you read code:
* it is not clear where the APIs originate
* the code dependencies are not longer easily visible
Ever since, I've switched to making all use of these
functions explicit with reference to the mx.Tools
module.
http://www.egenix.com/files/python/mxTools.html
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source  (#1, Mar 12 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread John Williams
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 is it to have 
an extra line or two in your code?
The problem with this approach is that any() and all() are so 
fundamental* that you should just use them without thinking about it, 
just as when you use "+" to conctenate strings, you don't have to stop 
and think to yourself, "Ah, this program needs to be able to manipulate 
strings.  I'd better make sure string operations as available in this 
module."  Thinking such thoughts takes you away from thinking about the 
problem you're trying to solve by manipulating strings.

Likewise, programmers solve a lot of problems with boolean expressions, 
and it seems silly to require a special declaration just to make the 
full complement of boolean operations available.  I can think of three 
ways of coping with any() and all() being in a module:

First, I could just not use them.  In that case all the effort here is 
wasted, and my code becomes less readable than it would have been 
otherwise.  This is the approach I usually take with modules like 
"operator", where I can just as easily write a lambda expression (for 
now at least).

Second, I could break my concentration to think about import statements 
every time I have a use for these particular functions.

Third, I could import them at the top of every module.  Since one of the 
distinguishing features of Python in a lack of gratuitous boilerplate 
code everywhere, I would find it very sad to add even a little bit.

So while putting any() and all() into a module isn't that bad in itself, 
 it seems like the start of a slippery slope that has Python at the top 
and C++ at the bottom.

-- jw
*I appreciate the irony of calling something "fundamental" when we've 
all gotten by just fine without it for many years--I'm trying to think 
from the perspective of someone used to dealing with a later (and 
hopefully better) version of Python.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread François Pinard
[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 would be a waste.  In other contexts dans `if' or `while',
`any(...)' might be read as "pick one of", in which case a True/False
result might be surprising. `allTrue' (or such) is clearer in all
contexts, even if not as nice in some of them.  For `any(...)' to be
clear in all contexts, it should return one of its arguments.  That
would surely do the proper thing in `if' or `while' context.

We've read various arguments about this idea.  Some (pro or con)
arguments are only valid outside `if' and `while' context, other (pro
and con) arguments are only valid within `if' and `while' context.  If
we are going to dismiss contexts outside `if' and `while', we should not
retain arguments which only apply outside those contexts.

This is my only complain.  The overall idea and principle are good,
especially if they succeed in cleaning out `reduce' and the others.
However, if for compatibility reasons, `reduce' stays, than we are
merely adding other ways, without sparing any, and this means yet
another tiny bloat in Python, that might be better avoided.

> What worries me a bit about doing a PEP for this simple proposal is
> that it might accidentally have the wrong outcome:

Isn't that true of any PEP?  I thought going through a PEP for changes,
and additions just as well, was not far from being a principle.
Depending on opinions, the outcome is right or wrong.

The principle of PEPs is not necessarily a good one in practice, as some
PEPs are forever incomplete or unupdated, miss their role, and then sum
up to having nearly been an annoyance.  Good if PEPs may be avoided! :-)

-- 
François Pinard   http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Barry Warsaw
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Adding any() and all()

2005-03-11 Thread Jim Jewett
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 extra line that
> it takes to get the same effect with an explicit for loop and if
> statement.

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 is it to have 
an extra line or two in your code?

These aren't *really* replacing map/filter/reduce because you're
adding the new functions now, but the old-function removal is 
waiting until (forever?)

A compromise (which may not be worth doing) would be to put
them in another module, and then import them into  __builtins__
if desired.  map/filter/reduce could be moved out (but reimported
for at least 2.5) in the same way, which would make their 
inclusion look more like "standard policy" than "part of the 
language".

[And yes, I know that itertools might be the "wrong" module; I 
just don't remember the name of the module for iteration-related 
tools that happen to return something other than an iterator.]

-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Alex Martelli
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* (as one would expect) the GD nuisance of converting x's items 
to str (hellishly hard to document accurately and clearly, but 
extremely convenient!-).

Which reminds me -- could we have a methodcaller relative to attrgetter 
and itemgetter?  "Sort a list of strings in a case-insensitive way" 
would become *SO* easy with sort(dalist, key=methodcaller('lower'))... 
can't REALLY recommend sort(dalist, key=str.lower) then the items of 
dalist MIGHT be either str or unicode items... (the relevance of 
''.join is that it proves SOMEbody considered it important to deal with 
a list of either str or unicode in the joining context... why not in 
the sorting context then?).

Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Alex Martelli
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 all() [[indeed, I think a 
similar approach to any and all might be best: have them return an item 
from the sequence, an empty sequence uses the optional second item 
defaulting to something reasonable -- 0 for sum, False for any, True 
for all, for example]] in a neatly explicit way.  As I recall, I had 
tried to handle non-empty sequences by picking the first item and doing 
following + on it (with internal implementation specialcasing for 
strings, to avoid an "attractive nuisance" situation), and you cut the 
gordian knot by pronouncing about the second argument with a default of 
0 (I immediately thought your pronouncement was excellent and I still 
can't see why it wouldn't be).

Forcing the user to provide a 2nd arg when summing a sequence of 
non-numbers (say, datetime.timedelta instances, that's one example that 
ended up in the 2nd ed Cookbook) is good because it ensures a good 
return value when the sequence is empty (say, timedelta(0) rather than 
0 as a number).

If you're considering revisions to sum's design, my suggestion would be 
to find a way to let the user tell sum to use a more accurate approach 
when summing floats.  Summing a million floats with a loop of 
total+=item loses a LOT of accuracy (several digits' worth!) -- but 
doing the summation the right way takes O(N) auxiliary temporary space, 
so both approaches (the naive, performance-optimized accuracy disaster, 
and the expensive but accurate one) should ideally be available.  An 
optional use_partials keyword argument defaulting to False, for 
example, might allow that... (again, I've hopefully clarified the 
issues in another 2nd ed Cookbook recipe, I guess I can post that if it 
helps).

Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Barry Warsaw
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 Python 2 to Python 3.  So while I would
lament the loss of lambda too, I think its impact on my code will be in
the noise compared to dealing with "optional" static typing and the
truly saddening loss of <>.

there's-a-wink-in-there-somewhere-ly y'rs,
-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


RE: [Python-Dev] Adding any() and all()

2005-03-11 Thread Barry Warsaw
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 go; I've used it maybe a handful of
times in all my years of Python.  Using a list comprehension instead of
map() is fine too, but I'll miss the filter(None, seq) idiom.  Ping's
suggested list comprehension abbreviation, i.e.:

[x in seq if x] == [x for x in seq if x]

might help.

> Lambda will be more difficult.  Eric Raymond adapted an anti-gun control
> slogan and said "you can pry lambda out of my cold dead hands."  A bunch
> of folks will sorely miss the ability to create anonymous functions on
> the fly.  When lambda is used for deferred argument evaluation (a la PEP
> 312), the def syntax is a crummy substitute.

Yeah, I'm with you here.  As warty as lambda is, it just is so damn
convenient some times.  I've recently been using it as a companion to
property(), providing concise definitions of read-only attributes.

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread M.-A. Lemburg
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 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.
Nope. Think of the side-effects that can occur as a result
of calling the function argument n times with different
arguments. itertools only help if the functions don't have
side-effects.
Iteration is nice, but not the solution to everything :-)
Lambda will be more difficult.  Eric Raymond adapted an anti-gun control
slogan and said "you can pry lambda out of my cold dead hands."  A bunch
of folks will sorely miss the ability to create anonymous functions on
the fly.  When lambda is used for deferred argument evaluation (a la PEP
312), the def syntax is a crummy substitute.
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).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source  (#1, Mar 11 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


RE: [Python-Dev] Adding any() and all()

2005-03-11 Thread Raymond Hettinger
> 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 functional module.  The map() and filter()
functions are already covered by the itertools module.

Lambda will be more difficult.  Eric Raymond adapted an anti-gun control
slogan and said "you can pry lambda out of my cold dead hands."  A bunch
of folks will sorely miss the ability to create anonymous functions on
the fly.  When lambda is used for deferred argument evaluation (a la PEP
312), the def syntax is a crummy substitute.



> 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
> that string concatenation is apparently O(N) rather than O(N**2) (is
> that right, Raymond?) maybe this could be revised.

str.join() is still the best practice for string concatenation.  

Armin's optimization doesn't appear in other implementations of Python.
In CPython, it has a set of pre-conditions that are usually but not
always True.  IIRC, it also doesn't apply to Unicode and ASCII mixed
with Unicode.

Also, the optimization is part of ceval.c and would not be triggered by
sum()'s call to PyNumber_Add().  That limitation is not easily removed
because the optimization depends on an interaction between the stack,
variable refcounts, and the sequence of opcodes.

IOW, your original pronouncement on the subject should remain in effect.



Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Barry Warsaw
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 builtin or a variable.

> Personally, I think Python has too many builtins already.

I agree.  Personally, I'd rather see 'all' called 'every' (I'm less sure
about 'any' being called 'some'), and I'd rather see these put in some
module other than builtin.

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Guido van Rossum
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 there's no confusion
there; (2) anyFalse() and allFalse() are redundant, so there's no need
to distinguish between anyTrue() and anyFalse(). (To the person who
wondered why we default to True: because 'if' tests for True, duh. :-)

Whether to always return True and False or the first faling / passing
element? I played with that too before blogging, and realized that the
end case (if the sequence is empty or if all elements fail the test)
can never be made to work satisfactory: picking None feels weird if
the argument is an iterable of bools, and picking False feels weird if
the argument is an iterable of non-bool objects.

Whether to use each() and some() instead of all() and any(), to
preserve variable namespace: each() in particular (and some() to some
extent) emphasizes the individual element, while all() emphasizes the
whole set. As long as we accept that the return value should not
return one of the arguments elements, I prefer emphasizing the group.
The namespace argument doesn't weigh much in my mind; there's no
backwards incompatibility, and there are plenty of builtins that are
routinely reused as variables (e.g. str, file, id, type) without
apparently affecting readability. Context helps a lot!

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 extra line that
it takes to get the same effect with an explicit for loop and if
statement.

What worries me a bit about doing a PEP for this simple proposal is
that it might accidentally have the wrong outcome: a compromise that
can carry a majority rather than the "right" solution because nobody
could "sell" it. Yet, if people really feel strongly that there are
more issues that need to be discussed, and they think it's worth their
time, let someone stand up now to own the PEP and guide the
discussion. But personally, I think it's more efficient if Raymond
just checks in his code now. :-)

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. The PEP, in addition to making a really strong case for each of
the removals, will have to deal with a deprecation period, possibly
moving the functions to a "functional programming" module, etc.

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
that string concatenation is apparently O(N) rather than O(N**2) (is
that right, Raymond?) maybe this could be revised.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Jeremy Hylton
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 slated for disappearance, too.

I think I'd miss reduce, but I'd be happy to have it moved to an
extension module.  There's no need for reduce to be a builtin.  I'd be
very happy to have any and all around.

Jeremy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Guido van Rossum
> 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. Builtins will be followed by a '('; the variables won't.
(Obviously there can be exceptions, but in practice very, very few.)

> 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 slated for disappearance, too.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Nick Coghlan
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.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Rodrigo Dias Arruda Senra
[ 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 False in (x > 42 for x in S):
> > instead of "all"?
>
> Because "any" and "all" have shortcut semantics (they
> return as soon as they can determine the final result).
[ Guido ]:
--
> See my blog:
> http://www.artima.com/forums/flat.jsp?forum=106&thread=98196
> Do we even need a PEP ?
In the absence of a PEP, soon will see in c.l.p discussions like:
"""
 For completeness sake shouldn't there be a optimiztion
 version for  nonetrue() ?
 def nonetrue(S):
 for x in S:
 if x:
 return False
 return True
 why not allfalse() ?
 Due to the previous use of sometrue(), guess it becomes
 easier to remeber nonetrue() than allfalse().
 One may argue for aliasing(nonetrue, allfalse), and we are
 back to _builtin pollution_.
"""
So, people might fallback to any() and all(),realising that:
'''not all()''' meaning somefalse()
'''not any()''' meaning nonetrue()==allfalse()
All I'm saying: +1 for the PEP.
OFF-TOPIC:
It is curious though that we choose to read an *implicit*
True in [all(), any()] instead of an implicit False.
I guess that is a moral or ethical choice coming from the Human
realm, favouring Truth instead of Falsity. But that difference
does not hold in the Boolean realm .
best regards,
Senra
--
Rodrigo Senra
MSc Computer Engineer [EMAIL PROTECTED]
GPr Sistemas Ltda   http://www.gpr.com.br
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Nick Coghlan
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 be oriented 
towards consuming iterators in a reductive fashion.

product(), anytrue() and alltrue() were obvious candidates for inclusion ([1]).
The combination of explicit for loops and a standard toolkit of reductive 
operations was designed to eliminate the need for reduce() ([2]).

Cheers,
Nick.
[1] While any()/all() read well in the context of an if statement, I think 
anytrue()/alltrue() better convey the reductive nature of the operations, read 
nearly as well in the if context, and read significantly better when isolated 
from the if context (e.g. assigned to a variable). I also think the names are 
less likely to collide with existing variable names.

[2] I'm firmly in Guido's camp on this one - whenever I encounter code that uses 
reduce(), I have to rewrite it (either mentally or literally) to use a for loop 
before I can understand it. Getting rid of the function would benefit me because 
I would no longer have to waste time figuring out what such code was doing - it 
would already be an explicit loop, or it would be using one of the standard 
reductive operations.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Pierre Barbier de Reuille
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 module ? Perhaps in itertools ?

Pierre
PS: It's my first post on the list, even if I'm reading it for a few 
months now ^_^

Peter Astrand a écrit :
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 thought of as a list of

Using "any" and "all" as variables hides the builtins, but doesn't
disallow their use elsewhere. Personally, though, I wouldn't use "any"
or "all" as variable names, so that's a style issue.

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 builtin or a variable.
Personally, I think Python has too many builtins already.
/Peter Åstrand <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/pierre.barbier%40cirad.fr
--
Pierre Barbier de Reuille
INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France
tel   : (33) 4 67 61 65 77fax   : (33) 4 67 61 56 68
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Samuele Pedroni
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" is usually thought of as a list of
 

 

Using "any" and "all" as variables hides the builtins, but doesn't
disallow their use elsewhere. Personally, though, I wouldn't use "any"
or "all" as variable names, so that's a style issue.
   

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 builtin or a variable.
Personally, I think Python has too many builtins already.
 

to extend the naming pool, FWIW CL calls similar things EVERY and SOME.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Peter Astrand
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 thought of as a list of

> Using "any" and "all" as variables hides the builtins, but doesn't
> disallow their use elsewhere. Personally, though, I wouldn't use "any"
> or "all" as variable names, so that's a style issue.

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 builtin or a variable.

Personally, I think Python has too many builtins already.


/Peter Åstrand <[EMAIL PROTECTED]>

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread Paul Moore
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 out for. Also, "all" is usually thought of as a list of
> (all) things. In my mind it doesn't make sense (yet) that all(seq)
> returns true if all elements of seq is true and false otherwise, I
> would have expected "all" to return a list. "any" is better because it
> is very obvious it can only return one thing.

Using "any" and "all" as variables hides the builtins, but doesn't
disallow their use elsewhere. Personally, though, I wouldn't use "any"
or "all" as variable names, so that's a style issue.

As far as the names making sense is concerned, they are perfect in context:

if all(i > 0 for i in int_list):

if any(invalid(s) for s in input_values):

While you may think that use in any other context looks a little less
natural (something I'm not convinced of), in the intended context, the
names seem ideal to me.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-11 Thread BJörn Lindqvist
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 doesn't make sense (yet) that all(seq)
returns true if all elements of seq is true and false otherwise, I
would have expected "all" to return a list. "any" is better because it
is very obvious it can only return one thing.


-- 
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-10 Thread Aahz
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 a
>> predicate.  Also, it avoids the kind of errors/confusion that people
>> currently experience with Python's unique implementation of "and" and
>> "or".
>> 
>> Returning the last element is not evil; it's just weird, unexpected, and
>> non-obvious.  Resist the urge to get tricky with this one.  

+1

> Fine, but then let's keep reduce(), which has this nice property.

-1
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code -- 
not in reams of trivial code that bores the reader to death."  --GvR
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-10 Thread Jack Diederich
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 should be called "first" and "last".
> 
> -1
> 
> 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 that people
> currently experience with Python's unique implementation of "and" and
> "or".
> 
> Returning the last element is not evil; it's just weird, unexpected, and
> non-obvious.  Resist the urge to get tricky with this one.  

Perl returns the last true/false value as well, and it is a subtle trap.
I worked at a perl shop that had a long style guide which outlawed using
that side effect but people did anyway.  I'm +1 on having it return a
true boolean for the same reason "if (x = calc_foo()):" isn't supported,
if there is a quirky side effect available someone will use it and someone
else won't notice.
[in fact we had a guy who was "downsized" for doing things like calling
database queries on the return value of a function that was documented
as returning True/False]

Perl shops require long style guides becuase perl is, ummm, perl. Python
is a boon because YAGN (a style guide).  The fewer side effects the better.

-Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-10 Thread Bill Janssen
> 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 that people
> currently experience with Python's unique implementation of "and" and
> "or".
> 
> Returning the last element is not evil; it's just weird, unexpected, and
> non-obvious.  Resist the urge to get tricky with this one.  

Fine, but then let's keep reduce(), which has this nice property.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


RE: [Python-Dev] Adding any() and all()

2005-03-10 Thread Raymond Hettinger
[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 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 that people
currently experience with Python's unique implementation of "and" and
"or".

Returning the last element is not evil; it's just weird, unexpected, and
non-obvious.  Resist the urge to get tricky with this one.  


Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-10 Thread Phillip J. Eby
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 "first" and "last".
More precisely (since "S" might be an iterator, or empty):
def any(S):
x = False
for x in S:
if x: break
return x
def all(S):
x = True
for x in S:
if not x: break
return x
However, "first" and "last" don't make sense to me as names.  First 
what?   Last what?  Actually, "any" and "all" don't make that much sense to 
me either.  I find myself wanting to call them "or" and "and", or maybe 
"or_iter" and "and_iter".  Or perhaps "until_false" or "until_true".  Nah, 
the and/or names make more sense, as they exactly match the behavior of the 
corresponding logical operators, if you could call them as a function.  At 
least, if they took *args anyway.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


RE: [Python-Dev] Adding any() and all()

2005-03-10 Thread Raymond Hettinger
> 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.


Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding any() and all()

2005-03-10 Thread Bill Janssen
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Adding any() and all()

2005-03-10 Thread Guido van Rossum
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?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com