There are other ways of getting the same effects now (list() or zip()
for map(None, ...)).

In the absence of an identity function, map accepting None is useful in 
the cases like this:

converters = {..}
y = map(converters.get(c), x)

That will now have to be rewritten as

conv = converters.get(c)
if conv is None:
   y = list(x)
else:
   y = map(conv, x)

and subtle bugs will be introduced if x is used instead of list(x) in 
the None case.

Another alternative,

y = map(converters.get(c, lambda x:x), x)

will be much slower.

Take my opinion with a grain of salt because I also believe None should 
be callable with None(x) -> x and None(x,y,..) -> (x,y,..).

Attached patch removes support for None from filter and 
itertools.ifilter.  My objections for removing that from map do not 
apply because bool function can be used instead of None in filter 
achieving similar performance and better clarity.

None support was apparently removed from map in r60206.

Remaining questions:

1. map(None,[]), filter(None,[]) and in fact map(anything,[]) still 
work.  I don't think that needs to be fixed.

2. Should None support be removed from itertools.ifilterfalse? I would 
guess yes, unless it is going away.

Let me assign this to Raymond for the answering of the question about
ifilterfalse.

Will think about ifilter() and ifilterfalse() for a day or two.  The
None argument handles the common use-case and there may be a good case
for keeping it.  If I do decide to drop it, will put in my own patch
that optimized for the case with the filter function is bool().

+1 On removing the None argument from map() and imap().  It was
hold-over from the days before zip().

Raymond,

There must be a reason why we constantly disagree.  Do you live in
California by any chance? :-)

I am not sure if map(None, ..) fate is still up for voting given your
changes at r60206, but your own patch illustrates the problem that I
highlighted:

< it = izip(map(key, in1), count(), in2)                  # decorate
--
> keys = in1 if key is None else map(key, in1)
> it = izip(keys, count(), in2)                           # decorate

See
http://svn.python.org/view/python/branches/py3k/Lib/heapq.py?rev=60206&view=diff&r1=60206&r2=60205&p1=python/branches/py3k/Lib/heapq.py&p2=/python/branches/py3k/Lib/heapq.py

With filter, availability of bool as a substitute for None is probably
making special handling unnecessary because __nonzero__ is called on
every object anyways.

In the case of map(None,...) the optimization is more substantial and
without None is precluded by the absence of a singleton identity function.

FWIW, I didn't disagree on filter().  Am taking your suggestion under
advisement for a couple days.  At this point, I'm leaning towards
accepting the request (although with a different version of the patch).

For map(None, ...), I happy to live with examples like the patch you
referenced. It's important that this API be as simple and clean as
possible.  It's a matter of taste.  I concur with Guido that we never
would have created map(None, ...) if zip() had existed.  The primary use
case is obsolete.  

Also, I think the motivation behind your other use case will likey be
addressed in a more general way with an identify function being added to
the operator module.  That is a more explicit and less hackish than
having a special meaning for None.  It is also more in-line with the way
functional language approach the same problem.

Will meditate on both of these for a couple days and get back.

Raymond,

it looks like you just broke the build for me:

/Users/sasha/Work/python-svn/trunk/Modules/itertoolsmodule.c: In 
function 'ifilter_next':
/Users/sasha/Work/python-svn/trunk/Modules/itertoolsmodule.c:2058: 
error: invalid operands to binary ==
/Users/sasha/Work/python-svn/trunk/Modules/itertoolsmodule.c: In 
function 'ifilterfalse_next':
/Users/sasha/Work/python-svn/trunk/Modules/itertoolsmodule.c:2202: 
error: invalid operands to binary ==

$ svn update Modules/itertoolsmodule.c
At revision 61073.

(Mac OS 10.4)

Alexander, please contact me directly at python at rcn dot com.

Need to figure-out why this works on my build but not yours.  There may
be an include file issue.

It appears Facundo fixed your problem.

What do you guys think about just making the predicate argument optional? 

   filter([-2,0,2]) --> -2, 2
   filter(pred, iterable)

One arg is the first case and two args is the second case.

> What do you guys think about just making the predicate argument 
> optional?

You've read my mind! That what I was going to suggest if I realized that 
optional argument does not have to be the last one.

Looks like it would make sense to keep filterfalse with a similar 
change.

> I think the motivation behind your other use case will likey be
> addressed in a more general way with an identify function being
> added to the operator module.

Quite true, but I thought operator.identity was dead and buried.  Can 
you update issue1673203 if some decision was made?

Note that in msg55022 I said: "If [the identity] proposal is accepted, 
it will make sense to deprecate the use of None as an identity function 
in map."  So there may be no disagreement at all.

>  What do you guys think about just making the predicate argument optional?
>
>    filter([-2,0,2]) --> -2, 2
>    filter(pred, iterable)
>
>  One arg is the first case and two args is the second case.

-1. Apart from range() this is used nowhere else in Python. (Well, it
is in curses, but it's an abomination there too.) I'd rather keep
explicit None that *this*, though I really don't see what's wrong with
filter(bool, ...) -- you can even optimize for that pattern.

Okay.  Will drop None in favor of bool() in ifilter and ifilterfalse. 
Also, it looks like there agreement on dropping None for map() and 
going forward with the operator.identity() patch.  Will check these in 
in the next couple of days.

Do you guys see any merit in changing the argument order for ifilter so
that the predicate function can just be an optional argument:

  ifilter(data[, pred])

Alex Martelli successfully lobbied for groupby() to have that same
argument order.  Originally, the signature was groupby(key, iterable)
but it worked-out much better to have groupby(iterable[, key]).

Also, I like swapped arguments because it more closely parallels the
order used in an equivalent list comprehension:

   [e for e in iterable if pred(e)]

It would break the symmetry with map().

Okay, thanks.  Though, I should have also mentioned symmetries with
sorted(), min(), and max() which all take the iterable first and follow
with an optional key function.

Closing this one. The map(None, *args) feature was removed for 3.0. 
Have decided to leave None in ifilter() and ifilterfalse() since None is
the preferred way to spell a default argument and having to pass "bool"
feels awkward and clunky. Switching the argument order was shot down, so
will just leave it as-is.

Marked resolution as "accepted" since the map(None) suggestion went in.

It may be too late to express my opinion, but why symmetry with map is 
so important?  There are several reasons why sequence, predicate order 
is natural for filter and function, sequence is a natural order for map.

1. In list comprehensions predicate comes last: compare [f(x) for x in 
seq] and [x for x in seq if pred(x)].

2. In English, map(f, sec) = "Map f over seq" while filter(pred, seq) = 
filter seq through pred.