Terry J. Reedy <tjre...@udel.edu> added the comment: Stephen, I think *you* were the one over-anxious to be dismissive. In the title Marco refers to "Jupyter console (IPython)" features and in his opening, to "Jupyter console, aka IPython". Jupyter Console is, I read, QT based. IPython/Jupyter Notebooks are GUI-based also.
However, I agree that single process terminal IPython, such as illustrated near the top of https://ipython.readthedocs.io/en/stable/index.html is the better reference for comparison. As pictured, it requires a color terminal with full screen edit. An important constraint is that instead of users talking to the UI program with menu clicks, they must use "‘magic’ commands" entered after the '>>>' prompt instead of code. Guido specifically vetoed the idea of allowing these into IDLE, so he must not want them in the REPL either. Skipping the rest of your post, I will just restate why I closed this issue. 1. It introduces too many features not directly related. The existing unix-only completions uses two modules. I suspect some of the other features would also need new modules. (But Marco, please don't rush to immediately open 8 new issues.) Furthest removed, no new module needed: Adding builtins that can be used in REPL as it is. I suspect the answer to that proposal would be to use a PYTHONSTARTUP module with code such as "import pprint as _; pprint = _.pprint" 2. It introduces policy issues that might require a policy change, and that I think should better be discussed on, say, pydev. Steven and I have obviously gotten different policy impressions from Brett and Guido respectively. I will try to ask on pydev what the current REPL feature policy is, and what people think it should be. For instance, how far do we want to go is adding features that only work on a subset of systems? 3. I believe that some of the concrete proposals have even more implementation problems than Marco himself acknowledged. Difficult does not mean prohibited, but coredevs are mostly not interested in working on UIs and it has been Guido's stated-to-me policy that 'advanced' UI/IDE features (not defined) should be left to other projects. One communication problem is that once python is running in interactive mode, the only thing the user can send to it is lines of Python code. Consider pasting multiline code with blank lines. The console feeds pasted lines *1 at a time* to interactive Python, the same as if the user typed them. So Python does not know if they were typed or pasted. Nor does it know that there might be a next line already waiting, and if so, what it is (dedented?). If it does not execute on receiving '\n', when will it? There are also communication issues in the other direction. When REPL sends a prompt, everything up to and including a prompt is somehow marked read-only. But autoindents must be left erasable so a user can dedent. If that can be solved, including on Windows, I would like IDLE's autoindent code moved to an stdlib module (and polished, if need be) to be used by REPL, IDLE, and anyone else who wishes. The main function would map a sequence of lines to a PEP-8 compliant indent for the next line. Syntax-coloring opens a much bigger can of worms. It requires full screen editing to overwrite existing input. It also needs to be configurable as part of a configuration system. IPython requires the user to write "a dictionary mapping Pygments token types to strings defining the style." in a python file with other needed code in a place where IPython can find it. IDLE lets one modify an existing scheme by clicking on an element in sample code and then a new color and let IDLE handle the storage. Marco, you said "I *really* hope that IDLE is simply a GUI wrapper of REPL". Nope. In a single process, python cannot simultaneous execute a file in batch mode and input lines in interactive mode. IDLE uses "exec(code, simulated_main_namespace)" and I suspect other simulated shells do something similar. An advantage is that 'code' can represent complete multiline statements or even an entire module. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38747> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
