On Wednesday, December 18, 2013 8:34:21 AM UTC-6, Edward K. Ream wrote:
>
> Rev 6432 contains the prototype of a simpler, faster, more flexible
> importer for Python files. This is a great day for Leo.
>
I've spent several hours recently playing with the new importer.
Everything I have seen so far indicates that the idea is completely sound.
It *will* be possible to use @auto instead of @file in many cases.
There are subtle design and usage issues involved, mostly involving section
references. In the old @auto code, section references were treated as
ordinary text, both when reading and when writing. For example, consider
this snippet from a unit test::
# This is valid Python, but it looks like a section reference.
a = b << c >> d
Imo, the new code must still handle lines like the above, but *in
addition*, the user should be able to add "light sentinels" by hand. For
example, consider this input file::
if 0:
def dump(*stuff):
pass
class testClass1:
pass
At present, the *new* importer produces::
if 0:
@others
<<class testClass1>>
with two child nodes, dump and <<class testClass1>>
This demonstrates all the essential features of the importer, but it would
be better to have the read and write code "conspire" to use light sentinels
inserted by the user.
Let me try to make the issues clearer. The new import code inserts @others
wherever possible, but if a node already has an @others, then the import
code *must* insert a section reference instead. In many cases, we would
prefer to have one or more section references (like << imports >>) precede
the @auto.
For example, it would usually be better style to write the example as::
if 0:
<<define dump>>
@others
But we can't do that directly if section references are ignored! Instead,
the *user* will have to write:
if 0:
#<<define dump>> <----- a light sentinel
def dump(*stuff):
pass
#> <----- a light sentinel
class testClass1:
pass
which in turn should allow the read code to something like:
if 0:
#<<define dump>>
@others
with the <<define dump>> node created as a child.
Even better, the user should be able to specify a **commented section
reference** directly in the @auto file::
if 0:
#<<define dump>> <----- commented section reference.
@others
As with legacy section references, a descendant <<define dump>> node must
exist. The @auto *write* code must support such commented section
references by producing the corresponding light sentinels in the
appropriate places. In turn, the @auto *read* code must honor the light
sentinels.
In the unlikely event that a file contains a commented section reference
"by mistake", the importer will not be affected at all. The write code may
issue a warning, or not. The user could easily "disable" such a section
reference, so this is a very minor point.
In short, it's not really the importer code that is the sticking point,
it's setting things up (a collaboration between the user and the new @auto
write code) so that light sentinels get placed in the external file as
needed. Imo, this clearly *is* possible.
Edward
P.S. The switchover from the old to new code will be challenging, for at
least three reasons:
1. Packaging issues are tricky because of the very complex nature of the
code in leoAtFile.py. I even contemplated refactoring the code, but
quickly abandoned the idea as not being even close to worth the effort.
2. Unit testing issues are tricky become some unit tests will have to
change in the new scheme. In some cases, I have forgotten what the unit
tests do, and the unit tests for imports (including @auto) are not easy to
understand.
3. As indicated above, initially the user may want to insert section
references in places different from what the "untutored" import algorithm
would produce.
EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
