[Python-Dev] Updating turtle.py

[Nick Coghlan]

On 2 June 2014 14:03, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 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 at gmail.com   |   Brisbane, Australia