suggestions for VIN parsing

[Rick Johnson]

On Monday, December 29, 2014 10:58:59 AM UTC-6, Vincent Davis wrote:

> Rick, Thanks for your suggestions, I was just starting
> version2 and wanted to do something like you suggest.
> Another question. I what to change the logic so that
> rather than return THE match it return all matches. I want
> to do this for 2 reasons, 1, it would act as a kinda test,
> If I only expect one match and I get more than I likely
> have a problem,

The best solution for this problem is to raise an exception.
And for completeness sake i would suggest creating a custom
exception.

class VINPatternDuplicityError(Exception):
    pass

try:
    vin_to_year(vin): # I like Tim's func-name better!
except VINPatternDuplicityError:
    print 'Oops, my logic is not sound *enough*!'
else:
    print 'Huh! Crossing my fingers and toes really does work!'

> 2, I found a more extensive (maybe better)
> list of frame numbers, I could see some overlapping
> although I have not looked real close yet.

Sorry, i don't have time to study the data set --  but If
your data set contains overlaps *within* the same "mapped set"
then you're forced to handle those as special cases. 

============================================================
 Also, i just realized a few minor flaws with my approach:
============================================================

1. Since my logic is *ONLY* iterating over the keys of the
mapping set, a good old "linear-access data structure" (like
list or tuple) would be a better choice for each of the
"mapping sets", and by using a linear data structure, you can
control the order of range tests.

    This could be useful in catching corner cases early!

2. I used "tuples-for-keys-and-strings-for-values" in each
of my unique map sets, and although Python will happily
accept this sort of hash, i can't help but feel that it is
in some way "unnatural". Although we are looking up year
values based on ranges, and the natural "left-to-right"
order dictates *unconsciously* that keys should be ranges
and values should be years, iteration is not bounded by
these ritualized "reading and comprehension laws", NO, and
as such, storing year values as keys and ranges as values is
perfectly acceptable -- and only requires a small change to
the iteration logic.

However, if you ever *did* decide to change the order from a
"left-to-right" to a "right-to-left" please be sure to write
a thoughtful comment explaining how and why this approach
was taken, because, even though we (as programmers) tend to
be a logical bunch, we are still slaves to unconscious
"natural instincts" when reading and comprehending written
text, and as such, our comprehension system can break down
when faced with relationship that contradicts our
internalized idea of what is "natural".

    Somewhere a malevolent English teacher is smacking a ruler
    on her palm and smiling a most devilish grin. <--SADIST!