This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients Ramchandra Apte, Torgil Svensson, amaury.forgeotdarc, asvetlov, ideasman42, kbk, larry, ned.deily, python-dev, rhettinger, roger.serwy, terry.reedy
Date 2015-08-24.17:04:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1440435889.53.0.330095102408.issue16123@psf.upfronthosting.co.za>
In-reply-to
Content
Torgil, thank you for the interesting feedback. I will respond to your four paragraphs slightly out of order.

1. Starting Idle with '-n', I verified that running 'print(a)' from the editor works after entering 'a=1' in the shell. The intended purpose of the editor is to edit files that run as is.  From this viewpoint, the carryover behavior is a bug.  Idle's original single process mode, now accessed with -n, only remains because communicating with a subprocess via sockets turns out to be a bit unreliable.

3. Using an editor as a extension of the shell is an alternate use.  It does not have to be tied to -n.  I have been thinking about alternate run modes and added 'run as input' to my list.  A useful version might be this: don't require a name for the editor buffer; don't restart; enter each statement at a prompt and run as if typed.  The latter would make all the code run in Shell visible and add each statement to the history list.

2. I am a bit puzzled by your matlab comment. When tkinter code is run from editor in a separate process, it successfully grabs keyboard and mouse input.  (One of the reasons for the shift from 1 to 2 processes was to disentangle user tkinter guis from the Idle tkinter gui.) On the other hand, running
  import msvcrt; k = msvcrt.kbhit()
on Windows does not work with either 1 or 2 processes because the Idle gui retains input focus.

If you want to pursue this, please open a new issue on the tracker or post to the idle-sig list or its news.gmane.org mirror gmane.comp.python.idle. In either case, say more about what 'not work' means.

4.This issue was opened before PEP 434 and before 2.7 maintenance was extended from 5 years (expiring now as 3.5 is released) to 10 years.  Hence the deprecation notice was not added to 2.7. I do not expect this to change.
History
Date User Action Args
2015-08-24 17:04:49terry.reedysetrecipients: + terry.reedy, rhettinger, kbk, amaury.forgeotdarc, larry, ned.deily, roger.serwy, asvetlov, ideasman42, python-dev, Ramchandra Apte, Torgil Svensson
2015-08-24 17:04:49terry.reedysetmessageid: <1440435889.53.0.330095102408.issue16123@psf.upfronthosting.co.za>
2015-08-24 17:04:49terry.reedylinkissue16123 messages
2015-08-24 17:04:48terry.reedycreate