I've heard the claim that interpreted languages simply have a whole different set of bugs than compiled languages.
I think about 95% of the bugs I encounter in Python at runtime are due to incompatible types due to an "inappropriate" type/value being passed to a function. Sometimes it's simply the wrong variable and sometimes the right variable has been passed but needs to be converted to str/int/etc or exist inside a list. I find this class of bugs is usually not detectable with static file checkers like pylint/pyflakes/flake8. I'm annoyed by them but they are almost always obvious from the stack trace. I've also heard the claim that static type checking eliminates this class of bugs. I would agree that static type checking can *limit* this class of bugs but I also find that it presents a false sense of security about passing appropriate values and lulls me into writing weaker tests. Type checking *can* be a *part* of a robust test but should rarely be the only test. I infinitely prefer this class of bugs over memory management issues. That said, if one is following best practices and robust tests are being written then this class of bugs nearly disappears, which explains why I encounter them so often ;) On Friday, December 16, 2016 at 4:49:04 AM UTC-5, Edward K. Ream wrote: > > 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
