My thoughts on this. Overall, +.something (and increasing as I look at it more ;-).

I am opposed to adding this to the relatively long file menu. It has nothing to do with manipulating or editing files. If it is to go in, please put it on the help menu, at least for now, as the intention is to somehow help beginners. If we ever add a demo section or submenu to the Help menu or Demo to the top-level level menu, we can move this.

Any patch should be applied to both 3.4 and 3.5. Turtledemo apparently does not exist in 2.7.

Idle NEWS items first go into the Idle section of the regular NEWS file. They are supposed to be copied into the idlelib/NEWS with each release. That has sometimes happened but not always. (I should open separate issue to fix both the idlelib files and the procedure.) In any case, NEWS entries should not be added to a patch until it is about to be committed. Otherwise, merge conflicts are possible or even likely.

With the main code in turtledemo.__main__ wrapped in a function, we could pass an 'idle' argument so that the demo could modify its behavior when run from Idle. I mention a possibility below.

The patch runs turtledemo within the Idle process. It might be better to run it in a separate subprocess:
  python -c "from turtledemo.__main__ import main; main('idle')"
One reason, aside from not leaving all the imports around, is that 3 of the demos print to console.

* When clock is stopped, a traceback is printed; this in mentioned in a tracker issue (and should be fixed).
* Penrose prints each info about each round; this text could/should be put in a popup text window.
* Tree prints '1024'; this could be eliminated or put on the status bar under the text window, as another demo does.

When Idle is run windowless with pythonw on Windows, attempts to print to the non-existent console crash the process. There have been several bug issues about this. The current patch should not be pushed with turtledemo as is unless tested with installed 3.4.1 by hand-patching idlelib. Or, all console prints should be eliminated.

However, a future addition to turtledemo could create a problem. That is why I think it better that only idlelib code run within the idle process.

I am bothered a bit that there is little relationship between Idle and turtledemo. Both using tkinter seems not too relevant. That both tend to be used by less experienced Python users seems a bit thin. The relationship would be stronger if there were other demos (which I would like) or if there were option in the demo to load the code for a particular example into an Idle editor window. (Each demo will run independently in an Idle user process - text output, including tracebacks resulting from ungracefully closing an example before it is done, appears in the Shell window.)