list/tuple to dict...

Alex Martelli aleaxit at
Thu Sep 16 10:16:28 CEST 2004

Pierre Fortin <pfortin at> wrote:
> class todict:
>     """ Converts a list/tuple to a dict:  foo = todict(values,names) """
>     def __init__(self,values,names):
>         self.d = {}
>         for i,name in enumerate(names.split(",")):
>             self.d[name.strip()]=values[i]
>     def __setitem__(self, name, value):
>         self.d[name]=value
>     def __getitem__(self, name):
>         return self.d[name]

You can implement this exact functionality (not worth it for os.stat, of
course, which already does return a pseudotuple with named items) in a
probably better way...:

import itertools


   def __init__(self, values, names):
        self.d = dict(itertools.izip(
            map(str.strip, names.split(',')),

However, as recently discussed on this group, this is going to put a
dictionary in EVERY instance of 'todict' dealing with the same sequence
of names.  Normally when you deal with tuples whose items have certain
names, you will deal with a lot of such tuples with the same item names.
It seems better to me to make a TYPE which deals with the name-to-index
mapping, then instantiate that type as needed with tuples of values.

> Over time, I'll probably build a list of functions I use and just
> copy/paste the line(s) I need:

Copy and paste is a BAD way to reuse software.  Very, very bad.  Anybody
with the least experience maintaining big programs will confirm.

> Is there a way to rewrite the class to allow for calls which take parms to
> include the parms in the resulting dict..?  I'm probably trying to get too
> cute here though... :^)

You can easily add keyword args to the __init__:

   def __init__(self, values, names, **kw):
        self.d = dict(itertools.izip(
            map(str.strip, names.split(',')),
            values), **kw)

This way you can set extra parameters as you instantiate todict.

> The newbie who gets to read (maintain?) my code should have an easier
> time; at least, that's my intent...  Though Alex will probably consider
> this boilerplating...  I think .some. boilerplating is good...   B-]
> Other suggestions welcome :^)

My suggestion is to rethink your thesis that some boilerplate is good.
The first time in your life you must make a change and hunt down every
place you have c&p'd your boilerplate -- forget some place and get
anomalies -- etc, etc -- you'll see why.  But why _must_ some people
make themselves the mistakes many previous generations have already
made, when members of those older generations keep alerting them to said
mistakes?  Can't you be original and make YOUR OWN brand-new mistakes?!

Ah well.  Making a specific type for each given sequence of item names
is clearer, conceptually preferable, faster, not wasteful of memory, and
lacks any countervailing counterindication -- yet you like boilerplate,
you like copy and paste, and _want_ all of the overheads you pay to get
them.  OK, I'm not going to repeat once again the details on how to make
a type -- I must have posted them three times over the last 10 days or
so, enough is enough.  Just one last attempt at motivation in case you
are at all superstitious...: should anybody else ever find themselves
maintaining your sw and find out that you DELIBERATELY inflicted this
chore on them because of your preference for boilerplate and c&p over
cleaner and lighter-weight approaches, don't be surprised if your tea
kettles never boil, your cat scratches you, and you find yourself having
to get new tires often because you keep hitting nails and shards of
glass on the street... it's just the MILDEST kind of curses those poor
software maintainers are streaming towards you constantly, starting to
work on the astral plane...  ((ok, ok, I don't necessarily _believe_
this, but hey, if anybody does and I can thereby motivate them to write
better sw than they otherwise would, why, I think that's justification
enough for this little white, ahem, working hypothesis I'm


More information about the Python-list mailing list