goto is pretty important and it was a primary keyword in early languages
in many contexts goto is needed and without it python programmers either resort to clunky while true hacks or memory-shifting hacky external libs that crash the cpython virtual machine
in cpython bytecode there is: jump_absolute [addr] pop_jump_if_true
now i just want these tools to be surfaced into python
i know the dogma that goto is bad but that’s not a reason if you have a rejetcion please supply a real reason
2: screen clearing
in python people usually need os.system('cls' if os.name == 'nt' else 'clear') or std.stdout.write("\033[2J\033[H");std.stdout.flush() just to clear the screen.
why not add a cls()/clear()/wipe() builtin to do that for us? because the other ways are hard to process mentally (maybe to shutil if it doesnt deserve the global namespace)
now i know python is crossplatform so i think shutil.cls() can handle all the tty and posix stuff internally and maybe even handle terminal-less environments and do nothing (maybe with isatty())
now to be clear i’m not demanding the exact syntax this is just ideas with potential syntax
In order to convince people that it’s worth adding to the language, we kinda do, yeah. Simply “this would have been convenient once in my life” isn’t enough to justify having another feature in the language that everyone has to learn about.
it isn’t just once every person at some point finds themselves needing goto i came back from x86-16 so goto is how i natively speak and maybe each one of us needs goto sometime
I am first and foremost a C/C++ programmer so I can understand the reason why gotos are useful. However, they are both useful and evil.
wonderful: it’s very much easier to use gotos for merged cleanups so as to avoid extra functions, or break/continue and other changes. It’s always possible to rewrite code without a goto but sometimes a goto is simply easier (for instance breaking out of nested loops without returning directly).
evil: it’s evil because it breaks the reading flow; Python favors readability and simplicity and usually rejects complex language features. Depending on languages, the notion of goto is different as well. For instance in C, goto is much less permissive than goto in C++ since the latter doesn’t allow entering some variable scopes that C would otherwise allow (essentially because of non-trivial default constructors). Should Python behave like C, this may add a language complication for scopes in general.
When I say goto is wonderful is really a matter of taste. It has nothing to do with functionalities or even performance. Unless I am missing something, it’s always possible to transform goto-based code into equivalent one with some additional cheap variables and checks:
for x in xs:
for y in ys:
if cond(x, y):
goto end
end:
...
can be rewritten with similar performance and readability as
ok = False
for x in xs:
for y in ys:
if cond(x, y):
ok = True
break
if ok: break
if ok: ...
This only adds a single if at every iteration which is usually not costly compared to the rest of the loop. I personally find this a bit annoying but not impossible but being expressive is Python’s essence. Breaking that is like breaking what the language was meant for in the first place.
memory-shifting hacky external libs that crash the cpython virtual machine
That’s a strong statement that needs clarification and proof. I don’t understand why there is no in-between. Without a clear example of why a goto is the only answer to dramatically improve performance, this suggestion is likely to be rejected.
i know the dogma that goto is bad but that’s not a reason if you have a rejetcion please supply a real reason
Sorry but this is a reason. The same argument can be used for you to provide a real reason for why you need a goto.
About screen clearing
This is not something meant in the stdlib. It should rather be in a 3rd party library. Terminal capabilities etc are hard to detect and the behavior of CSI 2J differs per terminal. The stdlib doesn’t want all 3-liners (if it were simply os.system(...)). I would rather have various handling ofr ANSI escape codes in a separate package (such as ansi).
It’s worth noting that using a different language’s idioms is usually NOT the most productive way to work. When I’m writing Python code, I will use Python’s idioms, since they work well with the language. Pike is slightly different, so I’ll do things slightly differently. C is very different, so I’ll use a completely different way of working. [1] For example, the goto statement in C and C++ is very frequently used for resource cleanup after errors, but you simply don’t need that in Python.
Ultimately, we don’t have to convince you that goto is useless; you have to convince us (or, more specifically, you have to convince the core devs) that goto is worth adding. Something that’s only of marginal value isn’t going to be added; there has to be a strong reason for adding it.
And then there’s C#, where some of the rules just leave me wondering what is even meant to be idiomatic. But that’s beside the point. ↩︎
i don’t even really want to force anything to be added i just stated my opinion and they can just straight up kick it outta the window
also i had the point of shutil.cls and everyone is debating goto
I would rather not have to read sources containing goto’s, structured programming thought of what they were used for that was maintainable and introduced while/for/do loops and removed goto. I have not missed it.
A multi-break, or label + breakTo / breakOutis indeed something I occasionally miss, but most of the time I end up using a function with return instead, and in 1% of cases the well known try-raise-except idiom with a custom exception.
Actually, the 'better readability" here is very subjective.
It is hard to argue that being able to break multiple loops at once might not be useful - still, I dislike the idea of a `goto`.
But maybe being able to put an ordinal after `break` to spell out how many levels it would break, could add to the language. `break 0` could be sinonimous with `continue` (if allowed at all), and the no argument break be the equivalent to `break 1`.
About `clear`: it just works on the REPL right now. - jsut type it.
If you are writting something programatic for the terminal, it is either a flow forward" “CLI” that just streams new content to stdout/stderr: `clear` is not really expected, or you are doing a full fledged TUI , in which case the TUI framework you are using already will provide a way to clear the screen.
If you want anything in between, the print ANSI codes you put as an example should be used. The thing is that, actually, the case for that might be common enough.
On the things to thonk about. if we woild be bringing ‘clear’ - why to draw the line there and not bring in more TUI-framework things in? And then, were to draw the line of what’d be included? (Note that Python already has a TUI framework builtin the stdlib, but it ends up being complicated enough no one uses it: `curses`)
Yep - I came here to argue against a “clear” - but after stating the above: no, there is a niche for it, indeed. Maybe it could go as a `print` kwarg, instead, so no need for a “tui module” just to house it?
Or - more likely, bring `_colorize` out of the shadows (the module used internally for things using colors in the terminal since 3.13), and fatten it up with some light-weight TUI primitives, including “clear”?
When I say goto is wonderful is really a matter of taste
But maybe being able to put an ordinal after `break` to spell out how many levels it would break, could add to the language. `break 0` could be sinonimous with `continue` (if allowed at all), and the no argument break be the equivalent to `break 1`.
PARI/GP is the only language I know providing this feature but it suffers the same issues as goto, namely breaking the reading flow. For break 2 with loops with their for not too far from each other, it’s ok. But once you have 3 loops and each for is far from each other, I find myself using the “create a boolean for early exit” for clarity.
Having a level of break makes refactoring harder as well (and I’m not buying the “use an LLM” argument: not everyone is able to use them, or even endorse them). If you add a single loop, you need to increment the level of each nested break by 1 if the latter were meant to jump outside the outer loop (in this case, I would rather prefer a goto where the jump is “absolute”).
It is definitely supported by the shell programming language too (POSIX
shell, not just bash).
POSIX issue 8 even includes this startling gem in the footnotes:
In early proposals, consideration was given to expanding the syntax of
/break/
<https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#break>
and /continue/
<https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#continue>
to refer to a label associated with the appropriate loop as a preferable
alternative to the /n/ method. However, this volume of POSIX.1-2024 does
reserve the name space of command names ending with a <colon>. It is
anticipated that a future implementation could take advantage of this
and provide something like:
outofloop: for i in a b c d e do for j in 0 1 2 3 4 5 6 7 8 9 do if test
-r "${i}${j}" then break outofloop fi done done
and that this might be standardized after implementation experience is
achieved.
c2y has accepted N3355 (citing rust / java inspiration), which means
labeled breaks will exist in c2y as well. Perhaps POSIX issue 9 will
bring them to the shell.
Labeled breaks solve the problem of needing to increment nested breaks
when refactoring code, at least.
On a general note, there are some valid use cases of goto, but typically we already have better language constructs (exceptions for error handling, context managers for state cleanup, …). Breaking out of multiple loops is possibly the most prominent example of a goto use case that does not have language support. If we feel a need to break out of multiple loops, and patterns like “encapsulate in function and use return” are not enough, we should rather introduce something like labeled breaks and not a general goto.