Speed: bytecode vz C API calls

[Jacek Generowicz]

"Francis Avila" <francisgavila at yahoo.com> writes:

> Aahz wrote in message ...

[about map]

> > and it's usually less readable than some other way of getting
> > speed.

Actually, I use map in my code because I find it very elegant and very
readable[*]. Usually, the speed has nothing to do with it. But if I
already have a map, and I'm interested in speed then I'm loathe to
replace it with something slower.

> I think in the OP's case, any little drop of speed he can get more than
> justifies the very, very slightly un-idiomatic use of map instead of a
> for-loop.

Why do you consider my use of map to be un-idiomatic? I want to
transform a sequence into another one, by applying a function to each
element of the original. This is exactly the point of map. What am I missing?

> Be warned that map() may go away in future Pythons, though....

Yes, I've heard idle rumours to this effect. I think it would be a
great shame.

Yes, I realize that there are list comprehensions. I appreciate both,
and find that sometimes one looks more natural than the other, and
sometimes it's the other way around. I find this ability to pick the
right-looking idiom worth more than a One Way To Do it principle.


[*] There seems to be a faction in the Python community which
    considers map, reduce, filter and lambda to be evil infiltrators
    from those perfidious inventions that are functional languages,
    and therefore the claim is made that they have no place in
    Python. Some newbies believe this **** and the myth spreads. Just
    my 2 cents.