can list comprehensions replace map?

[Raymond Hettinger]

[Paolino]
> Well, for my little experiences use cases in which the lists have different
> lengths are rare, but in those cases I don't see the reason of not being
> able
> to zip to the longest one.What is really strange is that I have to use
> map(None,....) for that,instead of another zip-like function which ,at
> least
> would be intutitive for the average user.Also map(None,...) looks like a
> super-hack
> and it's not elegant or readable or logic (IMO)
>
> I think zip comes to substitute the tuple.__new__ untolerant
> implementation.A dumb like me wuold expect map(tuple,[1,2,3],[2,3,4]) to
> work, so pretending map(None,....) would do it is like saying that None
> and tuple are near concepts, which is obviously an absurdity.

Yes, map(None, ...) lacks grace and it would be nice if it had never
been done.  The more recently implemented zip() does away with these
issues.  The original was kept for backwards compatibility.  That's
evolution.

My sense for the rest is that your difficulties arise from fighting the
language rather than using it as designed.  Most language features are
the result of much deliberation.  When design X was chosen over
alternative Y, it is a pretty good cue that X is a more harmonious way
to do things.

Some other languages chose to implement both X and Y.  On the plus
side, your intuition likely matches one of the two.  On the minus side,
someone else's intuition may not match your own.  Also, it leads to
language bloat.  More importantly, such a language provides few cues as
to how to select components that work together harmoniously.
Unfortunately, that makes it effortless to mire yourself in deep goo.

My advice is to use the language instead of fighting it.  Guido has
marked the trail; don't ignore the signs unless you really know where
you're going.



Raymond


"... and soon you'll feel right as rain."  -- from The Matrix