On Wed, Jan 25, 2012 at 9:33 AM, Edward K. Ream <[email protected]> wrote:
> Here are the invert and uninvert methods, devoid of traces, asserts, etc.::
>
> def invert (self,d):
> '''Invert a shortcut dict whose keys are command names,
> returning a dict whose keys are strokes.'''
> result = {}
> for commandName in d.keys():
> if commandName == '_hash':
> result['_hash'] = 'inverted %s' % d.get('_hash')
> else:
> for si in d.get(commandName,[]):
> stroke = si.val # Already canonicalized.
> si.commandName = commandName # Add for uninvert
> aList = result.get(stroke,[])
> if si not in aList:
> aList.append(si)
> result[stroke] = aList
> return result
The special case for the "_hash" key is troubling. It would be better
to define a class with an ivar corresponding to d.get('_hash').
This kind of hack ruins the type inference for the types of values
contained in d, and adds unnecessary special cases to the code. Alas,
there are probably several other similar hacks that make Leo's
shortcut code much harder to understand than necessary.
This counter example shows that we programmers do *not* always know
the types of objects. But we *could* know, if we didn't use bad hacks.
The question for a "translate Python to C" project is whether we
could create tools that would either
a) warn about type botches or
b) help ensure (at design or coding time) that type botches such as
the above don't happen.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
