Suggestion: Clear screen command for the REPL
Hello, I would like to suggest adding a clear command (not function) to Python. It's simple purpose would be to clear the REPL screen, leaving the >>> prompt at the top left of the screen. This is something very basic but also very useful for newbies learning Python from the REPL. After some trial and errors it is best to start with a clean screen. Clearing the screen helps clear your mind. Historically it is a common command in interpreted languages. Best regards, JM
On Sat, Sep 17, 2016 at 8:51 PM, João Matos <jcrmatos@gmail.com> wrote:
I'm not sure that it _is_ helpful, given that you're starting with a clean screen but not restarting the session (so you'll still have all the state from your previous work). If you want a completely fresh start, just exit Python, clear the screen with a shell command, and re-enter. The easiest way to play around with this would be to create a pure Python clear() function in your usercustomize or sitecustomize, and then try it in your own workflow - see whether it annoys you that it doesn't change the interpreter state. Maybe it will, maybe it won't. ChrisA
Hello, In other interpreted programming languages the clear screen command (whatever it is) also does not clear the session. It just clears the screen clutter. As I said, this would be very useful for newbies, which don't know anything about usercustomize or sitecustomize. Best regards, JM On 17-09-2016 12:07, Chris Angelico wrote:
With IPython, there are a number of ways to reset the terminal display: clear # %clear !cls #windows !reset - http://stackoverflow.com/questions/6892191/clearing-the-screen-in-ipython - Ctrl-L is a readline binding - http://pythonhosted.org/pyreadline/usage.html#pyreadline-with-python-interpr... - https://anaconda.org/anaconda/pyreadline - https://pypi.python.org/pypi/pyreadline - IPython >= 5 no longer uses pyreadline (instead, python prompt toolkit) - https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/prompt... #def clear - http://unix.stackexchange.com/questions/124762/how-does-clear-command-work - http://urwid.org/reference/display_modules.html#urwid.raw_display.Screen.cle... - https://rosettacode.org/wiki/Terminal_control/Clear_the_screen#Python On Saturday, September 17, 2016, João Matos <jcrmatos@gmail.com> wrote:
Hello, I know about those IPython commands and I searched and found several possible solutions to clear the screen in the CPython REPL, but all are, in my opinion, complex for a newbie. The existence of a clear command would be simple and obvious, therefore accessible to newbies. Best regards, JM On 17-09-2016 14:15, Wes Turner wrote:
On Sat, Sep 17, 2016 at 1:15 PM, Wes Turner <wes.turner@gmail.com> wrote:
!cls #windows
cmd's built-in cls command doesn't clear just the screen, like a VT100 \x1b[1J. It clears the console's entire scrollback buffer. Unix `clear` may also work like that. With GNOME Terminal in Linux, `clear` leaves a single screen in the scrollback buffer.
Hi! On Sat, Sep 17, 2016 at 11:51:16AM +0100, Jo??o Matos <jcrmatos@gmail.com> wrote:
Hello,
I would like to suggest adding a clear command (not function) to Python.
Pressing [Ctrl]+[L] works for me.
Best regards, JM
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Sat, Sep 17, 2016 at 11:11 AM, João Matos <jcrmatos@gmail.com> wrote:
Windows 10 added VT100 support to the console, so you can create a little cls() function to clear the screen: cls = lambda: print('\x1b[1J', end='', flush=True) VT100 support isn't enabled by default. However, cmd.exe always enables this mode. So run doskey.exe via os.system to enable VT100 mode while setting a convenient "cls" alias: import os os.system(r'doskey /exename=python.exe cls=cls()') This alias substitutes "cls()" for "cls" at the beginning of a line. This saves you from having to type "()" all the time. The alias isn't active for other programs; e.g. if you execute subprocess.call('powershell'), then "cls" will be the PowerShell alias for Clear-Host. You can also use ctypes instead of os.system and doskey.exe: import ctypes kernel32 = ctypes.WinDLL('kernel32') hStdOut = kernel32.GetStdHandle(-11) # enable VT100 mode mode = (ctypes.c_uint * 1)() kernel32.GetConsoleMode(hStdOut, mode) kernel32.SetConsoleMode(hStdOut, mode[0] | 4) # define a cls() function and set a console alias cls = lambda: print('\x1b[1J', end='', flush=True) kernel32.AddConsoleAliasW('cls', 'cls()', 'python.exe') For older versions of Windows you can use ANSICON or ConEmu, which use DLL injection to extend the console API. Python's colorama and pyreadline modules should also work for this.
Hello, I searched and found several possible solutions to clear the screen in the CPython REPL, but all are, in my opinion, complex for a newbie. The existence of a clear command would be a simple and obvious, therefore accessible to newbies. Best regards, JM On 17-09-2016 14:34, eryk sun wrote:
On 9/17/2016 6:51 AM, João Matos wrote:
Python is not an 'interpreted' language in the sense that you are using the word. It is a compiled language that includes its compile function as part of the runtime. This enables an interactive mode. Python does not have commands, only statements, expressions, and functions, etcetera. This is why the 'exit()' and 'quit()' 'commands' are functions and require the parentheses. In interactive mode, a statement consisting of a single indentifier (or expression) causes display of a representation of the resulting object. You could request that the site module also add a clear() function. But the next problem is that clearing the screen is not a Python function and the Python runtime does not normally know how to do so. The implementation of 'clear screen' is specific to the particular console or window or terminal emulation. The control sequence for a window that emulates VT100 does not work on Windows Command Prompt (excepting possibly a non-default CP on Win 10) or necessarily IDLE or IPython or PyCharm or ... . The only assumption that Python makes about the screen it is running on is that '\n' is interpreted as a newline. IDLE has a 'Restart Shell' menu command with key binding. It does not physically clear the screen but it draws a double line, which serves most of the 'clear the mind' purpose. If there is an editor window open, one can close and reopen the Shell window to start really fresh. At least on Windows, Select All (^A) + Del (or Backspace) is the common idiom for clearing an editor box in a GUI. Is this used on other OSes? This works in an IDLE editor also. It is disabled in the Shell because IDLE's original designers thought to protect beginners from doing such. A clear screen menu option has been requested, but it has never become a top priority. In any case, this, like other current clear screen commands, would work because the command would go to the window manager and not to python. -- Terry Jan Reedy
On Sat, Sep 17, 2016 at 11:51:16AM +0100, João Matos wrote:
Hello,
I would like to suggest adding a clear command (not function) to Python.
While technically "clear" could be a command, I think it should not be. First off, making clear a reserved keyword, and a statement, like print in Python 2, raise or import, would be a major backwards compatibility break. It would mean dict.clear() has to be renamed, and it would break lots of existing code. So making clear a keyword is not going to happen. If could be a pseudo-built-in, like help(), quit() and exit(), added to built-ins by the site module. In that case, it is *technically* possible to have it operate without the parentheses: class ClearType: def __repr__(self): # code to clear the screen here ... clear = ClearType() so that when you enter clear at the interactive interpreter, __repr__ is called and it clears the screen. But I would argue against it. Instead, it is better to use the same convention that executable code that has side-effects should be implemented as a function call. So I suggest following the design of exit() and quit(): py> exit Use exit() or Ctrl-D (i.e. EOF) to exit class ClearType: def __repr__(self): return "Use clear() or Ctrl-L (i.e. FF) to clear the screen" def __call__(self): # clear screen code goes here clear = ClearType() # or possibly cls ? That is, *if* we add this function at all. Personally, I agree with you. There are many different ways of clearing the screen, but they depend on the specific terminal used, whether readline is active or not, the operating system, etc. I think that interactive use is important enough that we should have a standard way of clearing the screen. I personally often find myself just holding down the Enter key until I have a blank screen. In this ticket: http://bugs.python.org/issue27771 Raymond Hettinger mentions that it is an often-requested feature by learners, and I believe that IDLE has an active task for this feature: http://bugs.python.org/issue6143 but I don't see any tasks for a clear screen command for the default REPL. I'm in favour of adding a clear() *function* to the site.py module, similar to exit/quit/help, but not making it "magical" or a keyword that doesn't require brackets. But I don't know how to implement it for the large variety of terminals and operating systems supported by Python. (The fallback if all else fails is easy: get the height of the terminal, in lines, and print that many blank lines.) -- Steve
On Mon, Sep 19, 2016 at 12:32 PM, Steven D'Aprano <steve@pearwood.info> wrote:
(The fallback if all else fails is easy: get the height of the terminal, in lines, and print that many blank lines.)
Assuming you can get the height in lines. Have you tried that in the default Windows shell? I don't think tcgetattr works on Windows. ChrisA
Chris Angelico writes:
Since a command is out of the question (look what happened to print!), it's a matter of defining a callable with a repr that explains how to call it (like help and friends). So if someone really wants this to happen, I would say the thing to do is to define that callable, put it on PyPI, add support for all the platforms, fix all the bugs, and when there are a couple million downloads, suggest preloading it in interpreter then. Don't forget how to document how to add it to site.py. But I would think that nowadays we'd push in the opposite direction (as with print). That is, with the great improvements in IDLE (batteries included!), IPython, and now we have Jupyter, you could now argue that the built-in REPL should lose at least one of the two exit functions (since EOF is a sufficient reason to exit). (help() still makes sense as the public interface to __doc__.) In other words, the built-in REPL should just provide some line-editing features and otherwise simply read lines, incrementally compile and execute them, and print results. Leave UI conveniences to other applications that (gasp!) specialize in providing consistent, powerful UI that isn't going to feel like bat guano on Tim's keyboard. IMHO YMMV, of course.
On 19 September 2016 at 03:40, Chris Angelico <rosuav@gmail.com> wrote:
shutil.get_terminal_size() is available on all platforms. I don't think it would be unreasonable to add shutil.clear_terminal() (at the moment, get_terminal_size is the only "terminal handling" function in shutil, but it would be the obvious place to add others if we chose to do so). Paul
On Mon, Sep 19, 2016 at 6:31 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Sounds good to me. This is definitely sounding complicated and messy enough to justify (a) writing a function to clear the screen, and (b) testing that function thoroughly as a PyPI module before pushing anything into the stdlib. ChrisA
On Mon, Sep 19, 2016 at 06:38:00PM +1000, Chris Angelico wrote:
This isn't Node.js where standard operating procedure is to rely on the third-party npm ecosystem even for tiny, ten line functions. And we should be *glad* that's not the case: http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ People don't often install minor or small packages off PyPI as a matter of course: they either roll their own, or do without, depending on which is more painful, or whether they are even allowed to download third-party software (not everybody is), or whether managing the dependency is more or less work than writing their own. I get it that not everything belongs in the std lib, and I get it that for *some* people (but not all) its easy to rely on packages in PyPI. But there's quite considerable friction in getting *small* things off PyPI. For starters, you have to know it exists, you have to trust that its functional and well-written. There is a huge amount of junk, abandoned and "version 0.1" packages on PyPI that nobody in their right mind should use. Dependencies don't come for free, they add complexity and cost to a project. Not everything belongs as a package on PyPI either. If the cost of dealing with the added dependency is greater than the benefit gained, people won't use third-party packages on PyPI. For small but useful functionality, saying "Put it on PyPI" is effectively just a dismissal. For relatively small pieces of functionality, if it is useful enough, we should just add it to the std lib, and if it isn't, we should just say it isn't useful enough. We shouldn't condemn supporters of the idea to this false hope that if they can convince a thousand, or a million, people to download their package, it will be added to PyPI. -- Steve
On 19 September 2016 at 12:56, Steven D'Aprano <steve@pearwood.info> wrote:
"... to the stdlib". Agreed. However, there are libraries already on PyPI that try to act in the role of "useful bits that aren't in the stdlib". The boltons project is one that I know of. Maybe a middle ground between stdlib inclusion and outright rejection would be the suggestion to submit the code to one of those 3rd party projects? There's no implication that doing so means that there's any better chance of getting accepted for the stdlib, but it does offer an option for people who want to publish their idea for wider use. For this particular suggestion, though, I don't think that's the case. I think it's going to either be something that's accepted into the stdlib, or something that's rejected as too platform-specific or messy to standardise, and people should roll their own implementation. I'm inclined to think there may be some scope for a blog entry or HOWTO on customising your personal Python environment - what facilities there are to do so, what other options (such as different REPLs) are available, and how to judge whether it's worth doing or not. Lots of people (myself included at times!) seem to be unaware of the options available. It's not something I'm likely to ever write, but if anyone is interested in doing so, it might be useful background for this type of discussion. Paul
On 19 September 2016 at 13:10, Paul Moore <p.f.moore@gmail.com> wrote:
Note, by the way, that in the form of a Python function, this capability is already available in lots of places - colorama and click include it, for a start. And even the stdlib has a version in the curses module (albeit not available on Windows). In the light of this, there seems little reason to water down this proposal to "provide a clear screen function in the stdlib". Taken in its original form of "add a command to the REPL to clear the screen", the main issue is that the standard Python REPL simply doesn't have a concept of "REPL commands", so there's nowhere really to add that functionality without a relatively major overhaul. People who want a richer REPL can look at other options like IDLE, or IPython/Jupyter. By the way - if you're on a system with readline support included with Python, GNU readline apparently has a binding for clear-screen (CTRL-L) so you may well have this functionality already (I don;'t use Unix or readline, so I can't comment for sure). So the proposal becomes limited to: """ Add a capability to the standard REPL to recognise and support "commands" (as distinct from executable Python code) and provide a "clear screen" command. """ This feature is only needed for users of the standard Python REPL, on systems without readline support (i.e. Windows). I don't think that's a significant enough benefit to warrant the change (even if we take into account the potential opportunity for additional commands that we'd get from adding command support to the REPL). Paul
On Mon, Sep 19, 2016 at 1:12 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Hooking Ctrl+L to clear the screen can be implemented for Windows Vista and later via the ReadConsole pInputControl parameter, as called by PyOS_StdioReadline. It should be possible to match how GNU readline works -- i.e. clear the screen, reprint the prompt, flush the input buffer, and write the current line's input back to the input buffer. The pInputControl parameter can also be used to implement Unix-style Ctrl+D to end a read anywhere on a line, whereas the classic [Ctrl+Z][Enter] has to be entered at the start of a line.
On Mon, Sep 19, 2016 at 02:45:53PM +0000, eryk sun <eryksun@gmail.com> wrote:
[Ctrl+D] also recognized as EOF only at the start of an input. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Mon, Sep 19, 2016 at 3:07 PM, Oleg Broytman <phd@phdru.name> wrote:
[Ctrl+D] also recognized as EOF only at the start of an input.
You're right. I was mixing it up with sys.stdin.buffer.raw.read(), for which Ctrl+D can end the read anywhere if entered twice. Having to enter it twice may be a bug, because os.read(0, 100) works fine. So making it compatible with GNU readline is more complicated, but I think it's possible. If the Ctrl+D isn't at the start of the line, it could write the result up to the "\x04" back to the input buffer and resume the read.
On Mon, Sep 19, 2016 at 9:56 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I agree; however, the bar for getting something onto PyPI is far lower than the stdlib, and it makes it far easier to get a bit of testing (hey, folks, here's what I'm playing with, can you try pip-installing it and see if it works on your platform please). So the "first on PyPI, then in the stdlib" route does have a lot of merit. But you're quite right that we don't want to depend on a ton of packages.... ChrisA
On 9/19/2016 4:31 AM, Paul Moore wrote:
shutil.get_terminal_size() is available on all platforms.
On windows, it works with Command Prompt and PowerShell but fails in IDLE, as it must. In the absence of knowledge, it guesses the default of 80 x 24 (as documented). AFAIK, there is no way whether an answer of 80 x 24 is correct or arbitrary nonsense. Returning 0 x 0 instead would be more informative. Terry Jan Reedy
On Mon, Sep 19, 2016 at 06:18:38AM -0400, Terry Reedy wrote:
Why "must" it fail? What is it about the IDLE terminal that prevents it from emulating an actual terminal, like all(?) the other terminal emulation programs people use? I just opened my Konqueror file & web browser, gave the command "Show Terminal Emulator", and ran Python: py> import shutil py> shutil.get_terminal_size() os.terminal_size(columns=85, lines=10) That's spot on perfectly correct. I then resized the window and tried it again: py> shutil.get_terminal_size() os.terminal_size(columns=108, lines=13) I then quit Python, and ran idle3.3 from the Konqueror terminal. Unfortunately, get_terminal_size() returned the size of the *Konqueror* terminal, instead of the IDLE terminal. I think that's a bug. I don't know if its a bug in IDLE or get_terminal_size() or both. -- Steve
On 9/20/2016 9:31 AM, Steven D'Aprano wrote:
Good question. When I wrote that, I had in mind the qualification 'in IDLE's default mode, as IDLE is currently structured'. In the default mode with user code executed in a separate no-window process, there is currently no way for the child process to know the current size of Shell's tk text window in the parent process. But this is not the real story. See below.
IDLE's Shell is based on a tk Text and by design is not a terminal emulation. (Which terminal would it emulate?). Note that with proportional fonts, a text editor does not really have character columns, though it can be sized according to some 'average' character width. Also, IDLE is a development environment, not a run environment, and this impacts a few decisions.
This is what I did and equivalently got with Command Prompt.
If I run IDLE from Command Prompt, without or with the currently deprecated -n option, to run user code in the original IDLE process instead of a separate subprocess, I get the same -- the current size of the parent Command Prompt. The reason is that shutil.get_terminal_size first looks for int(os.environ['COLUMNS']) (or 'LINES') and if that fails, calls os.get_terminal_size(sys.__stdout__.fileno()). In both cases, the latter refer to the parent console. The 'obvious' possible solution is for Shell to set the environment variables when created or modified. On creation would be easy. Unfortunately, there is not, AFAIK, an application-accessible Resize event. A feature of tk is that geometry managers handle resizing automatically once the user sets the parameters of which widgets can be resized, and if so, min sizes and relative weights. But maybe there is a workaround. I am also not sure if modified environ is propagated to subprocesses. On Posix, subprocess.Popen uses os.execvp, so the parent environment is inherited by the new process. I don't know if this means that subsequent changes are inherited. On Windows, Popen used the system CreateProcess and I don't know what this does. A workaround would be to monkeypatch the function. In the rarely used -n mode, this would be easy. In normal mode, this would require the execution server to send an rpc message to the Shell client asking for its dimensions so the server can format the string to send to the client. I do not know if the current rpc mechanism is set up for requests from server to client. If not fixed soon, I should add the limitation to the IDLE doc. -- Terry Jan Reedy
Hello, I don't see why creating a clear command would interfere with dict.clear() which is a function/method. Although my first idea was a clear command, I have no problem if it is a clear() function from site.py. I didn't suggest cls because it is normally used to mean class. I use Windows and tested a simple (possibly not the best of course) solution that seems to work in REPL (but not in IDLE). import os import sys def clear(): if sys.platform == 'win32': os.system('cls') else: os.system('clear') Best regards, JM segunda-feira, 19 de Setembro de 2016 às 03:33:45 UTC+1, Steven D'Aprano escreveu:
On 19 September 2016 at 21:35, João Matos <jcrmatos@gmail.com> wrote:
Ah, I think people had misunderstood your proposal of a "command" as something where you didn't have to type the parentheses. I know I did. If you're OK with what you type at the REPL being >>> clear() then that's much easier to achieve. For example, if you install click (https://pypi.python.org/pypi/click) you can just add "from click import clear" at the start of your REPL session (or add it to your PYTHONSTARTUP if you want it always available) and you're done. Adding similar functionality to the stdlib somewhere (for example os or shutil - I doubt it's going to get accepted as a builtin) isn't inconceivable. I'm still not sure the benefit is sufficient to be worthwhile (it might be more useful to just bite the bullet and bundle one of the many curses variants for Windows into the distribution, and make the curses module cross-platform once and for all, rather than implementing individual bits of functionality) but if someone wanted to contribute a patch on the tracker, it might be accepted. Paul
On 20 September 2016 at 08:57, אלעזר <elazarg@gmail.com> wrote:
Python's grammar is deliberately not context sensitive, as that makes it easier to parse (for both humans and computers). In particular, this means that things *other* than the Python interpreter can parse Python easily (think editor syntax highlighting, linters, etc). There have been occasional deviations from this (for example, the "as" in "import foo as bar" was, for a time, only a keyword in that specific context) but I don't believe any of them survived long-term. Guido has always avoided constructs that need lookahead or other contextual information to parse correctly, for this specific reason. Paul
On Tue, Sep 27, 2016 at 10:05:16AM -0700, João Matos wrote:
Hello,
It doesn't work in Windows.
What is "it"? Are you talking about Ctrl-L to clear the screen? Perhaps we should start by adding Ctrl-L as a standard way to clear the Python REPL, in the same way that Ctrl-C is the standard way to interrupt the interpreter regardless of whether you are using Linux, Mac or Windows. (Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows is Ctrl-Z + Return. Can that be standardized to Ctrl-D everywhere?) -- Steve
On Thu, Sep 29, 2016 at 12:04:28PM +1000, Steven D'Aprano <steve@pearwood.info> wrote:
(Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows is Ctrl-Z + Return. Can that be standardized to Ctrl-D everywhere?)
I don't think consistency should go that far. Consistency inside the platform is more important than consistency between platforms, and other w32 console programs understand [Ctrl]+[Z] as EOF and as far as I know only [Ctrl]+[Z].
-- Steve
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Thu, Sep 29, 2016 at 12:04 PM, Steven D'Aprano <steve@pearwood.info> wrote:
(Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows is Ctrl-Z + Return. Can that be standardized to Ctrl-D everywhere?)
Sadly, I suspect not. If you're running in the default Windows terminal emulator (the one a normal user will get by invoking cmd.exe), you're running under a lot of restrictions, and I believe one of them is that you can't get Ctrl-D without an enter. But it would be very nice to support both. ChrisA
On Wed, Sep 28, 2016, at 23:36, Chris Angelico wrote:
Well, we could read _everything_ in character-at-a-time mode, and implement our own line editing. In effect, that's what readline is doing. The main consequence of reading everything in character-at-a-time mode is that we'd have to implement everything ourselves, and the line editing you get *without* doing it yourself is somewhat nicer on Windows than on Linux (it supports cursor movement, inserting characters, and history). On Wed, Sep 28, 2016, at 23:41, אלעזר wrote:
It runs inside it, but it's using the "Windows Subsystem for Linux", which (I assume) reads character-at-a-time and feeds it to a Unix-like terminal driver, (which Bash then has incidentally also put in character-at-a-time mode by using readline - to see what you get on WSL *without* doing this, try running "cat" under bash.exe)
On Tue, Oct 4, 2016 at 2:22 PM, Random832 <random832@fastmail.com> wrote:
3.6+ switched to calling ReadConsoleW, which allows using a 32-bit control mask to indicate which ASCII control codes should terminate a read. The control character is left in the input string, so it's possible to define custom behavior for multiple control characters. Here's a basic ctypes example of how this feature works. In each case, after calling ReadConsoleW I enter "spam" and then type a control character to terminate the read. import sys import msvcrt import ctypes kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) ReadConsoleW = kernel32.ReadConsoleW CTRL_MASK = 2 ** 32 - 1 # all ctrl codes hin = msvcrt.get_osfhandle(sys.stdin.fileno()) buf = (ctypes.c_wchar * 10)(*('-' * 10)) pn = (ctypes.c_ulong * 1)() ctl = (ctypes.c_ulong * 4)(16, 0, CTRL_MASK, 0) >>> # Ctrl+2 or Ctrl+@ (i.e. NUL) ... ret = ReadConsoleW(hin, buf, 10, pn, ctl); print() spam >>> buf[:] 'spam\x00-----' >>> # Ctrl+D ... ret = ReadConsoleW(hin, buf, 10, pn, ctl); print() spam >>> buf[:] 'spam\x04-----' >>> # Ctrl+[ ... ret = ReadConsoleW(hin, buf, 10, pn, ctl); print() spam >>> buf[:] 'spam\x1b-----' This could be used to implement Ctrl+D and Ctrl+L support in PyOS_Readline. Supporting Ctrl+L to work like GNU readline wouldn't be a trivial one-liner, but it's doable. It has to clear the screen and also write the input (except the Ctrl+L) back to the input buffer.
Line-input mode also supports F7 for a history popup window to select a previous command; Ctrl+F to search the screen text; text selection (e.g. shift+arrows or Ctrl+A); copy/paste via Ctrl+C and Ctrl+V (or Ctrl+Insert and Shift+Insert); and parameterized input aliases ($1-$9 and $* for parameters). https://technet.microsoft.com/en-us/library/mt427362 https://technet.microsoft.com/en-us/library/cc753867
Let's take a look at how WSL modifies the console's global state. Here's a simple function to print the console's input and output modes and codepages, which we can call in the background to monitor the console state: def report(): hin = msvcrt.get_osfhandle(0) hout = msvcrt.get_osfhandle(1) modeIn = (ctypes.c_ulong * 1)() modeOut = (ctypes.c_ulong * 1)() kernel32.GetConsoleMode(hin, modeIn) kernel32.GetConsoleMode(hout, modeOut) cpIn = kernel32.GetConsoleCP() cpOut = kernel32.GetConsoleOutputCP() print('\nmodeIn=%x, modeOut=%x, cpIn=%d, cpOut=%d' % (modeIn[0], modeOut[0], cpIn, cpOut)) def monitor(): report() t = threading.Timer(10, monitor, ()) t.start() >>> monitor(); subprocess.call('bash.exe') modeIn=f7, modeOut=3, cpIn=437, cpOut=437 ... modeIn=2d8, modeOut=f, cpIn=65001, cpOut=65001 See the following page for a description of the mode flags: https://msdn.microsoft.com/en-us/library/ms686033 The output mode changed from 0x3 to 0xf, enabling DISABLE_NEWLINE_AUTO_RETURN (0x8) ENABLE_VIRTUAL_TERMINAL_PROCESSING (0x4) The input mode changed from 0xf7 to 0x2d8, enabling ENABLE_VIRTUAL_TERMINAL_INPUT (0x200) ENABLE_WINDOW_INPUT (0x8, probably for SIGWINCH) and disabling ENABLE_INSERT_MODE (0x20) ENABLE_ECHO_INPUT (0x4) ENABLE_LINE_INPUT (0x2) ENABLE_PROCESSED_INPUT (0x1) So you're correct that it's basically using a raw read, except it's also translating some input keys to VT100 sequences. If you Ctrl+Break out of WSL, don't plan to reuse the console for regular Windows console programs. You could reset the modes and codepages, but it'll simpler to just open a new console. Here's an example of the VT100 sequences for the arrow keys after breaking out of WSL: C:\>^[[A^[[B^[[C^[[D WSL also changes the input and output codepages to 65001 (UTF-8). It hasn't done anything to fix the console's broken support for non-ASCII input when using UTF-8. But instead of getting an empty read (i.e. EOF) like what we see in this case with the cooked read used by Windows Python, WSL's raw read simply strips out non-ASCII input. That's simply brilliant. /s
Hi all, I just tried with this official Python binary: Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32 and CTRL-L for sure does clear the window. It just doesn't then move the prompt to the top, so you end up with a bunch of empty lines, followed by the prompt. Stephan 2016-09-29 8:50 GMT+02:00 João Matos <jcrmatos@gmail.com>:
Hello, I tried on Python 2.7.10 and Python 3.5.2 and Ctrl-L doesn't work on both. I tried on 2 PCs with Windows 7 and none of them worked. What is your Windows version? Are you trying on the cmd.exe console or PS? Best regards, JM quinta-feira, 29 de Setembro de 2016 às 08:09:13 UTC+1, Stephan Houben escreveu:
Hi JM, Windows 7 Enterprise "Microsoft Windows [Version 6.1.7601]" I am running Python directly from the shortcut created on installation. But starting it from cmd.exe has the same effect. Codepage is 437 , this may be relevant? I just tried it on a Windows 10 PC, there it has the same effect. Stephan 2016-09-29 9:12 GMT+02:00 João Matos <jcrmatos@gmail.com>:
On Thu, Sep 29, 2016 at 7:12 AM, João Matos <jcrmatos@gmail.com> wrote:
What is your Windows version? Are you trying on the cmd.exe console or PS?
Are you talking about PowerShell ISE? That doesn't work for interactive console programs such as Python's REPL shell. Otherwise, FYI, there is no such thing as a cmd.exe or powershell.exe console. Those are shells, which can even run detached from a console using standard handles for the NUL device, pipes, or disk files. A shell that's attached to a console is just another console client application. Here's a brief overview of the Windows console system. Each console window is hosted by an instance of conhost.exe, but you can't simply run conhost.exe and get a console window. It depends on specific command-line arguments and handle inheritance, and Microsoft doesn't publish the implementation details. (It could be reverse engineered but there's not much to be gained from that.) A process can attach to a single console and set its standard input, output, and error file handles to either the console's input buffer or one of its screen buffers (or a new screen buffer via CreateConsoleScreenBuffer). This will be set up automatically by Windows if the executable is flagged as a console program and isn't run as a detached process. Otherwise a program can manually allocate or attach to a console via AllocConsole or AttachConsole. It can detach via FreeConsole. Attaching and detaching needs to be handled with care when updating the C standard FILE streams. Getting it wrong can crash the process.
On Thu, Sep 29, 2016 at 7:08 AM, Stephan Houben <stephanh42@gmail.com> wrote:
You probably have pyreadline installed. It calls ReadConsoleInputW to read low-level input records, bypassing the console's normal cooked read. See the following file that defines the key binding: https://github.com/pyreadline/pyreadline/blob/1.7/pyreadline/configuration/p... Unfortunately pyreadline is broken for non-ASCII input. It ignores the Alt+Numpad record sequences used for non-ASCII characters. Without having to implement readline module for Windows (personally, I don't use it), support for Ctrl+L can be added relatively easily in 3.6+. ReadConsoleW takes a parameter to specify a mask of ASCII control characters that terminate a read. The control character is left in the buffer, so code just has to be written that looks for various control characters to implement features such as a Ctrl+L clear screen.
On Sat, Sep 17, 2016 at 8:51 PM, João Matos <jcrmatos@gmail.com> wrote:
I'm not sure that it _is_ helpful, given that you're starting with a clean screen but not restarting the session (so you'll still have all the state from your previous work). If you want a completely fresh start, just exit Python, clear the screen with a shell command, and re-enter. The easiest way to play around with this would be to create a pure Python clear() function in your usercustomize or sitecustomize, and then try it in your own workflow - see whether it annoys you that it doesn't change the interpreter state. Maybe it will, maybe it won't. ChrisA
Hello, In other interpreted programming languages the clear screen command (whatever it is) also does not clear the session. It just clears the screen clutter. As I said, this would be very useful for newbies, which don't know anything about usercustomize or sitecustomize. Best regards, JM On 17-09-2016 12:07, Chris Angelico wrote:
With IPython, there are a number of ways to reset the terminal display: clear # %clear !cls #windows !reset - http://stackoverflow.com/questions/6892191/clearing-the-screen-in-ipython - Ctrl-L is a readline binding - http://pythonhosted.org/pyreadline/usage.html#pyreadline-with-python-interpr... - https://anaconda.org/anaconda/pyreadline - https://pypi.python.org/pypi/pyreadline - IPython >= 5 no longer uses pyreadline (instead, python prompt toolkit) - https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/prompt... #def clear - http://unix.stackexchange.com/questions/124762/how-does-clear-command-work - http://urwid.org/reference/display_modules.html#urwid.raw_display.Screen.cle... - https://rosettacode.org/wiki/Terminal_control/Clear_the_screen#Python On Saturday, September 17, 2016, João Matos <jcrmatos@gmail.com> wrote:
Hello, I know about those IPython commands and I searched and found several possible solutions to clear the screen in the CPython REPL, but all are, in my opinion, complex for a newbie. The existence of a clear command would be simple and obvious, therefore accessible to newbies. Best regards, JM On 17-09-2016 14:15, Wes Turner wrote:
On Sat, Sep 17, 2016 at 1:15 PM, Wes Turner <wes.turner@gmail.com> wrote:
!cls #windows
cmd's built-in cls command doesn't clear just the screen, like a VT100 \x1b[1J. It clears the console's entire scrollback buffer. Unix `clear` may also work like that. With GNOME Terminal in Linux, `clear` leaves a single screen in the scrollback buffer.
Hi! On Sat, Sep 17, 2016 at 11:51:16AM +0100, Jo??o Matos <jcrmatos@gmail.com> wrote:
Hello,
I would like to suggest adding a clear command (not function) to Python.
Pressing [Ctrl]+[L] works for me.
Best regards, JM
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Sat, Sep 17, 2016 at 11:11 AM, João Matos <jcrmatos@gmail.com> wrote:
Windows 10 added VT100 support to the console, so you can create a little cls() function to clear the screen: cls = lambda: print('\x1b[1J', end='', flush=True) VT100 support isn't enabled by default. However, cmd.exe always enables this mode. So run doskey.exe via os.system to enable VT100 mode while setting a convenient "cls" alias: import os os.system(r'doskey /exename=python.exe cls=cls()') This alias substitutes "cls()" for "cls" at the beginning of a line. This saves you from having to type "()" all the time. The alias isn't active for other programs; e.g. if you execute subprocess.call('powershell'), then "cls" will be the PowerShell alias for Clear-Host. You can also use ctypes instead of os.system and doskey.exe: import ctypes kernel32 = ctypes.WinDLL('kernel32') hStdOut = kernel32.GetStdHandle(-11) # enable VT100 mode mode = (ctypes.c_uint * 1)() kernel32.GetConsoleMode(hStdOut, mode) kernel32.SetConsoleMode(hStdOut, mode[0] | 4) # define a cls() function and set a console alias cls = lambda: print('\x1b[1J', end='', flush=True) kernel32.AddConsoleAliasW('cls', 'cls()', 'python.exe') For older versions of Windows you can use ANSICON or ConEmu, which use DLL injection to extend the console API. Python's colorama and pyreadline modules should also work for this.
Hello, I searched and found several possible solutions to clear the screen in the CPython REPL, but all are, in my opinion, complex for a newbie. The existence of a clear command would be a simple and obvious, therefore accessible to newbies. Best regards, JM On 17-09-2016 14:34, eryk sun wrote:
On 9/17/2016 6:51 AM, João Matos wrote:
Python is not an 'interpreted' language in the sense that you are using the word. It is a compiled language that includes its compile function as part of the runtime. This enables an interactive mode. Python does not have commands, only statements, expressions, and functions, etcetera. This is why the 'exit()' and 'quit()' 'commands' are functions and require the parentheses. In interactive mode, a statement consisting of a single indentifier (or expression) causes display of a representation of the resulting object. You could request that the site module also add a clear() function. But the next problem is that clearing the screen is not a Python function and the Python runtime does not normally know how to do so. The implementation of 'clear screen' is specific to the particular console or window or terminal emulation. The control sequence for a window that emulates VT100 does not work on Windows Command Prompt (excepting possibly a non-default CP on Win 10) or necessarily IDLE or IPython or PyCharm or ... . The only assumption that Python makes about the screen it is running on is that '\n' is interpreted as a newline. IDLE has a 'Restart Shell' menu command with key binding. It does not physically clear the screen but it draws a double line, which serves most of the 'clear the mind' purpose. If there is an editor window open, one can close and reopen the Shell window to start really fresh. At least on Windows, Select All (^A) + Del (or Backspace) is the common idiom for clearing an editor box in a GUI. Is this used on other OSes? This works in an IDLE editor also. It is disabled in the Shell because IDLE's original designers thought to protect beginners from doing such. A clear screen menu option has been requested, but it has never become a top priority. In any case, this, like other current clear screen commands, would work because the command would go to the window manager and not to python. -- Terry Jan Reedy
On Sat, Sep 17, 2016 at 11:51:16AM +0100, João Matos wrote:
Hello,
I would like to suggest adding a clear command (not function) to Python.
While technically "clear" could be a command, I think it should not be. First off, making clear a reserved keyword, and a statement, like print in Python 2, raise or import, would be a major backwards compatibility break. It would mean dict.clear() has to be renamed, and it would break lots of existing code. So making clear a keyword is not going to happen. If could be a pseudo-built-in, like help(), quit() and exit(), added to built-ins by the site module. In that case, it is *technically* possible to have it operate without the parentheses: class ClearType: def __repr__(self): # code to clear the screen here ... clear = ClearType() so that when you enter clear at the interactive interpreter, __repr__ is called and it clears the screen. But I would argue against it. Instead, it is better to use the same convention that executable code that has side-effects should be implemented as a function call. So I suggest following the design of exit() and quit(): py> exit Use exit() or Ctrl-D (i.e. EOF) to exit class ClearType: def __repr__(self): return "Use clear() or Ctrl-L (i.e. FF) to clear the screen" def __call__(self): # clear screen code goes here clear = ClearType() # or possibly cls ? That is, *if* we add this function at all. Personally, I agree with you. There are many different ways of clearing the screen, but they depend on the specific terminal used, whether readline is active or not, the operating system, etc. I think that interactive use is important enough that we should have a standard way of clearing the screen. I personally often find myself just holding down the Enter key until I have a blank screen. In this ticket: http://bugs.python.org/issue27771 Raymond Hettinger mentions that it is an often-requested feature by learners, and I believe that IDLE has an active task for this feature: http://bugs.python.org/issue6143 but I don't see any tasks for a clear screen command for the default REPL. I'm in favour of adding a clear() *function* to the site.py module, similar to exit/quit/help, but not making it "magical" or a keyword that doesn't require brackets. But I don't know how to implement it for the large variety of terminals and operating systems supported by Python. (The fallback if all else fails is easy: get the height of the terminal, in lines, and print that many blank lines.) -- Steve
On Mon, Sep 19, 2016 at 12:32 PM, Steven D'Aprano <steve@pearwood.info> wrote:
(The fallback if all else fails is easy: get the height of the terminal, in lines, and print that many blank lines.)
Assuming you can get the height in lines. Have you tried that in the default Windows shell? I don't think tcgetattr works on Windows. ChrisA
Chris Angelico writes:
Since a command is out of the question (look what happened to print!), it's a matter of defining a callable with a repr that explains how to call it (like help and friends). So if someone really wants this to happen, I would say the thing to do is to define that callable, put it on PyPI, add support for all the platforms, fix all the bugs, and when there are a couple million downloads, suggest preloading it in interpreter then. Don't forget how to document how to add it to site.py. But I would think that nowadays we'd push in the opposite direction (as with print). That is, with the great improvements in IDLE (batteries included!), IPython, and now we have Jupyter, you could now argue that the built-in REPL should lose at least one of the two exit functions (since EOF is a sufficient reason to exit). (help() still makes sense as the public interface to __doc__.) In other words, the built-in REPL should just provide some line-editing features and otherwise simply read lines, incrementally compile and execute them, and print results. Leave UI conveniences to other applications that (gasp!) specialize in providing consistent, powerful UI that isn't going to feel like bat guano on Tim's keyboard. IMHO YMMV, of course.
On 19 September 2016 at 03:40, Chris Angelico <rosuav@gmail.com> wrote:
shutil.get_terminal_size() is available on all platforms. I don't think it would be unreasonable to add shutil.clear_terminal() (at the moment, get_terminal_size is the only "terminal handling" function in shutil, but it would be the obvious place to add others if we chose to do so). Paul
On Mon, Sep 19, 2016 at 6:31 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Sounds good to me. This is definitely sounding complicated and messy enough to justify (a) writing a function to clear the screen, and (b) testing that function thoroughly as a PyPI module before pushing anything into the stdlib. ChrisA
On Mon, Sep 19, 2016 at 06:38:00PM +1000, Chris Angelico wrote:
This isn't Node.js where standard operating procedure is to rely on the third-party npm ecosystem even for tiny, ten line functions. And we should be *glad* that's not the case: http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ People don't often install minor or small packages off PyPI as a matter of course: they either roll their own, or do without, depending on which is more painful, or whether they are even allowed to download third-party software (not everybody is), or whether managing the dependency is more or less work than writing their own. I get it that not everything belongs in the std lib, and I get it that for *some* people (but not all) its easy to rely on packages in PyPI. But there's quite considerable friction in getting *small* things off PyPI. For starters, you have to know it exists, you have to trust that its functional and well-written. There is a huge amount of junk, abandoned and "version 0.1" packages on PyPI that nobody in their right mind should use. Dependencies don't come for free, they add complexity and cost to a project. Not everything belongs as a package on PyPI either. If the cost of dealing with the added dependency is greater than the benefit gained, people won't use third-party packages on PyPI. For small but useful functionality, saying "Put it on PyPI" is effectively just a dismissal. For relatively small pieces of functionality, if it is useful enough, we should just add it to the std lib, and if it isn't, we should just say it isn't useful enough. We shouldn't condemn supporters of the idea to this false hope that if they can convince a thousand, or a million, people to download their package, it will be added to PyPI. -- Steve
On 19 September 2016 at 12:56, Steven D'Aprano <steve@pearwood.info> wrote:
"... to the stdlib". Agreed. However, there are libraries already on PyPI that try to act in the role of "useful bits that aren't in the stdlib". The boltons project is one that I know of. Maybe a middle ground between stdlib inclusion and outright rejection would be the suggestion to submit the code to one of those 3rd party projects? There's no implication that doing so means that there's any better chance of getting accepted for the stdlib, but it does offer an option for people who want to publish their idea for wider use. For this particular suggestion, though, I don't think that's the case. I think it's going to either be something that's accepted into the stdlib, or something that's rejected as too platform-specific or messy to standardise, and people should roll their own implementation. I'm inclined to think there may be some scope for a blog entry or HOWTO on customising your personal Python environment - what facilities there are to do so, what other options (such as different REPLs) are available, and how to judge whether it's worth doing or not. Lots of people (myself included at times!) seem to be unaware of the options available. It's not something I'm likely to ever write, but if anyone is interested in doing so, it might be useful background for this type of discussion. Paul
On 19 September 2016 at 13:10, Paul Moore <p.f.moore@gmail.com> wrote:
Note, by the way, that in the form of a Python function, this capability is already available in lots of places - colorama and click include it, for a start. And even the stdlib has a version in the curses module (albeit not available on Windows). In the light of this, there seems little reason to water down this proposal to "provide a clear screen function in the stdlib". Taken in its original form of "add a command to the REPL to clear the screen", the main issue is that the standard Python REPL simply doesn't have a concept of "REPL commands", so there's nowhere really to add that functionality without a relatively major overhaul. People who want a richer REPL can look at other options like IDLE, or IPython/Jupyter. By the way - if you're on a system with readline support included with Python, GNU readline apparently has a binding for clear-screen (CTRL-L) so you may well have this functionality already (I don;'t use Unix or readline, so I can't comment for sure). So the proposal becomes limited to: """ Add a capability to the standard REPL to recognise and support "commands" (as distinct from executable Python code) and provide a "clear screen" command. """ This feature is only needed for users of the standard Python REPL, on systems without readline support (i.e. Windows). I don't think that's a significant enough benefit to warrant the change (even if we take into account the potential opportunity for additional commands that we'd get from adding command support to the REPL). Paul
On Mon, Sep 19, 2016 at 1:12 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Hooking Ctrl+L to clear the screen can be implemented for Windows Vista and later via the ReadConsole pInputControl parameter, as called by PyOS_StdioReadline. It should be possible to match how GNU readline works -- i.e. clear the screen, reprint the prompt, flush the input buffer, and write the current line's input back to the input buffer. The pInputControl parameter can also be used to implement Unix-style Ctrl+D to end a read anywhere on a line, whereas the classic [Ctrl+Z][Enter] has to be entered at the start of a line.
On Mon, Sep 19, 2016 at 02:45:53PM +0000, eryk sun <eryksun@gmail.com> wrote:
[Ctrl+D] also recognized as EOF only at the start of an input. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Mon, Sep 19, 2016 at 3:07 PM, Oleg Broytman <phd@phdru.name> wrote:
[Ctrl+D] also recognized as EOF only at the start of an input.
You're right. I was mixing it up with sys.stdin.buffer.raw.read(), for which Ctrl+D can end the read anywhere if entered twice. Having to enter it twice may be a bug, because os.read(0, 100) works fine. So making it compatible with GNU readline is more complicated, but I think it's possible. If the Ctrl+D isn't at the start of the line, it could write the result up to the "\x04" back to the input buffer and resume the read.
On Mon, Sep 19, 2016 at 9:56 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I agree; however, the bar for getting something onto PyPI is far lower than the stdlib, and it makes it far easier to get a bit of testing (hey, folks, here's what I'm playing with, can you try pip-installing it and see if it works on your platform please). So the "first on PyPI, then in the stdlib" route does have a lot of merit. But you're quite right that we don't want to depend on a ton of packages.... ChrisA
On 9/19/2016 4:31 AM, Paul Moore wrote:
shutil.get_terminal_size() is available on all platforms.
On windows, it works with Command Prompt and PowerShell but fails in IDLE, as it must. In the absence of knowledge, it guesses the default of 80 x 24 (as documented). AFAIK, there is no way whether an answer of 80 x 24 is correct or arbitrary nonsense. Returning 0 x 0 instead would be more informative. Terry Jan Reedy
On Mon, Sep 19, 2016 at 06:18:38AM -0400, Terry Reedy wrote:
Why "must" it fail? What is it about the IDLE terminal that prevents it from emulating an actual terminal, like all(?) the other terminal emulation programs people use? I just opened my Konqueror file & web browser, gave the command "Show Terminal Emulator", and ran Python: py> import shutil py> shutil.get_terminal_size() os.terminal_size(columns=85, lines=10) That's spot on perfectly correct. I then resized the window and tried it again: py> shutil.get_terminal_size() os.terminal_size(columns=108, lines=13) I then quit Python, and ran idle3.3 from the Konqueror terminal. Unfortunately, get_terminal_size() returned the size of the *Konqueror* terminal, instead of the IDLE terminal. I think that's a bug. I don't know if its a bug in IDLE or get_terminal_size() or both. -- Steve
On 9/20/2016 9:31 AM, Steven D'Aprano wrote:
Good question. When I wrote that, I had in mind the qualification 'in IDLE's default mode, as IDLE is currently structured'. In the default mode with user code executed in a separate no-window process, there is currently no way for the child process to know the current size of Shell's tk text window in the parent process. But this is not the real story. See below.
IDLE's Shell is based on a tk Text and by design is not a terminal emulation. (Which terminal would it emulate?). Note that with proportional fonts, a text editor does not really have character columns, though it can be sized according to some 'average' character width. Also, IDLE is a development environment, not a run environment, and this impacts a few decisions.
This is what I did and equivalently got with Command Prompt.
If I run IDLE from Command Prompt, without or with the currently deprecated -n option, to run user code in the original IDLE process instead of a separate subprocess, I get the same -- the current size of the parent Command Prompt. The reason is that shutil.get_terminal_size first looks for int(os.environ['COLUMNS']) (or 'LINES') and if that fails, calls os.get_terminal_size(sys.__stdout__.fileno()). In both cases, the latter refer to the parent console. The 'obvious' possible solution is for Shell to set the environment variables when created or modified. On creation would be easy. Unfortunately, there is not, AFAIK, an application-accessible Resize event. A feature of tk is that geometry managers handle resizing automatically once the user sets the parameters of which widgets can be resized, and if so, min sizes and relative weights. But maybe there is a workaround. I am also not sure if modified environ is propagated to subprocesses. On Posix, subprocess.Popen uses os.execvp, so the parent environment is inherited by the new process. I don't know if this means that subsequent changes are inherited. On Windows, Popen used the system CreateProcess and I don't know what this does. A workaround would be to monkeypatch the function. In the rarely used -n mode, this would be easy. In normal mode, this would require the execution server to send an rpc message to the Shell client asking for its dimensions so the server can format the string to send to the client. I do not know if the current rpc mechanism is set up for requests from server to client. If not fixed soon, I should add the limitation to the IDLE doc. -- Terry Jan Reedy
Hello, I don't see why creating a clear command would interfere with dict.clear() which is a function/method. Although my first idea was a clear command, I have no problem if it is a clear() function from site.py. I didn't suggest cls because it is normally used to mean class. I use Windows and tested a simple (possibly not the best of course) solution that seems to work in REPL (but not in IDLE). import os import sys def clear(): if sys.platform == 'win32': os.system('cls') else: os.system('clear') Best regards, JM segunda-feira, 19 de Setembro de 2016 às 03:33:45 UTC+1, Steven D'Aprano escreveu:
On 19 September 2016 at 21:35, João Matos <jcrmatos@gmail.com> wrote:
Ah, I think people had misunderstood your proposal of a "command" as something where you didn't have to type the parentheses. I know I did. If you're OK with what you type at the REPL being >>> clear() then that's much easier to achieve. For example, if you install click (https://pypi.python.org/pypi/click) you can just add "from click import clear" at the start of your REPL session (or add it to your PYTHONSTARTUP if you want it always available) and you're done. Adding similar functionality to the stdlib somewhere (for example os or shutil - I doubt it's going to get accepted as a builtin) isn't inconceivable. I'm still not sure the benefit is sufficient to be worthwhile (it might be more useful to just bite the bullet and bundle one of the many curses variants for Windows into the distribution, and make the curses module cross-platform once and for all, rather than implementing individual bits of functionality) but if someone wanted to contribute a patch on the tracker, it might be accepted. Paul
On 20 September 2016 at 08:57, אלעזר <elazarg@gmail.com> wrote:
Python's grammar is deliberately not context sensitive, as that makes it easier to parse (for both humans and computers). In particular, this means that things *other* than the Python interpreter can parse Python easily (think editor syntax highlighting, linters, etc). There have been occasional deviations from this (for example, the "as" in "import foo as bar" was, for a time, only a keyword in that specific context) but I don't believe any of them survived long-term. Guido has always avoided constructs that need lookahead or other contextual information to parse correctly, for this specific reason. Paul
On Tue, Sep 27, 2016 at 10:05:16AM -0700, João Matos wrote:
Hello,
It doesn't work in Windows.
What is "it"? Are you talking about Ctrl-L to clear the screen? Perhaps we should start by adding Ctrl-L as a standard way to clear the Python REPL, in the same way that Ctrl-C is the standard way to interrupt the interpreter regardless of whether you are using Linux, Mac or Windows. (Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows is Ctrl-Z + Return. Can that be standardized to Ctrl-D everywhere?) -- Steve
On Thu, Sep 29, 2016 at 12:04:28PM +1000, Steven D'Aprano <steve@pearwood.info> wrote:
(Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows is Ctrl-Z + Return. Can that be standardized to Ctrl-D everywhere?)
I don't think consistency should go that far. Consistency inside the platform is more important than consistency between platforms, and other w32 console programs understand [Ctrl]+[Z] as EOF and as far as I know only [Ctrl]+[Z].
-- Steve
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Thu, Sep 29, 2016 at 12:04 PM, Steven D'Aprano <steve@pearwood.info> wrote:
(Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows is Ctrl-Z + Return. Can that be standardized to Ctrl-D everywhere?)
Sadly, I suspect not. If you're running in the default Windows terminal emulator (the one a normal user will get by invoking cmd.exe), you're running under a lot of restrictions, and I believe one of them is that you can't get Ctrl-D without an enter. But it would be very nice to support both. ChrisA
On Wed, Sep 28, 2016, at 23:36, Chris Angelico wrote:
Well, we could read _everything_ in character-at-a-time mode, and implement our own line editing. In effect, that's what readline is doing. The main consequence of reading everything in character-at-a-time mode is that we'd have to implement everything ourselves, and the line editing you get *without* doing it yourself is somewhat nicer on Windows than on Linux (it supports cursor movement, inserting characters, and history). On Wed, Sep 28, 2016, at 23:41, אלעזר wrote:
It runs inside it, but it's using the "Windows Subsystem for Linux", which (I assume) reads character-at-a-time and feeds it to a Unix-like terminal driver, (which Bash then has incidentally also put in character-at-a-time mode by using readline - to see what you get on WSL *without* doing this, try running "cat" under bash.exe)
On Tue, Oct 4, 2016 at 2:22 PM, Random832 <random832@fastmail.com> wrote:
3.6+ switched to calling ReadConsoleW, which allows using a 32-bit control mask to indicate which ASCII control codes should terminate a read. The control character is left in the input string, so it's possible to define custom behavior for multiple control characters. Here's a basic ctypes example of how this feature works. In each case, after calling ReadConsoleW I enter "spam" and then type a control character to terminate the read. import sys import msvcrt import ctypes kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) ReadConsoleW = kernel32.ReadConsoleW CTRL_MASK = 2 ** 32 - 1 # all ctrl codes hin = msvcrt.get_osfhandle(sys.stdin.fileno()) buf = (ctypes.c_wchar * 10)(*('-' * 10)) pn = (ctypes.c_ulong * 1)() ctl = (ctypes.c_ulong * 4)(16, 0, CTRL_MASK, 0) >>> # Ctrl+2 or Ctrl+@ (i.e. NUL) ... ret = ReadConsoleW(hin, buf, 10, pn, ctl); print() spam >>> buf[:] 'spam\x00-----' >>> # Ctrl+D ... ret = ReadConsoleW(hin, buf, 10, pn, ctl); print() spam >>> buf[:] 'spam\x04-----' >>> # Ctrl+[ ... ret = ReadConsoleW(hin, buf, 10, pn, ctl); print() spam >>> buf[:] 'spam\x1b-----' This could be used to implement Ctrl+D and Ctrl+L support in PyOS_Readline. Supporting Ctrl+L to work like GNU readline wouldn't be a trivial one-liner, but it's doable. It has to clear the screen and also write the input (except the Ctrl+L) back to the input buffer.
Line-input mode also supports F7 for a history popup window to select a previous command; Ctrl+F to search the screen text; text selection (e.g. shift+arrows or Ctrl+A); copy/paste via Ctrl+C and Ctrl+V (or Ctrl+Insert and Shift+Insert); and parameterized input aliases ($1-$9 and $* for parameters). https://technet.microsoft.com/en-us/library/mt427362 https://technet.microsoft.com/en-us/library/cc753867
Let's take a look at how WSL modifies the console's global state. Here's a simple function to print the console's input and output modes and codepages, which we can call in the background to monitor the console state: def report(): hin = msvcrt.get_osfhandle(0) hout = msvcrt.get_osfhandle(1) modeIn = (ctypes.c_ulong * 1)() modeOut = (ctypes.c_ulong * 1)() kernel32.GetConsoleMode(hin, modeIn) kernel32.GetConsoleMode(hout, modeOut) cpIn = kernel32.GetConsoleCP() cpOut = kernel32.GetConsoleOutputCP() print('\nmodeIn=%x, modeOut=%x, cpIn=%d, cpOut=%d' % (modeIn[0], modeOut[0], cpIn, cpOut)) def monitor(): report() t = threading.Timer(10, monitor, ()) t.start() >>> monitor(); subprocess.call('bash.exe') modeIn=f7, modeOut=3, cpIn=437, cpOut=437 ... modeIn=2d8, modeOut=f, cpIn=65001, cpOut=65001 See the following page for a description of the mode flags: https://msdn.microsoft.com/en-us/library/ms686033 The output mode changed from 0x3 to 0xf, enabling DISABLE_NEWLINE_AUTO_RETURN (0x8) ENABLE_VIRTUAL_TERMINAL_PROCESSING (0x4) The input mode changed from 0xf7 to 0x2d8, enabling ENABLE_VIRTUAL_TERMINAL_INPUT (0x200) ENABLE_WINDOW_INPUT (0x8, probably for SIGWINCH) and disabling ENABLE_INSERT_MODE (0x20) ENABLE_ECHO_INPUT (0x4) ENABLE_LINE_INPUT (0x2) ENABLE_PROCESSED_INPUT (0x1) So you're correct that it's basically using a raw read, except it's also translating some input keys to VT100 sequences. If you Ctrl+Break out of WSL, don't plan to reuse the console for regular Windows console programs. You could reset the modes and codepages, but it'll simpler to just open a new console. Here's an example of the VT100 sequences for the arrow keys after breaking out of WSL: C:\>^[[A^[[B^[[C^[[D WSL also changes the input and output codepages to 65001 (UTF-8). It hasn't done anything to fix the console's broken support for non-ASCII input when using UTF-8. But instead of getting an empty read (i.e. EOF) like what we see in this case with the cooked read used by Windows Python, WSL's raw read simply strips out non-ASCII input. That's simply brilliant. /s
Hi all, I just tried with this official Python binary: Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32 and CTRL-L for sure does clear the window. It just doesn't then move the prompt to the top, so you end up with a bunch of empty lines, followed by the prompt. Stephan 2016-09-29 8:50 GMT+02:00 João Matos <jcrmatos@gmail.com>:
Hello, I tried on Python 2.7.10 and Python 3.5.2 and Ctrl-L doesn't work on both. I tried on 2 PCs with Windows 7 and none of them worked. What is your Windows version? Are you trying on the cmd.exe console or PS? Best regards, JM quinta-feira, 29 de Setembro de 2016 às 08:09:13 UTC+1, Stephan Houben escreveu:
Hi JM, Windows 7 Enterprise "Microsoft Windows [Version 6.1.7601]" I am running Python directly from the shortcut created on installation. But starting it from cmd.exe has the same effect. Codepage is 437 , this may be relevant? I just tried it on a Windows 10 PC, there it has the same effect. Stephan 2016-09-29 9:12 GMT+02:00 João Matos <jcrmatos@gmail.com>:
On Thu, Sep 29, 2016 at 7:12 AM, João Matos <jcrmatos@gmail.com> wrote:
What is your Windows version? Are you trying on the cmd.exe console or PS?
Are you talking about PowerShell ISE? That doesn't work for interactive console programs such as Python's REPL shell. Otherwise, FYI, there is no such thing as a cmd.exe or powershell.exe console. Those are shells, which can even run detached from a console using standard handles for the NUL device, pipes, or disk files. A shell that's attached to a console is just another console client application. Here's a brief overview of the Windows console system. Each console window is hosted by an instance of conhost.exe, but you can't simply run conhost.exe and get a console window. It depends on specific command-line arguments and handle inheritance, and Microsoft doesn't publish the implementation details. (It could be reverse engineered but there's not much to be gained from that.) A process can attach to a single console and set its standard input, output, and error file handles to either the console's input buffer or one of its screen buffers (or a new screen buffer via CreateConsoleScreenBuffer). This will be set up automatically by Windows if the executable is flagged as a console program and isn't run as a detached process. Otherwise a program can manually allocate or attach to a console via AllocConsole or AttachConsole. It can detach via FreeConsole. Attaching and detaching needs to be handled with care when updating the C standard FILE streams. Getting it wrong can crash the process.
On Thu, Sep 29, 2016 at 7:08 AM, Stephan Houben <stephanh42@gmail.com> wrote:
You probably have pyreadline installed. It calls ReadConsoleInputW to read low-level input records, bypassing the console's normal cooked read. See the following file that defines the key binding: https://github.com/pyreadline/pyreadline/blob/1.7/pyreadline/configuration/p... Unfortunately pyreadline is broken for non-ASCII input. It ignores the Alt+Numpad record sequences used for non-ASCII characters. Without having to implement readline module for Windows (personally, I don't use it), support for Ctrl+L can be added relatively easily in 3.6+. ReadConsoleW takes a parameter to specify a mask of ASCII control characters that terminate a read. The control character is left in the buffer, so code just has to be written that looks for various control characters to implement features such as a Ctrl+L clear screen.
participants (16)
-
Chris Angelico -
Dennis Brakhane -
eryk sun -
Greg Ewing -
João Matos -
Michel Desmoulin -
Oleg Broytman -
Paul Moore -
Random832 -
Stephan Houben -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy -
Wes Turner -
Zachary Ware -
אלעזר