Python Tutorial Was: Guido's regrets: filter and map

David Brown david at no.westcontrol.spam.com
Tue Nov 26 05:11:15 EST 2002


> map(), filter(), and reduce() do not represent all of the uses for filter,
> and thus, they can't all be replaced by list comps (BTW, I never used
> reduce, never understood what it was good for, and don't immediately
> see how it can be done using list-comps -- would be genuinely interested
> in seeing a couple of example if anyone's willing).
>

I've used reduce() a couple of times, such as for calculating checksums of
strings to/from a serial port.  But I wouldn't miss it much if I didn't have
it - a for loop would do just as well.

> So I think lambda still has a place, though I wouldn't want to increase
> its capabilities (such as making non-expression functions possible).

Agreed - if you make your lambdas too complicated, they won't fit on a line
or two, so you would be better off with a seperate function anyway.

>
> > I find lambda quite useful for creating simple anonymous functions to
pass
> > to GUIs as button commands and the like. I suppose the same effect could
be
> > obtained by adding a couple more lines to define a temporarily-named
> > function, but then I'd have to think up a name. I've been known to waste
> > hours trying to come up with names for new computers. I'm not quite so
> > indecisive about functions, but it does seem to be one of my weak
points.
>
> Agreed -- the general pattern of passing functions as first-class objects
> is supported by providing the simplicity of lambda for the degenerate
> case, just like numerical or aggregate data literals support passing
> variables (do I recall correctly that you couldn't pass literals to
functions
> in Pascal?  I remember being very annoyed by that, coming from
> Fortran).
>
> As for the pain of thinking up a name -- I think it's actually a good
> sign. It shows you care.  Good names are a real benefit to your own
> future self and to anyone else who must read your code. Though they
> weren't primarily interested in programming but in websites, I found the
> book "Information Architecture" (O'Reilly), to be very influential in
> my thinking about variable names and other "labels" -- which is the
> term they use.  Not saying I always live up to the ideal, but it gave me
> an ideal to try for. ;-D
>

Good names are the key to readable and maintanable programming.  But there
are plenty of cases where no name is better than some dummy name.  If you
have to refer to something, it should have a good, sensible name.  If you
don't have to refer to it, then it is an advantage to have no name - it
saves cluttering namespaces, and it makes dir() more useful.

> Cheers,
> Terry
>
> --
> Terry Hancock ( hancock at anansispaceworks.com )
> Anansi Spaceworks  http://www.anansispaceworks.com
>





More information about the Python-list mailing list