Why are unified diffs only "grudgingly" accepted?

[Guido van Rossum]

cg at gaia.cdg.acriter.nl (Cees de Groot) writes:

> Thomas Wouters  <thomas at xs4all.net> said:
> >I think you're being very unfair to Guido and the others who
> >do most of the work on Python: the difference between sending in a context
> >diff and a unified diff is *one character* in a command line, and they *do*
> >accept unified diffs. 
> 
> I think the poster had a point. It's hard to keep a tab on what sort of
> diffs everybody wants.

Which is why I publish my preferences *and* accept other reasonable
patch formats too.  (And yes, for me unified diffs are harder to read
than context diffs, and that's all there is to that particular
preference.)

> Furthermore, I think it is rude, as a software
> developer, to reject patches because of format nitpicking (yes, I do
> develop open source software so I know that part of the game). The people
> who made the patch did a lot of work for you (as y'all know, a one-liner
> patch can be the result of hours and hours of work), and converting
> between diff type A and diff type B, even without specialized tools,
> is as simple as "patch ...; cvs diff".

*If* the patch applies cleanly.  If it applies cleanly, I usually
don't complain; but if it doesn't, the patch goes back whether it's a
context diff or not.

I should add that while I get lots of patches that indeed save me
hours, sometimes days, of work, I also get lots of patches that don't
work or attempt to introduce an undesirable change.  Having to say no
half of the time is no fun!  It's easier to reject a patch that's also
poorly formatted than one that at least shows that the submittor did
his homework, so if you want me to look at your patch carefully,
taking care of the formatting helps!  It's the same argument really as
the value of correct spelling in a resume.

> A good patch starts with a blob of text "selling" the contents of the
> patch to the code owner anyway. A good story is far more important than
> format A, B or C. The burden on the contributor is to provide a good story
> and a working patch.

Very well put!

> The burden on the maintainer is to try to give the
> patch a fair judgement. Both parties invest a lot of work, so I don't
> see a reason at all for one of the parties kicking the other one around.

Sure.  But the typical patch submittor has one patch to work on.  I
have to review everybody's patches.  (Well, I used to.  Fortunately
the python-dev crowd is helping out.  Still, there's more of you than
there are of us.)  So please accept our apologies if a review seems
curt.  We're trying to save time so we can handle more good patches.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)