Hi! 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.

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.

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:

On Sat, Sep 17, 2016 at 8:51 PM, João Matos wrote:

...

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.

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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Sat, Sep 17, 2016 at 11:11 AM, João Matos wrote:

On 17-09-2016 12:07, Oleg Broytman wrote:

...

Pressing [Ctrl]+[L] works for me.

Doesn't work on Windows.

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 17-09-2016 12:07, Oleg Broytman wrote:

...

Pressing [Ctrl]+[L] works for me.

Doesn't work on Windows. Windows 10 added VT100 support to the console, so you can create a

On Sat, Sep 17, 2016 at 11:11 AM, João Matos wrote: 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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 9/17/2016 6:51 AM, João Matos wrote:

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.

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 Mon, Sep 19, 2016 at 12:32 PM, Steven D'Aprano 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

On 19 September 2016 at 03:40, Chris Angelico wrote:

On Mon, Sep 19, 2016 at 12:32 PM, Steven D'Aprano 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.

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 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 19 September 2016 at 12:56, Steven D'Aprano wrote:

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

"... 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 wrote:

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.

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 9:45 AM, eryk sun wrote:

On Mon, Sep 19, 2016 at 1:12 PM, Paul Moore wrote:

...

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).

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.

That sounds lovely, any chance you could work up a patch? :) -- Zach

On Mon, Sep 19, 2016 at 3:07 PM, Oleg Broytman 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 19 September 2016 at 21:35, João Matos wrote:

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')

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

Hello, You are correct. Thanks for the explanation. Best regards, JM terça-feira, 20 de Setembro de 2016 às 02:56:57 UTC+1, Steven D'Aprano escreveu:

On Mon, Sep 19, 2016 at 01:35:53PM -0700, João Matos wrote:

...

Hello,

I don't see why creating a clear command would interfere with dict.clear() which is a function/method.

For the same reason that you can't have a method called foo.while or foo.if or foo.raise. If clear is a "command" (a statement) it would need to be a keyword, like while, if and raise.

-- Steve _______________________________________________ Python-ideas mailing list Python...@python.org javascript: https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 20 September 2016 at 08:57, אלעזר wrote:

This is since in Python there are no contextual keywords (like "override" and "final" in C++). I remember encountering error in a Django project where accessing u.pass was a syntax error, but there *was* a field "pass" in u and they had to resort to getattr(u, "pass"). What is the reasoning behind that decision?

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

+1 for this. I regularly miss this feature. Le 17/09/2016 à 13:12, João Matos a écrit :

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:

...

On Sat, Sep 17, 2016 at 8:51 PM, João Matos wrote:

...

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.

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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 9/20/2016 9:31 AM, Steven D'Aprano wrote:

On Mon, Sep 19, 2016 at 06:18:38AM -0400, Terry Reedy wrote:

...

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.

Why "must" it fail?

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.

What is it about the IDLE terminal that prevents it from emulating an actual terminal, like all(?) the other terminal emulation programs people use?

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.

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)

This is what I did and equivalently got with Command Prompt.

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.

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

I don't know if it works on Windows, but at least in Linux pressing Ctrl-L will do exactly what you describe (as long as the REPL uses readline) On 17.09.2016 12:51, João Matos wrote:

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

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

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 PM, Steven D'Aprano 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

Hello, Yes, Ctrl-L doesn't clear the screen on Windows. Making Ctrl-L clear the screen would be a good solution (no need for a clear screen command). Best regards, JM quinta-feira, 29 de Setembro de 2016 às 03:06:26 UTC+1, Steven D'Aprano escreveu:

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 _______________________________________________ Python-ideas mailing list Python...@python.org javascript: https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

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 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 javascript:>:

...

Hello,

Yes, Ctrl-L doesn't clear the screen on Windows. Making Ctrl-L clear the screen would be a good solution (no need for a clear screen command).

Best regards,

JM

quinta-feira, 29 de Setembro de 2016 às 03:06:26 UTC+1, Steven D'Aprano escreveu:

...

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 _______________________________________________ Python-ideas mailing list Python...@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python...@python.org javascript: https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, Sep 29, 2016 at 7:08 AM, Stephan Houben wrote:

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.

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.

Hello, You must have pyreadline installed (it isn't installed in the default CPython distribution). Best regards, JM On 29-09-2016 08:56, Stephan Houben wrote:

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 mailto: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 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 :

Hello,

Yes, Ctrl-L doesn't clear the screen on Windows. Making Ctrl-L clear the screen would be a good solution (no need for a clear screen command).

Best regards,

JM

quinta-feira, 29 de Setembro de 2016 às 03:06:26 UTC+1, Steven D'Aprano escreveu:

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 _______________________________________________ Python-ideas mailing list Python...@python.org https://mail.python.org/mailman/listinfo/python-ideas https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python...@python.org https://mail.python.org/mailman/listinfo/python-ideas https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ http://python.org/psf/codeofconduct/

On Thu, Sep 29, 2016 at 7:12 AM, João Matos 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 Tue, Oct 4, 2016 at 2:22 PM, Random832 wrote:

On Wed, Sep 28, 2016, at 23:36, Chris Angelico wrote:

...

On Thu, Sep 29, 2016 at 12:04 PM, Steven D'Aprano 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.

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.

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.

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).

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

...

"Bash on Ubuntu on windows" responds to CTRL+D just fine. I don't really know how it works, but it looks like it is based on the Windows terminal emulator.

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)

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