[Numpy-discussion] Python needs goto

[Christophe Bal]

To be honest, I am not very conviced. Does someone can give a pseudo
example ?
Le 24 sept. 2015 20:50, "Benjamin Root" <ben.v.root at gmail.com> a écrit :

> Most of the time when I wanted to use goto in my early days, I found that
> breaks and continues were better and easier to understand. I will admit
> that there are occasional nested if/elif/else code that get messy without a
> goto. But which smells worse? A "goto" package or a complex if/elif/else?
>
> Ben Root
>
> On Thu, Sep 24, 2015 at 2:41 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>>
>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak <yarkot1 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
>>> alex.eberspaecher at gmail.com> wrote:
>>>
>>>> On 24.09.2015 13:25, Christophe Bal wrote:
>>>>
>>>> > Can you give an example where GOTO is useful ?
>>>>
>>>> I think those pieces of code are best understood with some humour..
>>>>
>>>> However, basically I can think two main causes for using goto:
>>>>
>>>> 1. Stop whatever your code is doing and jump towards the end of the
>>>> program. However, this is mainly something useful for languages without
>>>> exception handling and garbage collection.
>>>>
>>>> 2. Get out of something deeply nested. Also, this probably isn't very
>>>> useful in Python as there's exception handling.
>>>>
>>>
>>> I think there are more valid uses - I've read that "goto" basically is
>>> what a state machine does.
>>> Have a read of the brief implementation notes for "goto" in golang, for
>>> example.  Goto may not be unreasonable to use, just most people would
>>> abuse.  Sort of like "everyone shouldn't write assembly, but if you
>>> understand the machine, you can make good things happen".  Without
>>> compiler/interpreter checks, more responsibility rests on the coder to keep
>>> out of trouble.
>>>
>>
>> I would agree about state machines. When implemented using the standard
>> control flow constructs they always look a bit artificial.
>>
>> Chuck
>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150924/ceac14f7/attachment.html>