[Python-Dev] Updating turtle.py

[Raymond Hettinger]

On May 30, 2014, at 8:32 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> B. Lets assuming that turtle.py is, at least to some degree, fair game for fixes and enhancements. PSF Python PyLadies (Jessica Keller, Lynn Root) are participating in the 2014 GNOME Outreach Program for Women (OPW) https://wiki.python.org/moin/OPW/2014 . One of the projects (bottem of that page) is Graphical Python, in particular Turtle.
> 
> A few days ago, Jessica posted
> http://bugs.python.org/issue21573 Clean up turtle.py code formatting
> "Lib/turtle.py has some code formatting issues. Let's clean them up to make the module easier to read as interns start working on it this summer." She want to follow cleanup with code examination, fixes, and enhancements.

If these modules are going to change (and Gregor gives us the go-ahead), I suggest we do real clean-ups, not shallow pep8/pylint micro-changes.   

I use these modules as part of a program to teach adults how to teach programming to children.  I've have good success but think the code for several of the modules needs to be simplified.  At some point, kids wrote some of this code but along the way it got "adultified", making it less useful for teaching younger kids.

I would like to be involved in helping to improve these modules in a substantive way and would be happy to coach anyone who wants to undertake the effort and bring a useful patch to fruition.

One thing I would not like to see happen is telling interns that their time is being well spent by pep-8 checking code in the standard library.  It sends that wrong message about what constitutes an actual contribution to the core.  There are plenty of useful things to do instead (we have an "easy" tag on tracker to highlight a few of them).

Another thought is that there are tons of python projects that could use real help and those would likely be a better place to start than trying to patch mature standard library code (where the chance of regression, code churn, or rejection is much higher).

Over the past few years, I've taught Python to over three thousand programmers and have gotten a number of them started in open source (a number of them are now active contributors to OpenStack for example), but I almost never direct them to take their baby steps in the Python core (unless they've found an actual defect or room for improvement).  It's a bummer, but in mature code, almost every idea that occurs to a beginner is something that makes the code worse in some way -- that isn't always true but it happens often enough to be discouraging.


Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140601/fed625f8/attachment.html>