[Python-Dev] tracker contribution (original) (raw)

Mark Lawrence breamoreboy at yahoo.co.uk
Sun Jul 18 20:43:53 CEST 2010

On 18/07/2010 15:34, Antoine Pitrou wrote:

Hello Mark, On Sun, 18 Jul 2010 00:45:09 +0100 Mark Lawrence<breamoreboy at yahoo.co.uk> wrote: On 17/07/2010 22:57, Terry Reedy wrote:

On 7/17/2010 8:41 AM, Mark Lawrence wrote:

IIRC Terry Reedy is also interested in moving IDLE forward. Interested, yes. But until either a) I can commit patches, or b) there is someone who will respond to commit review recommendations with "No, here is why not" or "Yes, committed", I will work on other issues, such as doc issues, for which I can get responses. I am certainly reluctant to recruit others to help, as I did for #9222, if there will be no action indefinitely. This is standard Python behavour. The worst case I've come across is a patch that dated back to 2001 that had not been dealt with. But I'm staggered as to how a third party supplies a patch for (say) 2.3, it doesn't get applied, then the issue tracker simply keeps updating the version targeted until we're now at 3.2. That of course doesn't mean that anything will get done, better wait until py4.7? My approach is very simple, maybe even ruthless, but in the long term I believe it's better for everybody. Does this patch stay open, yes or no? At least it gets the mind focused. Some people have complained at me about my approach. Others have said great job. Obviously there's no correct or incorrect way, there's nowt as queer as folk. Well, I would still encourage you to adopt a different approach. Simply bumping up bugs without adding any useful content to the discussion does not help much. Especially if you do so several times in a day, because it increases a lot the bandwidth of messages we have to deal to. And, given we have a limited amount of time and cognitive capacity to devote to Python (we're all volunteers), that means we either spend a lot of time reading your messages and context switching between several issues per day, or start filtering out your messages in order to stay focussed. And if we start doing the latter, it means you are just wasting your own time. It would be IMHO much more useful if you concentrated on a couple of issues which interest you, or which you feel competent in, and where you either: - produce a review of a posted patch - post a patch yourself - give suggestions as to how the issue could be solved (or, alternatively, explain why it is detrimental, or useless, or too late (etc.) to solve the issue) - ask questions to the original submitter if things seem fuzzy It is especially useful if you manage to produce a negative review, that is point out something wrong with the patch/issue. Things that can get wrong with a patch (non-exhaustive list follows): - the patch doesn't apply cleanly anymore (on the py3k or 2.7 SVN branch, depending on whether the issue regards 3.x or only 2.x) - the proposed solution breaks compatibility in an obvious or subtle way - the patch lacks unit tests - unit tests don't adequately test behaviour (too strict, too laxist, too fragile, etc.) - portability problems, i.e. patch wouldn't have guaranteed or proper behaviour on all platforms - inconsistent or improper coding style - performance problems on arguably performance-critical code - undesireable side effects - etc. I would stress that this kind of involvment would also be able to get you much higher on the learning curve than your current involvment does: i.e., non-trivial contributions will build the competences to improve both yourself (assuming that's something you're interested in) and the complexity, correctness and completeness of your future contributions. Which in the middle-term is generally quite gratifying. Regards Antoine. I'm extremely offended by your comments. I'll just back off and let the number of outstanding bugs grow and grow and grow, until such time as people get fed up with Python and go to (say) Ruby.

Kindest regards.

Mark Lawrence

More information about the Python-Dev mailing list