[Numpy-discussion] Python needs goto

[Christophe Bal]

By pseudo example, I mean pseudo code.
Le 24 sept. 2015 20:56, "Christophe Bal" <projetmbc at gmail.com> a écrit :

> 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/cbe75826/attachment.html>