Comments on Version 2, Draft Pep for Deprecating Builtins

[Grant Edwards]

In article <Xns91FF9515A57Eduncanrcpcouk at 127.0.0.1>, Duncan Booth wrote:
> holger krekel <pyth at devel.trillke.net> wrote in 
> news:mailman.1020082610.7467.python-list at python.org:
> 
>> Btw, what is the best/shortest way to express 'filter' and 'reduce' with 
>> list comprehensions?
> 
>  filter(fn, lst)
> becomes:
>  [ v for v in lst if fn(v) ]

I find the former far more readable.

>  filter(None, lst)
> becomes:
>  [ v for v in lst if v ]

Same here.

> If the second argument to filter is a string or tuple then you have to 
> convert the resulting list back to the appropriate type:
> 
> e.g.
>  filter(fn, aString)
>  str.join('', [ v for v in aString if fn(v) ])

IMO, claiming that the latter is not less clear is pretty bogus.

> reduce doesn't return a list, so a list comprehension is not an
> appropriate replacement.
> 
>  reduce(fn, seq, initial)
> becomes:
>  res = initial
>  for v in seq: res = fn(res, v)

I find the "reduce" spelling simpler and easier to both read
and write.

> All of these replacements are big winners if they remove a use of the 'l' 
> word.

If getting rid of "lambda" is the goal, then why not state that
openly and propose elimination of "lambda".

> I don't think any of them lose in clarity even if there are no 'l's 
> around.

You've got to be kidding -- especially looking at the "reduce"
and "filter a string" examples.

If you want to move map/filter/reduce into a module, fine.  I
think it's too much breakage for too little gain, but whatever...

However, claiming that they aren't useful because the above
"replacements" are just as clear is just silly.

-- 
Grant Edwards                   grante             Yow!  NOT fucking!! Also
                                  at               not a PACKAGE of LOOSE-LEAF
                               visi.com            PAPER!!