ENB: 20 years of lint removed from leoAtFile.py
46 views
Skip to first unread message
Edward K. Ream
Apr 10, 2017, 1:38:15 PM4/10/17
to leo-editor
This is an engineering notebook post. It will be of interest primarily to devs.
The js branch contains the new code. I created this branch to fix bugs in the javascript importer, but the changes needed quickly resulted in the massive housekeeping I am about to describe. This housekeeping was greatly aided by the new "hasattr" pattern.
tl;dr: Many switches in methods of the AtFile class were confusing or unnecessary. The new code is now as simple as I can make it. Afaik, there are no more "huh?"s left.
The hasattr pattern
The new pattern, described here, allows direct communication between code that wants to set a flag and code that uses the flag. Intervening methods have no knowledge of the communication. In particular, there is no need to pass the flag around. This pattern has been a spectacular success in the two or three places it is used.
The new hasattr pattern seems like the reverse of exception handling. Exceptions pass data up the calling tree. The new pattern passes data down the calling tree.
What I did
- Removed trialWrite from all methods except at.writeOneAtAutoNode.
Only linescanner.Importer.trial_write sets this flag, so it's fairly clear from context what is going on.
- Removed perfectImportFlag.
- Replaced forceSentinels by hasattr(at, 'force_sentinels').
- Replaced partialFlag by force.
- Removed all thinFile code from the AtFile write logic.
thinFile still exists in Leo's read logic, so that Leo can read ancient external files.
- Removed the scriptWrite arg.
The trialWrite, perfectImportFlag, scriptWrite and thinFile switches (in the write logic) were each major "huh?" producers.
Compatibility
Eliminating keyword args in the AtFile class has the potential to break scripts and plugins. Imo, the danger is small, because scripts are unlikely ever to have used the weird keyword args. Python will catch errors provided that you use the following style for all calls to AtFile methods:
at.aMethod(
required_arg1,
required_arg2,
keyword_arg1 = aValue,
keyword_arg2 = aValue,
)
This style ensures that referencing a non-existent keyword arg will generate a Python error. Leo's core uses this style for all calls to AtFile methods.
Summary
For the first time in a long, long time the AtFile class contains no "huh?"s.
The new clarity in the code is the foundation for @auto work. That work is nearly complete.
I'll merge the js branch into master in a day or three. Imo, the present code is safe to use.
Edward
The js branch contains the new code. I created this branch to fix bugs in the javascript importer, but the changes needed quickly resulted in the massive housekeeping I am about to describe. This housekeeping was greatly aided by the new "hasattr" pattern.
tl;dr: Many switches in methods of the AtFile class were confusing or unnecessary. The new code is now as simple as I can make it. Afaik, there are no more "huh?"s left.
The hasattr pattern
The new pattern, described here, allows direct communication between code that wants to set a flag and code that uses the flag. Intervening methods have no knowledge of the communication. In particular, there is no need to pass the flag around. This pattern has been a spectacular success in the two or three places it is used.
The new hasattr pattern seems like the reverse of exception handling. Exceptions pass data up the calling tree. The new pattern passes data down the calling tree.
What I did
- Removed trialWrite from all methods except at.writeOneAtAutoNode.
Only linescanner.Importer.trial_write sets this flag, so it's fairly clear from context what is going on.
- Removed perfectImportFlag.
- Replaced forceSentinels by hasattr(at, 'force_sentinels').
- Replaced partialFlag by force.
- Removed all thinFile code from the AtFile write logic.
thinFile still exists in Leo's read logic, so that Leo can read ancient external files.
- Removed the scriptWrite arg.
The trialWrite, perfectImportFlag, scriptWrite and thinFile switches (in the write logic) were each major "huh?" producers.
Compatibility
Eliminating keyword args in the AtFile class has the potential to break scripts and plugins. Imo, the danger is small, because scripts are unlikely ever to have used the weird keyword args. Python will catch errors provided that you use the following style for all calls to AtFile methods:
at.aMethod(
required_arg1,
required_arg2,
keyword_arg1 = aValue,
keyword_arg2 = aValue,
)
This style ensures that referencing a non-existent keyword arg will generate a Python error. Leo's core uses this style for all calls to AtFile methods.
Summary
For the first time in a long, long time the AtFile class contains no "huh?"s.
The new clarity in the code is the foundation for @auto work. That work is nearly complete.
I'll merge the js branch into master in a day or three. Imo, the present code is safe to use.
Edward
Edward K. Ream
Apr 10, 2017, 5:04:38 PM4/10/17
to leo-editor
tl;dr: Many switches in methods of the AtFile class were confusing or unnecessary. The new code is now as simple as I can make it. Afaik, there are no more "huh?"s left.
To repeat something I've said several times recently, this work required all the major tools available to me:
clone-find commands, git, pylint and pyflakes:
- git makes everything safe.
- pyflakes catches almost errors immediately.
- pylint catches more subtle errors that sometimes escape unit tests.
- Leo's clone-find commands revealed global patterns quickly.
I would not have attempted this work without git and the clone-find commands. The latter allow me to answer complex questions about code quickly. I can then reorganize the searches for even greater clarity.
I'm hoping to convince Terry and Kent at our upcoming meeting that the clone-find commands are worth using.
Edward
Kent Tenney
Apr 11, 2017, 11:27:21 AM4/11/17
to leo-editor
Looking forward to it!
--
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 leo-editor+unsubscribe@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages