Gregor Lingl <gregorli...@users.sourceforge.net> added the comment:
First of all: I'd not like to see turtle.py converted into a package. I think
with the turtle module things should be as simple as possible and I don't see
any need to put approx. 100kB of code into an __init__.py and be it only
because there are hundreds of them and on cannot see from the name what's in
there. I do not expect the avarage turtle user to look at the code, but
certainly some teachers and instructors do even if they are not python
specialists accustomed to the use of packages.
As far as I understood from the discussion the MAIN POINT is to make the
turtleDemo accessible as easyly as possible.
So at first this needs a decision to put the demo code into the
Windows-Distribution.
The next question is where to put it. In my opinion there are two possibilities.
1) The one mentioned by Alexander in msg119612: a turtledemo directory in Lib.
2) To put a turtledemo directory into the Tools directory (in some sense the
demoViewer is sort of a tool, isn't it.)
I quickly prepared a 'prototypical' collection with a modified viewer, which
accounts for some of the arguments which came up in the current discussion. It
contains a turtledemo package. Please download it and have a look.
Each demo can be run by doubleclicking, as a standalone script, as well as from
the turtledemo.viewer
If from the above options 1) were chosen or the package is somewhere else in
the search path, on can - at the interactive prompt - do things like:
>>> from turtledemo import bytedesign
>>> bytedesign.main()
and also:
>>> from turtledemo import viewer
>>> viewer.run()
Morover one can load the examples into Idle and start them via the run-command.
So one has a look at the code and moreover the possibility to make changes and
try out, what happens.
I have renamed the sample scripts, omitting the tdemo_ - prefix, as
this looks nicer (at least for me). The previous version turtleDemo recognized
scripts with this suffix as belonging to the demo-suite and
added it to the examples menu. This was necessary because of a script, which
cannot be demonstrated in the demo_viewer (two canvases). I changed this in my
proposition in the following way: scripts that are in the demodirectory and
should not appear in the DemoViewer's example-Menu, should end with _.py or
some other extension.
To make the demo_viewer importable creates a special problem: the demos are
imported by the demoViewer via the __import__ function, so everyone can add his
own demos to the demo-directory and they will show up in the viewer. The
original version (and even this one) can do this also for demos in
subdirectories when started directly. (I've included as an example the geometry
directory). This does't work yet for importing the viewer, I only provided a
very clumsy quick and dirty solution and I hope that someone has a better, more
bright idea to do this more elegantly and correctly.
Now for something completely different: how to make it easily accessible.
1) Put remarks (and links) into the documentation, near the head of the turtle
module's docs. (Referring to 24.5.7)
2) Put a hint into the commentary/docstring of the file turtle.py itself.
3) I do not consider it a good idea to put the viewer.py into the
if __name__ == "__main__" - part of turtle.py thus replacing the current demo.
I think this part should demonstrate the possibilities of the module without
recurring to extra use of Tkinter (as the demo viewer does). (I must also
confess, that the quality of the code of the viewer, which I programmed back in
2006, does not reach the standards I tried to achieve for turtle.py)
4) BUT I'd find it useful to change this final demo code of turtle.py, so it -
in the end - displays a message where to find more demos (i. e. turtledemo) or
even to put there a question like ("Do you want to see more demos?") and two
"turtle-generated" "buttons": "YES" and "NO". If one chooses "Yes", the
turtledemo.viewer would pop up in a separate process.
Please consider this to be a proposal or a contribution. I'm very interested in
discussing it further and bringing it to a quick and easy solution for Python
3.2. Unfortunately I'm currently involved in a project (also python-related)
with very severe time constraints for the next four to five month. So ideas for
enhancing the demoviewer and probably turtle.py have to wait until then and
possibly will be an issue for Python 3.3
Best regards,
Gregor
----------
Added file: http://bugs.python.org/file19380/turtledemo32.zip
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
