On Fri, Nov 5, 2010 at 1:18 PM, Éric Araujo <report@bugs.python.org> wrote:
..
> nosy: +eric.araujo

Raymond has already rejected and closed this request, so I am not
optimistic that anything will happen here.  (I also understand that he
feels rather strongly about this because he closed the issue in just 5
hours!)

Nevertheless, let me answer Raymond's arguments for historical records:

> It's better as a demo for cmd than as a useful utility for the turtle module.

While I agree that TurtleShell is an excellent demo for the cmd
module, I find ReST files a poor place for example code, especially
multipage code like TurtleShell.   We do not have a procedure for
testing code presented in ReST files and such code regularly goes out
of date unnoticed.

At a minimum, I would like to see TurtleShell code moved into its own
file under Doc/includes/ and embedded in Doc/library/cmd.rst  using

.. literalinclude:: ../includes/turtleshell.py

directive.  See datetime.py and tzinfo-examples.py as an example of
this approach.

Doing so will help users that want to study TurtleShell code by
running and editing to get a working .py file.  (Sphinx can actually
make it even easier by supplying and easily accessible download link
for literalincludes.)

This will still not solve the problem of untested code in the manual,
but I this is a more general issue.  See #10225, for example.

> Also, we want people using turtle to learn Python, not to bypass the language altogether.

I agree and I can clearly see this a slippery slope before someone
would want to expand TurtleShell into a full-featured Logo
interpreter.  As it stands, however, I don't see a problem in letting
users command the turtle without twisting their fingers to enter
superfluous commas and parentheses.  (Remember, the target audience
may not even have full command of the shift key yet.)  We can also
teach TurtleShell to save history as a python program which will help
them to learn python.