I have two areas of questions about updating turtle.py. First the module itself, then a turtle tracker issue versus code cleanup policies.
A. Unlike most stdlib modules, turtle is copyrighted and licensed by an individual. '''
# turtle.py: a Tkinter based turtle graphics module for Python
# Version 1.1b - 4. 5. 2009
# Copyright (C) 2006 - 2010 Gregor Lingl
# email: firstname.lastname@example.org
''' I am not sure what the copyright covers other than the exact text contributed, with updates, by Gregor. It certainly does not cover the API and whatever code he copied from the previous version (unless that was also by him, and I have no idea how much he copied when reimplementing). I don't think it should cover additions made by others either. Should there be another line to cover these? '''
# Permission is granted to anyone to use this software for any purpose,
# including commercial applications, and to alter it and redistribute it
# freely, subject to the following restrictions:
# 1. The origin of this software must not be misrepresented; you must not
# claim that you wrote the original software. If you use this software
# in a product, an acknowledgment in the product documentation would be
# appreciated but is not required.
# 2. Altered source versions must be plainly marked as such, and must not be
# misrepresented as being the original software.
# 3. This notice may not be removed or altered from any source distribution.
''' As to point 2, the source has been altered a bit (by others) but it is not marked as such. How should it be? ''' _ver = "turtle 1.1b- - for Python 3.1 - 4. 5. 2009" ''' Obsolete; delete or alter (how)?
When this replaced the previous turtle.py, it was considered 'owned' by Gregor in that changes had to go through him. However, he became inactive soon after and maintenance ceased. There has been only one turtle-specific code change that I know of (by Ned Daily, a month ago, for OSX. So is turtle.py unpatchable by anyone or fair game for anyone?
A particular example: Gregor added intermediate layers to isolate turtle from tkinter. (He had a plan to add other backends, but I believe he abandoned that.) If someone wanted to reduce the layering and make the code easier to understand and maintain, while speeding execution, would that be allowed now?
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.
Responding today, I cautioned that clean-up only patches, such as she apparently would like to start with, are not in favor. But I cannot say how the policy applies to her proposal. Does the 'promise' of later work on the code make preliminary clean-up ok?
Since she only marked the issue for 3.5, I also cautioned that 3.5-only cleanups would make fixing bugs in other issues harder. Is the code clean-up policy the same for all branches?
Test? you ask?. There are apparently no unittests for turtle. On the other hand, turtledemo tests the overall function of the module and of many (most) of the top-level turtle functions.
-- Terry Jan Reedy