Goto (Posting On Python-List Prohibited)

bartc bc at freeuk.com
Sun Dec 31 18:21:05 EST 2017


On 31/12/2017 22:09, Ben Bacarisse wrote:

> No, you missed the point and did not address the question.  You said (now
> cut)
> 
> | If I thought introducing functions, whether local or not, as a way of
> | avoiding goto was worth doing, I would do so.
> 
> but I'm not sure you know if it's worth it or not.  So here's my
> question again: what language (or languages) were you using when you
> concluded that it was not worth using local functions to avoid gotos?
> Maybe you had a bad experience from some language that did it badly.

What makes you think I had a bad experience? I posted a version using 
Python a few hours ago (which needs the local function to be moved to 
work properly).

The same example works in my language (one of them anyway), but I still 
find a quick goto the simplest thing to do especially when the code is 
not complete so I don't know what will be added or changed or moved, 
which will be harder as soon a specific sequence is extracted into a 
function.

Also, what would be the duplicated code is seen to 'belong' to one of 
the options, rather than be anonymous.

(Here is the same example in my static language: 
https://pastebin.com/raw/dX2FNK7a

fn1 uses goto. fn2 uses a local function (not very demanding here so it 
works). fn3 uses the special 'block-call' feature which I no longer use 
(but I haven't yet got rid of it).

I prefer fn1 and fn3 because the code stays inline. If I had some 
inspiration for a better feature then I'd have fn4 and maybe fn5 too.)

Within Python, I touched on performance issues in my earlier post. (A 
local function apparently involves an extra assignment - per function - 
each time the containing function is called.)

>> (Which is likely to cause problems if the code includes breaks, or
>> gotos if the language has them.)
> 
> Good grief!  That is exactly the sort of code you should not re-use by
> jumping to it.  There are myriad potential problems and putting the code
> into a function will allow the compiler to diagnose lots of them.

OK, forget the gotos then. But a block can still contain break or return 
(and in my syntax, several other loop controls). It loses context as 
soon as it's hoisted into a function.

-- 
bartc



More information about the Python-list mailing list