@Tim: was it your intention that difflib track gnu diff?

I am on the fence with this issue. Without input from Tim other than the doc, I am tempted to call this a feature request and retitle it "Make unified_diff match gnu diff for [] input". The docs do not reference external definitions for context-diff and unified-diff. The entry for unified-diff does not give a format for the @@ control lines. So the current behavior cannot be said to violate the doc spec.

On the other hand, putting random garbage on @@ lines would clearly be a bug, so the doc must be taken as referencing some external definition, even if vague.
 
https://secure.wikimedia.org/wikipedia/en/wiki/Diff#Unified_format
says "Unified context diffs were originally developed by Wayne Davison in August 1990 (in unidiff which appeared in Volume 14 of comp.sources.misc). Richard Stallman added unified diff support to the GNU Project's diff utility one month later,". So using gnu diff as a standard is not unreasonable. (But did it give 0,0 for null files from the beginning?)

Now looking practically. If nothing but patch programs ever read and act on the control blocks, then, say Ray, a change would neither hurt nor be of any use. If any Python code does look, then a change could break code. I would in any case be reluntant to change 2.7. 

But if this is treated as a feature request and only 3.3 swere changed, then we would have to document the change:
"Version changed 3.3: for empty lists, the @@ block specification was changed from 1,0 to 0,0", which is pretty close to adding useless noise.
3.0 would have been the best time to make this change.