list/tuple to dict...

[Steve Holden]

Alex Martelli wrote:

> Pierre Fortin <pfortin at pfortin.com> wrote:
>    ...
[...]
> 
>>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.
> 
Yup. Make a mistake before c&p and you then have two places to fix it 
rather than one. Or three, or four, or an unknown number ...

> 
>>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?!
> 
One of the nicest things about c.l.py is its ability to soak up endless 
repetitions of the same enquiries from newcomers and remain (almost) 
unfailingly polite. I sense you are holding sclerotic tendencies in 
check with the utmost self-control here - well done! Humor, that's the 
trick.

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

More accurately, probably hasn't yet written enough code to appreciate 
the disadvantages of cut-and-paste methods. And I hope, now clued-up b y 
a master, likely to eschew the vile habit forthwith.

 >      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
> presenting!-))
> 
If only there were some way we could avoid having to repeat good advice 
so often (to avoid cutting and pasting it into so many c.l.py answers, 
for example).

Don't forget to take your blood-pressure medication :-)

just-heard-the-kettle-boiling-ly y'rs  - steve