Move Demo/turtle under Lib/ #54408
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee = 'https://github.com/abalkin' closed_at = <Date 2010-11-01.17:43:29.070> created_at = <Date 2010-10-26.15:48:54.253> labels = ['type-feature'] title = 'Move Demo/turtle under Lib/' updated_at = <Date 2010-11-01.17:43:29.069> user = 'https://github.com/abalkin'
activity = <Date 2010-11-01.17:43:29.069> actor = 'belopolsky' assignee = 'belopolsky' closed = True closed_date = <Date 2010-11-01.17:43:29.070> closer = 'belopolsky' components = ['Demos and Tools'] creation = <Date 2010-10-26.15:48:54.253> creator = 'belopolsky' dependencies =  files = ['19380', '19386'] hgrepos =  issue_num = 10199 keywords = ['patch'] message_count = 15.0 messages = ['119612', '119613', '119616', '119617', '119619', '119620', '119623', '119628', '119635', '119637', '119674', '119718', '119725', '120139', '120145'] nosy_count = 10.0 nosy_names = ['gvanrossum', 'georg.brandl', 'rhettinger', 'terry.reedy', 'glingl', 'belopolsky', 'gregorlingl', 'ned.deily', 'eric.araujo', 'r.david.murray'] pr_nums =  priority = 'normal' resolution = 'accepted' stage = 'resolved' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue10199' versions = ['Python 3.2']
The text was updated successfully, but these errors were encountered:
On Tue, Oct 26, 2010 at 11:18 AM, Guido van Rossum <firstname.lastname@example.org> wrote:
-- "Move Demo scripts under Lib"
Before I prepare a patch, I would like to get an agreement on the location of the demo package. In the order of my preference:
Note that while I listed conversion of turtle.py to a package as a cons, it may not be a bad idea on its own. For example, toolkit abstraction naturally belongs to submodules and procedural interface belongs to package level while OOP classes may be separated into submodules. While I am not proposing any such changes as a part of this ticket, it may not be a bad idea to take the first step and rename turtle.py to turtle/init.py.
IMO converting turtle.py into a package, unless that's already planned anyway, is not a good project to undertake right now. (OTOH the demo itself already is a package, less an __init__.py file.) Note that the turtle module already runs some demo when invoked as a script -- maybe this can be made to fire up the demo viewer instead?
On Tue, Oct 26, 2010 at 12:00 PM, Guido van Rossum
What are your reasons? I don't necessarily disagree, but want to
Unfortunately it also relies on being run from directory containing
Yes, I wanted to do that as well. Note that in this case, it would be
$ python -m turtle.tdemo_chaos $ python -m turtle.demo.chaos $ python -m turtledemo.tdemo_chaos ...
I would like Gregor Lingl's approval of turning turtle.py into a package. It might make some things harder for novices, e.g. trackebacks and just browsing the source code.
Also many people don't expect to find any code in a file named __init__.py (and most of the time I agree with this). But the alternative isn't so great either, assuming we'll want strict backwards compatibility (I wouldn't want the instructions in Gregor's or anyone's book to start failing because of this). You can't rename turtle to turtle/turtle.py either, because then there'd be horrible confusion between turtle/ and turtle.py.
IOW, yes, flat still seems better than nested here!
On Tue, Oct 26, 2010 at 12:31 PM, Guido van Rossum
Me too. :-) I added him to the "nosy list".
If better tracebacks were the goal, I would start with removing
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1, in forward .. TypeError: can't multiply sequence by non-int of type 'float'
Browsing source code may indeed be complicated by the package
Well, logging, tkinter, and ctypes are clearly counterexamples to this rule.
Backwards compatibility can be restored by use of relative imports as
Agree. We have too many turtles already. :-) On the other hand,
For a six year old, turtledemo is still nested - just without a dot. :-)
PS: My six year old loves the turtle!
I thought this email-to-roundup bug was fixed some time ago. The mangled sample session was:
>>> turtle.forward('5 miles') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1, in forward .. TypeError: can't multiply sequence by non-int of type 'float'
Just an FYI: the python.org installers for Mac OS X install the demos including the turtle demo (which is probably the most useful of the bunch these days) in /Applications/Python m.n/Extras/Demo. Depending on the default application association for ".py" files (something the user can change using the OS X Finder), double-clicking on the demo files will generally launch them in IDLE.app or with Python Launcher.app.
I usually expect things in stdlib to be usefully importable. Idlelib is clearly an exception.
I think it a mistake that tkinter.__init__ is huge, about as big as the other 13 modules added together. It makes it really hard to dive into the code.
I think turtledemo would be fine, separate from turtle, if one could import and run things (one at a time) from within the interactive interpreter.
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.
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:
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
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.
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
Attached patch, bpo-10199.diff is mostly a copy of Gregor's turtledemo32.zip, with the main difference being that viewer code is in turtledemo/main.py so it can be run with just
$ python -m turtledemo
I would like to commit this before any further improvements. Just as Gregor, I have many ideas on how to improve the demo, but implementing them would be a subject of a new ticket.
Here is a quick list:
Imho it is very important to clarify the name convention for demoscripts to be added to the demo before committing (or at least before the apperance of beta1). It decides about adding scripts to the Examples Menu of the viewer.
We all know, that things once they have found their way into Lib cannot be changed easily afterwards. Guidos argument on backwards compatibility applies. So now is the only point in time to decide about this.
Please note that there are other constraints also for demo_files anyway, like the size of the graphics window and the presence of a main()-function to be called by the viewer.
I'd like this to be decided actively.
What do you think?
On Wed, Oct 27, 2010 at 2:37 PM, Gregor Lingl <email@example.com> wrote:
I would rather separate move under Lib and any other changes. However
I don't really expect people to import turtledemo.xyz modules in their
In the long run, I would like to add a separate template that will