homepage

difflib alone and bundled Tools\Scripts\diff.py utility are both very
useful, esp. on windows platforms where standard unix diffutils are
absent. However, python difflib still doesn't have a patch counterpart
to apply at least unified diff format.

Tool is ready. diff/patch lib is not. http://code.google.com/p/python-patch/ 

I would like to see this more easily available, perhaps in /Scripts.
Are unified diffs the type usually posted to the tracker?
I am not sure what you meant by ' diff/patch lib is not.'

Is this really needed? TortoiseSVN is a cracking bit of kit, and I'm hoping that in the future TortoiseHG is as good if not better.

Unified diffs is the preferred type on this tracker as http://www.python.org/dev/patches/ describes. I also sure that they constitute more than 90% of patches attached here. If you have access to tracker attachments - you can test this.
Unfortunately, diff.py generates context diffs by default, and I do not have plans to add this format into my patch.py tool, so it won't be a correct counterpart to include in Scripts/
By ' diff/patch lib is not.' I meant that 'diff/patch _lib_ is not ready'. You can use patch.py as a tool, but don't rely that API is stable.

Given that difflib produces unified diffs (among 3 others) and that diff.py is a thin command-line wrapper that provides access to all 4 formats (with no default), I consider those two files 'ready'. So I presume you are referring to your patch.py, which is still labelled experimental.
Difflib works by analyzing sequences a and b with SequenceMatcher to produce a sequence of edits that would produce b from a. It then formats the edits into 1 of 4 formats.
Ideally, a patchlib would have a core SequenceEditor that would apply a sequence of edits (in the same format as SequenceMatcher's outputs) to sequence a to output sequence b. That much seems relatively easy. To be complete, it should also have at least 3 if not 4 parse functions that would produce edit sequences. A corresponding patch.py would then be a thin command-line wrapper over patchlib.
Your comments and a perusal of your code indicates that it has a unified diff parser, a sequence matcher, and command-line wrapper. I guess the immediate question is whether this would be enough for a start.

On Mon, Sep 20, 2010 at 11:58 PM, Terry J. Reedy <report@bugs.python.org> wrote:
> Given that difflib produces unified diffs (among 3 others) and that diff.py is a thin command-line wrapper that provides access to all 4 formats (with no default), I consider those two files 'ready'.
Context diff is default format for diff.py utility. I tried my best to
change this, but failed, and that's very disappointing in Python
community. You may take a look how much time was wasted on a decision
for a file that is neither part of standard library nor really used by
anyone participated except me. http://bugs.python.org/issue8355
> So I presume you are referring to your patch.py, which is still labelled experimental.
>
> Difflib works by analyzing sequences a and b with SequenceMatcher to produce a sequence of edits that would produce b from a. It then formats the edits into 1 of 4 formats.
>
> Ideally, a patchlib would have a core SequenceEditor that would apply a sequence of edits (in the same format as SequenceMatcher's outputs) to sequence a to output sequence b. That much seems relatively easy. To be complete, it should also have at least 3 if not 4 parse functions that would produce edit sequences. A corresponding patch.py would then be a thin command-line wrapper over patchlib.
Difflib doesn't produce correct output for unified format, and
patch.py is not able to parse it correctly - see issue2142, issue7585
(for Python 2.6). patch.py doesn't operate with sequences of edits -
it has line by line parser (rather than symbol by symbol), which
produces list of filenames with info about changed lines in hunk
objects (containing line numbers). There is no SequenceEditor
sequences.
> Your comments and a perusal of your code indicates that it has a unified diff parser, a sequence matcher, and command-line wrapper. I guess the immediate question is whether this would be enough for a start.
Unified diff parser is valid only for Subversion style patches.
Patches produced by difflib are not valid as stated above. Mercurial
and git style patches are about to be added later with an ability to
create and copy/move files.
Sequence matcher is line comparison tool with some intelligence to
free developer from CRLF difference sufferings. It is good for "apply
patch" use case, but I do not know how about low-level SequenceEditor
API. Usually patch utilities contains more additional logic to apply
patches with some offset.
http://code.google.com/p/google-diff-match-patch/ will be a better
point for low level difflib API.

For this to move forward, a patch or link to Mercurial repo would be required.

For this to move forward, PSF should accelerate work on new sane Contributor's Agreements or join Harmony (http://www.harmonyagreements.org/)

Anatoly,
Even if I remove all sarcasm from your previous answer, I don't see what it brings to the current issue.

It is not sarcasm, but prerequisite. I do not sign papers I don't understand or papers that doesn't make any sense (and thus are free to any interpretation). I could sign current CLA right away, but I prefer not to do this until everybody is aware of the issue.

A productive thing to do would be to ask feedback on python-ideas for this new feature.

I agree with Anatoly that it should be an easy way to create and apply Unified Diff Patches within Python. Also issue 2142 should get fixed, as proposed, but also include the fix at least on 2.7 not only on 3.x

Hi Marco, thanks for your interest in improving Python. Do you want to propose a patch for this request? If so, guidelines and help are found in the devguide.
(For the other bug, please read the discussion there to see why 2.7 is not possible.)

I would like a simple patcher for three reasons.
1. hg, at least as I see it exposed through tortoisehg workbenck, will not apply a patch if there is already an uncommitted change. (But perhaps someone will tell me that there is a 'do it anyway' option.)
Sometimes when working on a patch, I want to quickly try out ant then revert another patch that I know does not conflict with the current one.
2. The hg patcher does not give error messages (other than 'chunk failed'). So to do a backport, for instance, I re-edit the file instead of correcting the diff.s
3. Not everything is in hg or equivalent.

I don't think this should be done. Python is primarily a language with a standard library, not a command-line development toolkit. We should avoid "mission creep".
There are plenty of mature, robust, full-featured solutions already available. For example, when I was developing Python on Windows, I used the GNU Win32 toolkit.
If anything, this ought to be an offering on PyPI. There is could live freely outside our rather slow release cycle which is too lethargic to respond the challenges that would inevitably arise with a new command-line tool (i.e. it won't handle input from some diff utility, or isn't robust against minor spacing issues or encoding issues, or it can't handle slightly offset hunks etc).

I am going to agree with starting on PyPI if indeed there is not something there now.