Terry J. Reedy <tjre...@udel.edu> added the comment:
Deprecation has been done and a message is printed under the splash screen. With 5 more years of maintenance experience under deprecation, I have not experienced -n mode as a maintenance burden. So I have no inclination at present to remove it (or even implement any of the ideas above). Deprecation usually means 'no maintenance'. For idlelib, that means no new tests specifically for -n mode (and there never were any). I don't do manual tests either. (More patches and more testing in regular mode is more important to me.) It is possible that some feature has been disabled in that mode, but there are no such reports and I have not encountered anything in my occasional experiments in that mode. (Such as when someone claim that something only worked with -n.) I have occasionally touched blocks with 'if subprocess ... else ...' but it has not been hard to leave the else part alone. A year or so ago, I added a 'Startup failure' section to the IDLE doc. It list multiple possible causes and things to try. -n is irrelevant to most of them. If someone knows of another current issue, open a new tracker issue. ---------- dependencies: -Idle: use pipes instead of sockets to talk with user subprocess resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue16123> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
