Comment on draft PEP for deprecating six builtins

[Brian Quinlan]

> The functionals (map, filter, and reduce) had greater importance prior
> to the introduction of list comprehensions which are now the preferred
> (and more readable) approach.  

reduce() does not have a list comprehension equivalent. What about
zip()?

> Pow() and divmod() are more related to math module functions than any
> of the built-in functions.  In general, they are rarely used.  Because
> the ** operator is available, the pow() function is rarely called
> directly.

pow() has an optional third argument, so the ** operator cannot act as a
direct replacement. Also, a pow function, with different semantics,
exists in the math module.

I've seen divmod() used in lots of code. 

And, if you are going this far already, why shouldn't abs() and round()
be moved too?

In any case, math seems like an odd home for these functions as all of
the routines currently in math work with doubles.

> The -b command line option and related environment variable would go 
> into Python 2.3 and remain available in perpetuity.

1. Using a command-line switch seems evil. The first 3rd party module
that someone uses will provoke them to add the -b switch, which will not
encourage them to fix their own code. 
2. Leaving the switch in forever doesn't make sense. 

Cheers,
Brian