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
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>
Python-bugs-list mailing list

Reply via email to