filter and map / deprecated?

[Logan]

I read in PEP 279 the following comment by GvR:

"filter and map should die and be subsumed into list
comprehensions, not grow more variants."

Actually, I am using 'filter' and 'map' a lot in my scripts
(not really because they are necessary, but more because I
like them). Should I avoid the usage of 'filter' and 'map'
in the future? The above comment by GvR makes me a little
bit afraid that they will become deprecated one day and that
I will have to change many of my scripts then.

--
mailto: logan@phreaker(NoSpam).net

[Serge Orlov]

"Logan" <lo***@phreaker.nospam> wrote in message news:pa****************************@phreaker.nospa m...

I read in PEP 279 the following comment by GvR:

"filter and map should die and be subsumed into list
comprehensions, not grow more variants."

Actually, I am using 'filter' and 'map' a lot in my scripts
(not really because they are necessary, but more because I
like them). Should I avoid the usage of 'filter' and 'map'
in the future? The above comment by GvR makes me a little
bit afraid that they will become deprecated one day and that
I will have to change many of my scripts then.

You will have to port and and test your scripts on the new Python.
You aren't going to use them untested, are you? In case of
filter & map you will just have to (my guess) insert:
from legacy import filter, map
Using filter & map these days is discouraged, use itertools
module.

Anyway I think before they disappear they should be removed
from documentation and _books_ first. I mean old books should
become obsolete, new books and documentation should briefly
mention them in the legacy chapter. These are should be no
trace of them in the main chapters. And then the functions can
be actually removed from the Python core. I beleive this is the
least painful way to get rid of them. The cost of keeping them
in the core is very low, the main problem is documentation.
So the process of deprecitation should focus on the documentation.

-- Serge.

[John Roth]

"Logan" <lo***@phreaker.nospam> wrote in message
news:pa****************************@phreaker.nospa m...

I read in PEP 279 the following comment by GvR:

"filter and map should die and be subsumed into list
comprehensions, not grow more variants."

Actually, I am using 'filter' and 'map' a lot in my scripts
(not really because they are necessary, but more because I
like them). Should I avoid the usage of 'filter' and 'map'
in the future? The above comment by GvR makes me a little
bit afraid that they will become deprecated one day and that
I will have to change many of my scripts then.
My understanding is that they are on the list of functions
to go away in 3.0. Guido would like to get rid of all five
of the "functional programming" mechanisms. So far,
filter, map and apply have acceptable substitutes, and
the arm waving brigade is claiming that the new sum()
function will handle all "real" use cases for reduce. (You
can tell I don't agree, but that doesn't seem to be
relevant.) Lambda is the odd man out at this point.
I believe it's waiting on an acceptable syntax
for blocks, which seems to be very hard to do.

John Roth
--
mailto: logan@phreaker(NoSpam).net

[Matt Gerrans]

Also, I suppose if you were *really* in a rush and wanted to get old code
working, then all you'd have to do is add something like this to it:

def map( func, seq ): return [ func(x) for x in seq ]
def filter( func, seq ): return [ x for x in seq if func(x) ]

This will probably be less efficient than Serge's solution. It is probably
also better to have that self-documenting "from legacy ..." in there, to
boot.

I think after a using list comprehensions for a while, they become a lot
more comfortable though, so it is not such a bad thing to develop the habit
of using them instead. Then, in the fullness of time, map() and filter()
will begin to look funny.

[Terry Reedy]

"Logan" <lo***@phreaker.nospam> wrote in message
news:pa****************************@phreaker.nospa m...

I read in PEP 279 the following comment by GvR:

"filter and map should die and be subsumed into list comprehensions, not grow more variants."

Actually, I am using 'filter' and 'map' a lot in my scripts (not really because they are necessary, but more because I like them). Should I avoid the usage of 'filter' and 'map' in the future? The above comment by GvR makes me a little bit afraid that they will become deprecated one day and that I will have to change many of my scripts then.

Removing filter, map, etc, totally would be a
contentious and controversial move and would make
many people unhappy. I do not anticipate it.

It has been proposed on PyDev that they be moved
to a 'functional' module (name not yet decided),
perhaps with other stuff added, and I believe that
Guido said he would be amenable to that. This I
do anticipate. The threshhold for being in a
module is much lower than the threshhold for being
added to and eventually for remaining in the
builtins.

So I would continue with your preference with the
expectation that some years from now you would
have to run 2.x scripts through a search and
replace script to run them with Python 3. But I
expect that will be true anyway to cope with other
changes. I also expect that people will use
2.final for years after the arrival of 3.0 (Just
as 1.5.2 is still in use today.)

Terry J. Reedy

[Raymond Hettinger]

> I read in PEP 279 the following comment by GvR:

"filter and map should die and be subsumed into list
comprehensions, not grow more variants."

Actually, I am using 'filter' and 'map' a lot in my scripts
(not really because they are necessary, but more because I
like them). Should I avoid the usage of 'filter' and 'map'
in the future? The above comment by GvR makes me a little
bit afraid that they will become deprecated one day and that
I will have to change many of my scripts then.

Until Py3.0, we are shying away from deprecating things.
apply(), buffer(), coerce(), and intern() were moved to a
separate page in the docs for obsolete or non-essential stuff
but there are no deprecations.

The itertools variants of filter and map are proving to be
popular and will likely be around for a long time. I suggest
using them instead of the builtins since they are memory friendly
and scale-up nicely.
Raymond Hettinger