On 14 April 2017 at 03:44, Steve D'Aprano <steve+pyt...@pearwood.info> 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?
>
Everything new is definitely better, right?
> Are there reasonable uses for GOTO? Perhaps. There are semi-structured
> restricted versions of GOTO, like exceptions, break and return, but an
> unrestricted GOTO where you can jump anywhere in the program is a terrible
> feature
Yes I suppose, but I know too little about who restricts or
allows and how. And in python it is allowed to mistype
for example "while True :" in any part of the
.py file, as well as one can accidentally mess up with
indentation.
But indeed, Python has very restricted syntax and it is very good.
> Even that's not enough for some. Donald Knuth, who supports the use of GOTO
> under some circumstances, maintains that any program using GOTOs should
> have the invariant that its flow chart can be drawn with all forward
> branches on the left, all backward branches on the right, and no branches
> crossing each other.
I am in the category "I just want to express some
algorithm and don't want to learn every year new concepts".
I tend to think that extremely restricted syntax, in the sence
of having only few flow control instructions actually helps with
readability, despite I have never seriously used other languages
than python so I cannot judge GOTO specifically.
But that comes to many other aspects, most of the time
I just want my code look consistent and readable
and this is more representational problem.
And I suppose that with Python, what bothers
me is zig-zags of indentation.
Now regardless of Python :
if I would have, say 2 forms of GOTO,
ie direct GOTO and e.g. 'loop' ,
an improvised pseudocode example:
"""
in_menu = true
SUB -------------------------
init some
draw thing
# if skip_scan : goto .x
loop
| K=readkey()
| if K[shift] :
| goto .1
| if K[m] :
| in_menu = false
| goto .1
| if K[o] :
| in_menu = false
|.1 make something
| make something
| if (in_menu = false) : goto .x
\__
.x
clean_up something
clean_up something
"""
or a classic:
x, y = 0
xx, yy = 300
loop
|loop
||
|| x = x + 1
|| if (x+y) > 100 : goto .x
|| if (x>xx) : goto .1
|\__
|
|.1
| y = y + 1
| if (x>xx) : goto .x
\__
.x
"""
So with 'else'-less condition statement, goto, and loop
construct I would have simpler representation simply because
I would have no 'else', for(), etc... And I'd avoid nested loops as much
as i can.
So less indentation zig-zags and plain "column" code look everywhere,
I think that is what many programmers are looking for.
Just from the reader's POV: having implicit labels for exiting loop
is IMO not worse than additional keywords e.g. "break"...
At least I would not be so fast to judge that.
It is just the question, *how would I input and edit such code*
to avoids typos and renaming labels.
[...]
>> (** Although I find code full of class definitions, one-liners, decorators
>> and all the other esoterics, incomprehensive. I'm sure I'm not the only
>> one, so perhaps readability isn't too much of a priority either.)
>Classes and decorators are not esoteric. You sound like an old man who
>complains about this new-fangled "telephone", and how things were so much
>better when we had messenger boys to deliver messages anywhere in the city.
Seriously, when I open some random .py file from the web
and everywhere see class, class, class, kilometers of indentation...
Hair around one-liners all over the files.
And hedgehogs of try: except blocks, well, this is
straining, and trying to learn why I need
some of those, multiplies the pain.
So your comment applies to me too and I must sound
like an old stupid man I suppose?
And I don't like new "telephones" - they are heavy, need charge
every 2 day, does not fit in the hand well, and just to repat
the last call I need to swipe the stupid touch screen.
Mikhail
--
https://mail.python.org/mailman/listinfo/python-list
