A recent tweet misquoted me. In the "Why I Like Python <http://leoeditor.com/appendices.html#safety>" Chapter I discussed why python is fundamentally safer than C. It's not (usually) possible to make memory allocation errors in python, whereas in C one must be constantly on guard.
Alas, this does *not* mean that it is impossible to make serious errors in python! In Leo, the most serious errors would cause users to lose data *silently* when they saved a file. Yes, people can delete data from a .leo by accident, but that's not what I mean. The worst bugs would delete data without the user's knowledge. This has happened in the past. We don't want it ever to happen in future. The rest of this post discusses where the danger areas are in Leo. It will be of interest primarily to Leo's maintainers. Feel free to ignore. But please, I have *never* said that bad bugs are impossible in python. Only one class of bad bugs is impossible in python. *LeoTree.select* The easiest way to destroy Leo would be to mess up the node-switching logic in LeoTree.select and helpers. This logic handles the surprisingly complex and dangerous process of switching from one node to another. I won't go into details, but any errors can cause data in the body pane to revert to their previous contents, which horrendous consequences. Afaik, there is no way to simplify this logic. Among other things, it must switch what c.p means at *precisely* the correct moment so that redraws happen properly. c.endEditing is part of this logic, and is much trickier than one might assume. LeoBody.onBodyChanged is also critical and tricky code. *Leo's Qt event handling* It took months to get Leo's Qt tree-handling code to be rock solid. Mistakes caused Leo to hard crash within PyQt, which is a thin wrapper around C code. Pass a bad C reference to Qt--die hard. There is a serious, unavoidable, additional complication. Unlike most outliners, Leo scripts can cause changes to the outline. This means there are two, fundamentally different, paths through the tree handling code. The first arises from user mouse clicks in the outline. The second arises from user scripts, including built-in scripts. This second path can cause Qt events that *must be suppressed*. Failure to do so will cause unbounded recursions or other catastrophic failures. And one more thing about the Qt code. Ending editing of a headline destroys the underlying QLineEdit widget. Leo's code must take great pains to handle this fact. Failures result in references to unallocated C memory. Again, Leo dies hard. *Summary* The worst bugs in Leo's history caused people to lose data when switching nodes. Developing a new gui for Leo will always be challenging because scripts can cause unwanted outline events that must be suppressed. The curses gui may be an exception, or not. Memory allocation bugs are not (usually) possible with python, but they can arise by passing bad references to C libraries. Yes, python is fundamentally safer than C, but arbitrarily bad bugs *are* possible. Happily, bad bugs can arise only in a few critical areas in Leo. Edward -- 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
