And while your're at it, I suggest taking the Bayesian approach for the criterion of a scientific method, where falsification is a particular (and simplified) case of Bayesian reasoning.
A great introduction may be found at [0], if one is already well versed in Bayes theorom, then an excerpt [1] should be enough.
I might be nitpicking, but I disagree with Raymond Chen here.
Regarding his example, IMO, the process of saving a file has a platonic security abstraction, it is a very limited computation engine. When one is able to escape this abstraction, it is a security concern.
The distinction between a security bug and non security bug is very subtle.
An example how this violation may happen in real life. Assume a filesystem that may contain long filenames, an attacker may control it and cause remote execution. Another scenario may be a site that tells you to see an easter egg in notepad by fire up notepad and save a file named <payload>, which will do some trick and will also run arbitrary code on your machine.
Talking about tabs, I am really curious why links which get opened in new tabs don't feature a working back button. It really bothers me when reading an article that contains a lot of references, I open them, each one on a new tab, read through each one of them and then can't get back to the old one (I usually resort for Ctrl+Shift+T too many times).
I believe that a similar approach can also be used in C++ with the help of ADL [1] and some template magic. Though it may only work on expressions whose concrete type may be known at compile-time (which makes it pretty useless).
This repository previously included a toolchain to build a collection of eBooks, in ePub and MOBI formats, from Caltech's online edition of the Feynman Lectures. Those scripts have since been removed, in response to the suggestion that their continued availability might lead to a permanent discontinuation of HTML access.
Not only it is not very intuitive, I also find it to hurt the linearity of code. The code which will be executed after the loop ends depends on how the loop ended. break statement is usually a glorified but mostly harmless go to, but I think Python's go to statement isn't so harmless as it adds complexity but doesn't have big benefits.
But, I do think that the else clause on try\except blocks is less harmful. It is less harmful because the control flow complexity of exceptions handling is already there on the catch clause, so while exceptions does add big control flow changes, the addition of the else clause causes a relative minor change on the linearity of code (as it is already broken by catch: clause.)
A great introduction may be found at [0], if one is already well versed in Bayes theorom, then an excerpt [1] should be enough.
[0]: http://www.yudkowsky.net/rational/bayes
[1]: http://www.soest.hawaii.edu/oceanography/researchers/francoi...