This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, eric.araujo, glingl, gregorlingl, gvanrossum
Date 2010-10-26.17:05:51
SpamBayes Score 5.407341e-13
Marked as misclassified No
Message-id <AANLkTinqKt1DkZ-c0ZVYAZDxmwYaJ+L4pvw852R0X_y=@mail.gmail.com>
In-reply-to <1288110692.31.0.0560369831336.issue10199@psf.upfronthosting.co.za>
Content
On Tue, Oct 26, 2010 at 12:31 PM, Guido van Rossum
<report@bugs.python.org> wrote:
..
> I would like Gregor Lingl's approval of turning turtle.py into a package.

Me too. :-)  I added him to the "nosy list".

>  It might make some things harder for novices, e.g. trackebacks and just browsing the source code.

If better tracebacks were the goal, I would start with removing
eval-generated module level functions:

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
structure.  For example, I often find it difficult to navigate
unittest code once it became a package in the recent versions.
However, simple renaming of turtle.py to turtle/__init__.py is
probably a non-event since novice-oriented environments such as IDEs
are likely to take the user directly to turtle/__init__.py when he or
she clicks on "turtle".

> 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).

Well, logging, tkinter, and ctypes are clearly counterexamples to this rule.

>  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).

Backwards compatibility can be restored by use of relative imports as
necessary.  This is the unittest approach where backward compatibility
is paramount.

> You can't rename turtle to turtle/turtle.py either, because then there'd be horrible confusion
> between turtle/ and turtle.py.

Agree.  We have too many turtles already. :-)  On the other hand,
moving turtle object definitions into turtle/pen.py in some distant
future may not be a horrible idea.  (Note that "pen" end "turtle" are
already mostly synonymous.)

> IOW, yes, flat still seems better than nested here!

For a six year old, turtledemo is still nested - just without a dot. :-)

PS: My six year old loves the turtle!
History
Date User Action Args
2010-10-26 17:05:54belopolskysetrecipients: + belopolsky, gvanrossum, glingl, gregorlingl, eric.araujo
2010-10-26 17:05:53belopolskylinkissue10199 messages
2010-10-26 17:05:51belopolskycreate