[Python-Dev] Updating turtle.py

"Martin v. Löwis" martin at v.loewis.de
Sat May 31 20:05:55 CEST 2014


Am 31.05.14 05:32, schrieb Terry Reedy:
> 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: glingl at aon.at
> '''
> 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?

He should provide a contributor form, covering his past contributions.
Would you like to contact him about this?

Adding a license up-front (as you propose) is counter-productive; the
author may not agree to your specific licensing terms. If he was
unwilling to agree to the contributor form (which I doubt, knowing
him personally), the only option would be to remove the code from the
distribution.

> _ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"
> '''
> Obsolete; delete or alter (how)?

Delete. It's a private variable, and the true version number is
maintained by Mercurial, and not in the code itself (or else is the
version of Python it ships with).

> 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?

It would be good if there would be a new maintainer of the module. Maybe
Gregor would be willing to reactivate his contributions when asked,
maybe he would be willing to hand it over to somebody else. A maintainer
would have the ultimate say in architectural changes.

Without a maintainer, I'd rather not make architectural changes.

> Responding today, I cautioned that clean-up only patches, such as she
> apparently would like to start with, are not in favor. 

I would not say that. I recall that I asked Gregor to make a number of
style changes before he submitted the code, and eventually agreed to the
code when I thought it was "good enough". However, continuing on that
path sounds reasonable to me.

It is the mixing of clean-up patches with functional changes that is not
in favor.

> 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?

I don't think that we should be taken hostage by merging restrictions
of the DVCS - we switched to the DVCS precisely with the promise that
merging would be easier. Given the number of bug fixes that the turtle
module has seen, I'd suggest that it is less work to restrict cleanup
to 3.5, and then deal with any forward-porting of bug fixing when it
actually happens.

Regards,
Martin



More information about the Python-Dev mailing list