ENB: Progress report re the python importer

[Edward K. Ream]

PR #2331 contains recent work on issue #2327, improve the python importer. This work has turned into a project :-)

1. As discussed previously, the importer infrastructure no longer uses fields injected into vnodes. Instead, a vnode_info dict contains all import-related data.  All importers use the 'lines' key; only the python importer uses other keys.

2. The unit testing infrastructure is simpler. A typical legacy test looks like this:

<< define s, representing the incoming file >>

 p = self.run_test(s)
 self.check_headlines(p, (

    << table of (level, headline) entries,

       one for each expected imported node >>

 ))

BaseTestImporter.run_test will fail if the perfect import test fails. The infrastructure now optionally (depending on Importer switches) shows the generated outline when a test fails.

All legacy tests use this pattern. Some legacy tests omit the call to BaseTestImporter.check_headlines.

3. There were severe, unexpected troubles using the legacy python importer in this scheme. It's no big deal. The new infrastructure is here to stay, and it's time to finish the new python importer.

4. The BaseTestImporter.create_expected_outline method creates an outline corresponding to the MORE representation of the expected outline. There was no reason to represent both the incoming lines and the expected lines in a single string. Here is the new pattern:

input_s = << the incoming file >>
expected_s = << the expected outline, in MORE format >>
self.run_python_test(input_s, expected_s)

This pattern will likely morph into something like:

<< define input_s >>

<< define expected s >>

self.run_test(input_s)

self.check_result(expected_s)

In other words, there is nothing special about python's unit tests.

Summary

Infrastructure work is complete. I shall start work on the python importer today.

Edward