These are old-school-bad gotos: `if` statements would do the job more clearly. Is this a broken-window phenomenon: one planted `goto` opens the door for the rest? Or is there a deeper motivation for this style?
To be clear, these are not the "classically bad" go-to that Dijkstra &al. railed against. C's goto is restricted to local jumps. You'll rarely see a go-to used in the classically bad style these days outside of something like a hand-written assembly interpreter main loop.
As for why you'd want to write a goto where an if would be semantically equivalent, there's a mix of style and human-level semantics: gotos are for "exceptional" cases, so the "normal" case looks flat and falls though directly to unconditional code, keeping the main logic flow at a consistent indentation level. (And apparently this heuristic is also baked into simple branch predictors, though I doubt that's something that comes up nearly as much.)
This feels less like 'folly of dogma' and more like these (C/C#) programming languages don't have the constructs to safely and properly express what the programmer is trying to do. 'goto exit' is an unsafe and dangerous version of Rust's '?' operator.
> We should be willing to break generic rules when the circumstances call for it. Keep it simple.
I argue we should instead iterate on the programming language design to make sure we don't need to make these kinds of trade-offs.
C++ has solid "cleanup" constructs so I wonder why CPython is in C instead of C++. Is it portability, compilation speed, complexity control, transition cost, something else...
All of those, but also python came out in 1991 when C++ was still in its infancy. Even if C++ had been mature though C is still a better choice, python is often embedded in other programs and doing that with C has a lot fewer headaches (simpler linking, better compiler support)
CPython is a relatively simple program calling for a (relatively) simple language. It's meant to be understood by lots of people, used within many different contexts and C is in much better position here.
At its heart it is just a bytecode interpreter, i.e. a loop with a huge switch. I don't think you need an elephant language just for that.
It's the problem of worse programmers seeing something used, and then misusing it because they don't understand the fundamental reasoning that led to its use in the first place.
Graceful error exiting is to this day an unsolved problem in computer science (at least as far as the popular languages are concerned). Even after GOTO elimination hit its stride, Knuth noted:
"Another important class of go to statements is an error exit. Such checks on the validity of data are very important, especially in software, and it seems to be the one class of go to's that still is considered ugly but necessary by today's leading reformers. Sometimes it is necessary to exit from several levels of control, cutting across code that may even have been written by other programmers; and the most graceful way to do this is a direct approach with a go to or its equivalent. Then the intermediate levels of the program can be written under the assumption that nothing will go wrong."
https://github.com/python/cpython/search?q=goto
There's a lot of "goto exit" which is obviously a CPython runtime convention - fair enough. However there's plenty of classically bad code, example:
https://gist.github.com/ridiculousfish/ffe4fa2a17c831ed06e57...
These are old-school-bad gotos: `if` statements would do the job more clearly. Is this a broken-window phenomenon: one planted `goto` opens the door for the rest? Or is there a deeper motivation for this style?