[Python-Dev] Updating turtle.py
Terry Reedy writes: > As to point 2, the source has been altered a bit (by others) but it is > not marked as such. How should it be? I would suggest adding """ Based on turtle 1.1b for Python 3.1 (4.5.2009) by Gregor Lingl. This is a revised version including changes from the Python community. Change history is available from the Python repository: . """ Including the URL is questionable as updates are likely to be overlooked if the repo should ever move. Including the first sentence is a matter of taste. > ''' > _ver = "turtle 1.1b- - for Python 3.1 - 4. 5. 2009" > ''' > Obsolete; delete or alter (how)? Delete definition and references, or replace with more generic wording, I think. E.g., '_ver = "turtle for Python 3"'. It's a pain to maintain as is. It's not information for determining copyright, so is covered by Gregor's permissive license. > 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? Legally, it's fair game. Socially, it's a matter of project policy. AFAICT Python policy is that someone should ask Gregor (a precedent is the Fredrik Lundh/ElementTree case). AIUI, there's been a five-year span since Gregor's been active, so I would think it's basically a matter of courtesy. Most likely he's not interested in returning as maintainer, or he can't be contacted with reasonable effort. Then it's open to anyone. If he's interested in maintaining control but obstructive toward third party contributions, that's messy but in the end the PSF, or its delegates, as owners of the repo have legal control, and social legitimacy to exercise it as seems best for the project. If the PSF does "go over Gregor's head" to open up the file in trunk for modifications, the wording above might want to change to "This fork includes changes from ...". An alternative would be to fork into a new module with a different name. That can be done at any time, with the only downsides being redundancy and potential bad will between Python and Gregor Lingl. > 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. I don't think there is any issue at all here. Legally there's no barrier at all to working on Turtle or pushing changes anywhere. Socially, there's no barrier to anything but pushing to release branches (including trunk). To the extent that OPW (GSoC, etc) requires integration with the parent project, they can push to a hg.python.org branch pending clarification of the maintainership issue. Best of all, you've identified volunteers for searching for Gregor! IMHO YMMV Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Language Summit Follow-Up
Chris Barker writes:
> that way. Saying that their very first easy program is:
>
> print("hello world")
>
> is fine
I have had similar experience on a small scale.
Also I've been teaching R recently. The students who know Python
(Python 3, we don't have backward compatibility issues in our work)
got the concept that all "real work" in R is done by functions,
immediately. Those who don't, have trouble with the concept that
"help" and "q" (for "quit") need parentheses to get them to work.
Unfortunately R doesn't have Python's Easter Eggs, so they get a code
dump rather than help when they type the bare names.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updating turtle.py
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: [email protected] > ''' > 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 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updating turtle.py
Am 31.05.14 10:09, schrieb Stephen J. Turnbull: > AFAICT Python policy is that someone should ask Gregor (a precedent is > the Fredrik Lundh/ElementTree case). AIUI, there's been a five-year > span since Gregor's been active, so I would think it's basically a > matter of courtesy. Most likely he's not interested in returning as > maintainer, or he can't be contacted with reasonable effort. I would not be so sure about this, see http://python4kids.net/turtle.html Regards, Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updating turtle.py
On 5/31/2014 2:05 PM, "Martin v. Löwis" wrote: 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: [email protected] ''' 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? Thank you for the advice. I emailed him about contributor form, change notice in the file, and maintenance. 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. 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. I am not sure what you mean by 'that path', to be continued on. It is the mixing of clean-up patches with functional changes that is not in favor. What I have understood from Guido is that 'blind' format changes, not part of working on the file, are not good as they could cause harm without direct benefit. On the otherhand, you are saying that if the code is reviewed, then the format changes should be separate, possibly with a commit note that they are not 'blind'. 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, which is miniscule in the last few years... I ran differ on the 3.4 and 3.5 versions of turtle.py and did not see any differences. So at the moment, forward porting is trivial. 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. This would make it non-trivial for any patch hitting a difference. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
