"Goto" statement in Python

[bartc]

On 14/04/2017 02:44, Steve D'Aprano wrote:
> On Fri, 14 Apr 2017 12:52 am, bartc wrote:
>
>> I know this isn't the Python need-for-speed thread, but this is a
>> classic example where the lack of one simple feature leads to using
>> slower, more cumbersome ones.
>
> Dear gods, have I fallen back in time to 1975 again?
>
> The Goto Wars are over, and the structured programming camp won the war
> decisively.
>
> Are functions/procedures *technically* slower than GOTOs? Yes. So what?
> You're nano-optimizing the wrong thing: you're saving a microsecond of
> runtime at the cost of a megasecond of development and maintenance time.

Usually, yes. (And when you run CPython, whatever speed you do get, is 
partly thanks to compiler writers choosing jumps, or in-lining, over 
function calls. All those nanoseconds add up.)

However my comment wasn't specifically about goto. It's about using a 
slower feature to get around the lack of another feature that could have 
been implemented efficiently.

>> Function calls, returns and generators are rather more heavyweight in
>> comparison.
>
> And enormously better.

It depends if your application is speed-sensitive. Much scripting code 
isn't, or if it is, most of the work is done outside the language.

But sometimes you want your dynamic code to do some actual work of its 
own that involves executing byte-code, rather than calling some compiled 
code. And performance can matter.

-- 
bartc