Author terry.reedy
Recipients gvanrossum, markroseman, ncoghlan, ned.deily, serhiy.storchaka, terry.reedy
Date 2016-05-11.06:50:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In response to 1.  I considered copying idlelib as a whole as a serious possibility, meant to include it as an alternative, and am willing to reconsider my choice.  I specifically thought of something like idlelib3 or idlelib/idle3, but not _idlelib,  A complete copy in a new directory would be, as you say, a cleaner separation but it seemed like it would make import changes and startup more complicated.  It is also not obviously covered by PEP 434 -- unless you say so.

For users, making idle2 the copy would immediately break current external imports.  Making idle3 the copy would break new external imports sometime in the future.  But using _idlelib would warn of that possibility.

For importat, IDLE itself uses uses all of 'from idlelib import module', 'from idlelib.module import callable', 'from idlelib.idle_test.htest import run', and unittest.main('idlelib.idle_test.test_module' (but no relative imports).  A new directory would greatly increase the number of changes and mean changing 'idlelib' to 'something' now and 'something' back to 'idlelib' in the future.

I thought of using relative imports, but I have not used them and have read that they are limited, tricky, and discouraged.  I just did some experiments and it seems that they do not work when a file is run as __main__ instead of imported.  (Whatever the limitation, it is not obvious to me from the doc.)

I agree with 2. and 3. and will response to 4. in another message.
Date User Action Args
2016-05-11 06:50:24terry.reedysetrecipients: + terry.reedy, gvanrossum, ncoghlan, ned.deily, markroseman, serhiy.storchaka
2016-05-11 06:50:23terry.reedysetmessageid: <>
2016-05-11 06:50:23terry.reedylinkissue26993 messages
2016-05-11 06:50:22terry.reedycreate