On Sun, Dec 27, 2020 at 1:25 PM Steven D'Aprano firstname.lastname@example.org wrote:
But the ctrl-L trick has no discoverability. It took me close to twenty years of using Linux before I discovered it, and I still don't remember to use it when I need it.
Beginners and casual users aren't going to know ctrl-L, or stumble across it through experimentation. People like me aren't going to remember to use it. For interactive use, os.clear is barely any better.
(Me, I'll be looking in shutils, not os, because this is a shell feature, not an os feature.)
True. Plus, despite my misgivings about how it'd be misused, this IS a useful feature to have within a program, and making a program press Ctrl-L isn't reliable.
So I think the reason to have it in the std lib is for scripting, and I think putting it in os or sys is just fine.
Putting it in sys requires it to be built into the interpreter, which means it has to be written in C (for CPython). Putting it in os is fine, that can easily delegate to platform specific code in posix.py, nt.py etc, with a pure-Python lowest common denominator fallback for weird platforms that don't support anything sensible.
os or shutil would be fine with me, and I know for sure that a lot of people will look in the wrong one. My inclination would be for os, since shutil is described as "high level FILE operations", and is mainly focused on file system rather than console. But that's bikeshedding.
I just want site.py to import it at startup for the sake of beginners. Is that so bad? It adds one line to site.py, four if you want to make it conditional:
try: from os import clear except: pass
I can easily add it to my own personal PYTHONSTARTUP file, but the average beginner can't. Let's throw newbies a bone and pre-import it for them, they're the ones who seem to expect it the most.
This is actually the exact part that I think should *not* happen, for several reasons:
1) Stuff that exists interactively and doesn't exist in a script is a barrier to that migration. I don't think this feature justifies that barrier. 2) The builtins are already incredibly busy, and this, again, doesn't justify being one 3) Beginners already have to learn about importing (eg "from math import sin") and this is just one more importable.
So that's the easy part: just agree with me and import it in site.py, wherever it happens to come from. *wink*
This is python-ideas! We don't "just agree" here, we argue! Even if we don't have to!
The hard part is deciding exactly what it should do, e.g. clear the scrollback or not. I think Chris makes a good point that real beginners will misuse this to hide the evidence whenever they get an error, so I think the default should be to *not* clear the scrollback, for the sake of educators, teachers and trainers. People who know what the scrollback is and definitely want to clear it can just provide an extra argument to the function.
So let's just all agree I'm right *wink* and move on to the *really* hard part, which is ensuring it works on Windows and weird terminals.
Okay, so I think there are a few things we can agree on.
* Having a function to clear the screen can be abused, but is still worth having * It shouldn't be based on os.system, which top SO results are advocating. * It should work on all OSes, consoles, etc, if possible * It doesn't have to work in a GUI; Idle can monkeypatch it
My personal shed colour preferences:
* os module, not sys, not shutil, not builtin * clearscreen(), not cls(), although I'd accept clear() * Suppressing scrollback is a downside, but better than not having the feature at all * Beginners should NOT be encouraged to use this too much
The last one is hard to define, but I'm generally disinclined towards any proposal that makes it too easy for a beginner to clear the screen all the time. Life is SO much easier as an educator if you can do post-mortem analysis, not just of the one most recent action, but of all previous ones. Even among more advanced students, I see far too many cases where they try to "tidy up" (by clearing the screen, or closing the terminal and opening a new one, or whatever), and in doing so, throw away valuable error messages or indicative commands (like if someone wrote "os = 'Linux'" and then broke all os.x() calls).