On 2 June 2014 14:03, Stephen J. Turnbull email@example.com 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 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.
-- Nick Coghlan | firstname.lastname@example.org | Brisbane, Australia