classification
Title: difflib: add patch capability
Type: enhancement Stage: resolved
Components: Demos and Tools Versions: Python 3.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, eric.araujo, marco, rhettinger, stefanv, swixel, techtonik, terry.reedy, twhitema
Priority: low Keywords:

Created on 2008-02-10 07:32 by techtonik, last changed 2014-07-04 01:18 by terry.reedy. This issue is now closed.

Messages (17)
msg62244 - (view) Author: anatoly techtonik (techtonik) Date: 2008-02-10 07:32
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.
msg84146 - (view) Author: anatoly techtonik (techtonik) Date: 2009-03-25 07:38
Tool is ready. diff/patch lib is not. http://code.google.com/p/python-patch/
msg113206 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-07 21:18
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.'
msg116953 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-09-20 16:29
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.
msg116960 - (view) Author: anatoly techtonik (techtonik) Date: 2010-09-20 18:33
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.
msg116970 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-09-20 20:57
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.
msg116988 - (view) Author: anatoly techtonik (techtonik) Date: 2010-09-20 22:06
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.
msg137984 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-09 15:16
For this to move forward, a patch or link to Mercurial repo would be required.
msg137998 - (view) Author: anatoly techtonik (techtonik) Date: 2011-06-09 16:10
For this to move forward, PSF should accelerate work on new sane Contributor's Agreements or join Harmony (http://www.harmonyagreements.org/)
msg138011 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-06-09 16:36
Anatoly,
Even if I remove all sarcasm from your previous answer, I don't see what it brings to the current issue.
msg138019 - (view) Author: anatoly techtonik (techtonik) Date: 2011-06-09 18:05
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.
msg138093 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-10 16:02
A productive thing to do would be to ask feedback on python-ideas for this new feature.
msg148906 - (view) Author: Marco Scataglini (marco) Date: 2011-12-06 04:23
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
msg148923 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-12-06 15:03
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.)
msg222144 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-07-02 23:03
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.
msg222228 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2014-07-03 22:09
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).
msg222255 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-07-04 01:18
I am going to agree with starting on PyPI if indeed there is not something there now.
History
Date User Action Args
2014-07-04 01:18:15terry.reedysetstatus: open -> closed
resolution: rejected
messages: + msg222255

stage: needs patch -> resolved
2014-07-03 22:09:49rhettingersetnosy: + rhettinger
messages: + msg222228
2014-07-02 23:03:02terry.reedysetmessages: + msg222144
2014-02-03 19:14:44BreamoreBoysetnosy: - BreamoreBoy
2011-12-06 15:03:02eric.araujosetmessages: + msg148923
2011-12-06 04:23:38marcosetnosy: + marco
messages: + msg148906
2011-06-10 16:02:35eric.araujosetmessages: + msg138093
2011-06-09 18:05:28techtoniksetmessages: + msg138019
2011-06-09 16:36:19amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg138011
2011-06-09 16:10:11techtoniksetmessages: + msg137998
2011-06-09 15:16:32eric.araujosetversions: + Python 3.3, - Python 3.2
nosy: + eric.araujo

messages: + msg137984

stage: test needed -> needs patch
2010-09-20 22:06:06techtoniksetmessages: + msg116988
2010-09-20 20:57:59terry.reedysetmessages: + msg116970
2010-09-20 18:33:19techtoniksetmessages: + msg116960
2010-09-20 16:29:01BreamoreBoysetnosy: + BreamoreBoy
messages: + msg116953
2010-08-07 21:18:09terry.reedysetversions: + Python 3.2, - Python 2.6
nosy: + terry.reedy

messages: + msg113206

stage: test needed
2009-08-29 07:44:48swixelsetnosy: + swixel
2009-06-04 02:47:16twhitemasetnosy: + twhitema
2009-04-03 14:26:12stefanvsetnosy: + stefanv
2009-03-25 07:38:37techtoniksetmessages: + msg84146
2008-02-11 11:03:36christian.heimessetpriority: low
2008-02-10 07:32:51techtonikcreate