Making a dict from two lists/tuples

[Emile van Sebille]

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:9ej4b401cvs at enews1.newsguy.com...
> "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() --

Good point.  Then why do you later below suggest it likely would not be best
that some shops prescribe it? (Now that I've got those two sorted out.)

> 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!

But here, the difference is not huge, and the fancy technique is only
available in 2.0+ versions of python.  Besides, I though you would enjoy the
gap that bridges the two timings (0.039 vs 0.052) and prefer the second as
being more complete.  ;-)

>
> 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?

In general I agree.  But, suppose you take it a step further:  Assume that
you've profiled, and that one of those loops is still a severe bottleneck.
Now you've introduced (or are about to) a different version anyway.
Further, if at some point an efficient indexing option existed for 'for',
you'll either re-write occurences of older techniques (possibly a *lot* of
work), or live with two techiques in the code base anyway, or ignore the
benefit of improving these constructs by adhering to your internal
standards.  In any case, it becomes likely that support programmers will
need to recognize or work out these idioms, and that not all idioms in use
will be the best, fastest, most memory efficient, etc.

>
> 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.

The (obscure) reference was to PEaRL not stink, and its reputation for code
fragments that depend on side effects.  ;-)  I simply meant that

>
> > 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:-).

Yep.. prescribe is what I meant. My point there parallels your point above.
Select the idiom to use, publish it internally as a standard, and stick to
it.  Although I wouldn't be surprised to find it (or examples like it)
somewhere in some shop's standards manual.

Regards,

--

Emile van Sebille
emile at fenx.com

---------