Making a dict from two lists/tuples

[Alex Martelli]

"Emile van Sebille" <emile at fenx.com> wrote in message
news:9ej1bl$36fcc$1 at ID-11957.news.dfncis.de...
    ...
> > for k, v in zip(keys, vals):
> >     d1[k] = v
    ...
> > map(d1.setdefault, keys, vals)
>
> > D:\Python21>python po.py
> > Plain: 0.126390609312
> > Fancy: 0.0406811366581

And for completeness, this:

for i in range(len(keys)):
    d1[keys[i]] = vals[i]

Plain: 0.121645314797
Fancy: 0.0390636130951
Emile: 0.0522468491814


> > The fancy/neat form seems to be better than
> > three times faster on my box, so it may be
> > worth using DESPITE its fanciness...:-).
    ...
> I think you mean that it may be worth doing BECAUSE of the SPEED increase.

Yep, that's exactly what I think I just wrote:-).

Given the speed increase, the "fancy" technique
may be worth using (and getting used to), just as,
say, one uses and gets used to accumulating pieces
of string in a list and then using ''.join() --
not as intuitive and clear as a loop of += ops
to build up the big string from the pieces, but,
hey, better get used to it, it's just faster by
too much!

Or similarly, beep.sort(fancycompare) versus
temp=[decorate(x) for x in beep]
temp.sort()
beep[:]=[undecorate(x) for x in temp]

and so on.  Certain idioms have too large a speed
advantage over their naive/more-intuitive
counterparts, so...

> One common argument is that optimizing in advance of profiling and despite
> clarity is simply wasting time.

Sure, but if I have two dozen cases in my program
where I'm building dictionaries from sequences and
keys and values (etc), I *particularly* do NOT want
to use one idiom in six cases and a different one
in the other eighteen, because the first six are
bottlenecks and the other 18 aren't.  Actually, here,
I can and no doubt should wrap it up in a function
(not so easy for other idioms quoted above).  But
that function needs to use the fastest idiom at hand
if it's EVER on a bottleneck.  This *particularly*
goes if I need the function so often that I make it
part of my standard back of tricks... can't have two
different versions, what benefit would this give?

What I hold in my mind as "THE" obviously correct
way to do task X plays a similar role to a function.
Keeping several idioms for one task to the forefront
of one's consciousness is somewhat of a waste of
mental resources unless it DOES make sense to use
different idioms in different circumstances.

> In particular, this idiom depends on a side
> effect of the function argument,

Right - said function argument being *DESIGNED* for its
side effect.  Side effects in function will no doubt
disgust FP purists and Eiffel ones, but pragmatically
speaking they're very much a part of Python, so...

> and throws away the normal result of map.

Yep -- it would no doubt be faster if said result
list wasn't built in the first place, but, oh well.

It's pretty normal to use map just for speed, because
"it loops faster"...


> That's hardly intuitive behavior, and reeks somewhat of bad oysters (;-)),

I do agree it's "fancy" (a criticism, coming from me).
I don't think it's SO fancy as to stink, though.

> although it may be proscribed standard practice at some shops.  The

"proscribed" == "forbidden", and you may mean "prescribed" (I
strongly doubt any shop "prescribes" such a fancy style, though
some may surely "proscribe" it:-).

> technique of iterating through the indexes (i.e. for i in
range(len(keys)):
> d1[keys[i]] = vals[i]) is clearer, and is still about 2 1/2 times faster
> than using zip.

Excellent point, and another silent tear to shed for the
lack of an 'indexing' clause on Python's "for":-).


Alex