# My ideas for Python 3.16 (goto and clear terminal) **URL:** \ **Category:** Ideas\ **Created:** [September 7, 2026, 7:18am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917 "2026-09-07T07:18:36Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![nour314](https://avatars.discourse-cdn.com/v4/letter/n/9f8e36/32.png) [@nour314](https://discuss.python.org/u/nour314)\ **Post date:** [September 7, 2026, 7:18am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/1 "2026-09-07T07:18:36Z")
so, i have some ideas for py 3.16 1: goto / gotoif / label 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 ---
**Author:** ![jacopoabramo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jacopoabramo/32/23840_2.png) [@jacopoabramo](https://discuss.python.org/u/jacopoabramo)\ **Post date:** [September 7, 2026, 7:28am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/2 "2026-09-07T07:28:56Z")
> [@nour314](#): > > now i just want these tools to be surfaced into python It would help your case explaining _why_ you would need this. What are you trying to express in python that requires `goto`? ---
**Author:** ![nour314](https://avatars.discourse-cdn.com/v4/letter/n/9f8e36/32.png) [@nour314](https://discuss.python.org/u/nour314)\ **Post date:** [September 7, 2026, 7:30am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/3 "2026-09-07T07:30:11Z")
i don’t remember the specific thing but i remember i once needed a goto statement in a little python terminal i made (sorry if you expected a solid reason) ---
**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\ **Post date:** [September 7, 2026, 7:36am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/4 "2026-09-07T07:36:19Z")
> [@nour314](#): > > (sorry if you expected a solid reason) 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. ---
**Author:** ![nour314](https://avatars.discourse-cdn.com/v4/letter/n/9f8e36/32.png) [@nour314](https://discuss.python.org/u/nour314)\ **Post date:** [September 7, 2026, 8:26am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/5 "2026-09-07T08:26:35Z")
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 ---
**Author:** ![picnixz](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/picnixz/32/12660_2.png) [@picnixz](https://discuss.python.org/u/picnixz)\ **Post date:** [September 7, 2026, 8:46am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/6 "2026-09-07T08:46:40Z")
### About `goto` I am first and foremost a C/C++ programmer so I can understand the reason why `goto`s 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: ```py for x in xs: for y in ys: if cond(x, y): goto end end: ... ``` can be rewritten with similar performance _and_ readability as ```py 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](https://pypi.org/project/ansi/)). ---
**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\ **Post date:** [September 7, 2026, 8:53am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/7 "2026-09-07T08:53:23Z")
> [@nour314](#): > > so goto is how i natively speak 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. * * * 1. 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. ---
**Author:** ![nour314](https://avatars.discourse-cdn.com/v4/letter/n/9f8e36/32.png) [@nour314](https://discuss.python.org/u/nour314)\ **Post date:** [September 7, 2026, 11:45am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/8 "2026-09-07T11:45:38Z")
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 ---
**Author:** ![nedbat](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nedbat/32/8744_2.png) [@nedbat](https://discuss.python.org/u/nedbat)\ **Post date:** [September 7, 2026, 11:47am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/9 "2026-09-07T11:47:35Z")
It’s generally best to start a new post for each idea. Suggesting two different things in one post is bound to make the discussion difficult. ---
**Author:** ![Paddy3118](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/paddy3118/32/1396_2.png) [@Paddy3118](https://discuss.python.org/u/Paddy3118)\ **Post date:** [September 7, 2026, 11:54am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/10 "2026-09-07T11:54:45Z")
> [@nour314](#): > > i know the dogma that goto is bad I think this is the original: > **[Letters to the editor: go to statement considered harmful | Communications of...](https://dl.acm.org/doi/10.1145/362929.362947)** 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. ---
**Author:** ![warden](https://avatars.discourse-cdn.com/v4/letter/w/13edae/32.png) [@warden](https://discuss.python.org/u/warden)\ **Post date:** [September 7, 2026, 1:51pm UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/11 "2026-09-07T13:51:05Z")
A multi-`break`, or label + `breakTo` / `breakOut`is 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. ---
**Author:** ![da-woods](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/da-woods/32/7507_2.png) [@da-woods](https://discuss.python.org/u/da-woods)\ **Post date:** [September 7, 2026, 2:43pm UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/12 "2026-09-07T14:43:27Z")
There’s a few libraries that use hacky byte code tricks (and maybe some other tricks) to implement `goto` in Python: - [GitHub - cdjc/goto · GitHub](https://github.com/cdjc/goto) - [GitHub - alimsk/goto-python: goto statement for python · GitHub](https://github.com/alimsk/goto-python) - [GitHub - snoack/python-goto: Discontinued function decorator that rewrites Python bytecode to enable goto statements · GitHub](https://github.com/snoack/python-goto/) (Unfortunately they don’t all look hugely well maintained). Just something to play around with while we wait for Python 3.16. ---
**Author:** ![jsbueno](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jsbueno/32/1210_2.png) [@jsbueno](https://discuss.python.org/u/jsbueno)\ **Post date:** [September 7, 2026, 4:54pm UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/13 "2026-09-07T16:54:50Z")
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`. Personally, I’ve missed that sometimes. ---
**Author:** ![jsbueno](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jsbueno/32/1210_2.png) [@jsbueno](https://discuss.python.org/u/jsbueno)\ **Post date:** [September 7, 2026, 5:13pm UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/14 "2026-09-07T17:13:26Z")
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”? ---
**Author:** ![picnixz](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/picnixz/32/12660_2.png) [@picnixz](https://discuss.python.org/u/picnixz)\ **Post date:** [September 7, 2026, 5:13pm UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/15 "2026-09-07T17:13:47Z")
> [@jsbueno](#): > > Actually, the 'better readability" here is very subjective. I may not have been clear enough but I did say: > 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”). ---
**Author:** ![eschwartz](https://avatars.discourse-cdn.com/v4/letter/e/a9a28c/32.png) [@eschwartz](https://discuss.python.org/u/eschwartz)\ **Post date:** [September 7, 2026, 10:52pm UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/16 "2026-09-07T22:52:01Z")
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: ```python In early proposals, consideration was given to expanding the syntax of /break/ and /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 . 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. ---
**Author:** ![timhoffm](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/timhoffm/32/19468_2.png) [@timhoffm](https://discuss.python.org/u/timhoffm)\ **Post date:** [September 8, 2026, 5:39am UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/18 "2026-09-08T05:39:47Z")
Multi-level breaks have been discussed before: [Breaking/continuing out of multiple loops](https://discuss.python.org/t/breaking-continuing-out-of-multiple-loops/18354) 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. ---
**Author:** ![davidism](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidism/32/3295_2.png) [@davidism](https://discuss.python.org/u/davidism)\ **Post date:** [September 8, 2026, 1:13pm UTC](https://discuss.python.org/t/my-ideas-for-python-3-16-goto-and-clear-terminal/108917/19 "2026-09-08T13:13:43Z")
This has been rehashed enough.