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@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? ''' # 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
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:
''' _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! <wink/> IMHO YMMV Steve
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@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
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
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: glingl@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?
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
On May 30, 2014, at 8:32 PM, Terry Reedy
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
Raymond Hettinger writes:
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).
I have to ask for a qualification here, at least in the case of GSoC interns. Of course the intern should contribute to the code, but they are also supposed to become developers in the community. Spending a few hours checking code for PEP-8-correctness is useful training in writing good core code going forward. I agree with you that if they don't move on after a day or so, they should be told to do so. OTOH, I haven't yet met an intern who was willing and able to write in good PEP 8 style to start with, let alone one who was willing to "waste his time" doing style-checking on existing code -- is this really a problem? I agree that they should be told that this is an investment in *their* skills, and at best of marginal value to *Python*, of course. As you point out, directing them away from core code to other projects requiring PEP 8 in their style guides is usually a good idea, too.
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.
This is precisely why style-checking in the core may be a good idea for interns: assume the code is *good* code (it probably is), don't mess with the algorithms, but make the code "look right" according to project standards. The risk you cite is still there, but much less. It shows them what Pythonicity looks like at a deeper level than the relatively superficial[1] guidelines in PEP 8. Footnotes: [1] Not deprecatory. Consistent good looks are important.
On 2 June 2014 14:03, Stephen J. Turnbull
Raymond Hettinger writes:
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.
This is precisely why style-checking in the core may be a good idea for interns: assume the code is *good* code (it probably is), don't mess with the algorithms, but make the code "look right" according to project standards. The risk you cite is still there, but much less. It shows them what Pythonicity looks like at a deeper level than the relatively superficial[1] guidelines in PEP 8.
The problem from my perspective is that the standard library contains code where it's either old enough to predate the evolution of the conventions now documented in PEP 8, or else we declared some code (especially test code) "good enough" for inclusion because we *really* wanted the functionality it provided (the original ipaddr tests come to mind - I suspect that tracker issue is one of the specific cases Raymond is thinking of as well). Even if we had unlimited reviewer resources (which we don't), mechanical code cleanups tend to fall under the "if it ain't broke, don't fix it" guideline. That then sets us up for a conflict between folks just getting started and trying to be helpful, and those of us that are of the school of thought that sees a difference between "cleaning code up to make it easier to work on a subsequent bug fix or feature request" and "cleaning code up for the sake of cleaning it up". The latter is generally a bad idea, while the former may be a good idea, but it can be hard to explain the difference to folks that are more familiar with code bases started in the modern era where the ability to easily run automated tests and code analysis on every commit is almost assumed, rather than being seen as an exceptional situation. There's a reason the desire to "throw it out and start again with a clean slate" is a common trait amongst developers: green field programming is genuinely *more fun* than maintenance programming in most cases. I believe Raymond's concern (and mine) is that if the challenges of maintenance programming aren't made clear to potential contributors up front, they're going to be disappointed when their patches that might be fine for a green field project, or as part of the development of a particular feature or fix, are instead rejected as imposing too much risk for not enough gain when considered in isolation. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Am 01.06.14 00:21, schrieb Terry Reedy:
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.
The path of improving the coding style of the turtle module.
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.
Indeed. OTOH, it's simpler for anybody doing the code cleanup to do it only on one branch. Regards, Martin
Nick Coghlan writes:
Even if we had unlimited reviewer resources (which we don't),
Raymond said "interns". We at least have a mentor.
There's a reason the desire to "throw it out and start again with a clean slate" is a common trait amongst developers:
You mean the Cascade of Attention-Deficit Teenagers development model?
I believe Raymond's concern (and mine) is that if the challenges of maintenance programming aren't made clear to potential contributors up front,
So make it clear when the assignment is given. Remember, the point I'm making is that it's an investment for the intern, not for Python. If their code eventually gets relegated to a branch the may never ever get merged, that's a learning experience too -- they may have been told, and *thought* they signed up for that up front, but it's different when you actually get told, "it could be useful, but on balance let's not touch this code" or even "the 'owner' of the code doesn't have time to look at changes". It's not something I suggest as a "rite of initiation" for *all* interns. I just think it would be overkill to prohibit it in principle -- I have a couple of (non-Python) interns who would benefit from the exercise (their projects are greenfield code, so they have no "model code" to start from). It wasn't clear to me whether Raymond meant to go that far as a general prohibition. Regards,
On 6/2/2014 3:12 AM, Nick Coghlan wrote:
Even if we had unlimited reviewer resources (which we don't), mechanical code cleanups tend to fall under the "if it ain't broke, don't fix it" guideline. That then sets us up for a conflict between folks just getting started and trying to be helpful, and those of us that are of the school of thought that sees a difference between "cleaning code up to make it easier to work on a subsequent bug fix or
In the case of turtle, Jessica said from the beginning that code cleanup would be for the purpose of understanding the code and making it easier to do bug fixes and enhancements.
feature request" and "cleaning code up for the sake of cleaning it up".
As you know, many outsiders think that we take PEP 8 more seriously than we do. The latter is generally a bad idea, while the former may be a
good idea,
Lita seemed to quickly understand that being able to test a bug fix is more important than making it look pretty. In any case, I believe she is doing something else until we hear from Gregor or otherwise decide how to proceed with turtle.
but it can be hard to explain the difference to folks that are more familiar with code bases started in the modern era where the ability to easily run automated tests and code analysis on every commit is almost assumed, rather than being seen as an exceptional situation.
-- Terry Jan Reedy
participants (5)
-
"Martin v. Löwis" -
Nick Coghlan -
Raymond Hettinger -
Stephen J. Turnbull -
Terry Reedy