[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: > The reasons for rejecting this still apply. Which specifically are valid for 3.3? -- ___ Python tracker ___ __

[issue8355] diff.py produce unified format by default

Éric Araujo added the comment: The reasons for rejecting this still apply. -- versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: Reopening for Python 3. Does anybody still use context diffs nowadays? -- status: closed -> open versions: +Python 3.3 -Python 2.7, Python 3.2 ___ Python tracker ___

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: But I still think sticking to -c behavior by default is too conservative for clear minds. =) -- ___ Python tracker ___ _

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: Ok. I just wanted to make it compatible with my patch.py utility designed as a counterpart to diff.py to make Python contributing process self-sufficient on any platform. Its parser component doesn't support context diffs. http://code.google.com/p/python-p

[issue8355] diff.py produce unified format by default

Raymond Hettinger added the comment: I concur with Benjamin. -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing

[issue8355] diff.py produce unified format by default

Benjamin Peterson added the comment: -1 Even if diff.py is not exaclty a diff replacement, it still makes sense to emulate what's in people's minds. I really don't find having to type 3 more characters a very convincing argument. -- nosy: +benjamin.peterson status: open -> closed ___

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: I.e. if you put a -1 or +1 - put it with a short sentence that summarizes the key factor in your decision. There is no +0 or -0 that are used to give everybody else a hint about your feelings towards. For example: +1 - I use patch.py diff.py counterpart t

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: I am not convinced with -1 +1 argumentation. Can somebody properly summarize arguments behind the decision? Democracy is good, but it is a pity to see a technical proposal fail because of personal reasons. -- status: pending -> open __

[issue8355] diff.py produce unified format by default

Georg Brandl added the comment: Tentatively closing as rejected. There were quite a lot of -0 or -1, and you can include one from me as well. -- nosy: +georg.brandl resolution: -> rejected status: open -> pending ___ Python tracker

[issue8355] diff.py produce unified format by default

Changes by Stefan Krah : -- nosy: -skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: Seems like a bikeshed was too much of an argument, but I've run out of them discussing such minor issue. The last is that if anybody here has 0's - does my +1 value something? Why can't anybody just commit it and close this, so I can concentrate on resolut

[issue8355] diff.py produce unified format by default

Changes by Eric Smith : -- nosy: -eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue8355] diff.py produce unified format by default

Changes by Antoine Pitrou : -- nosy: -pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue8355] diff.py produce unified format by default

Changes by Brian Curtin : -- nosy: -brian.curtin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue8355] diff.py produce unified format by default

Antoine Pitrou added the comment: > Seems like I have to remind that everybody can still paint their > bikeshed in classic colors with "-c" option, but if you all prefer > unified colors, why do you resist on painting them in these by > default? Custom color options add more to a total price, yo

[issue8355] diff.py produce unified format by default

Eric Smith added the comment: To change the default, you need to know how many people it will benefit, and how many people will be negatively impacted by the change. I personally suspect that both numbers are zero, which is why I have a hard time getting excited about it. Are there any real-

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: Seems like I have to remind that everybody can still paint their bikeshed in classic colors with "-c" option, but if you all prefer unified colors, why do you resist on painting them in these by default? Custom color options add more to a total price, you

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: Stefan, do you use "diff.py"? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue8355] diff.py produce unified format by default

Stefan Krah added the comment: The requirement to remember the "-u" option is a benefit for the user. If he ever wants to use a standard diff, he doesn't have to relearn things. I don't agree that diff.py should be a custom tool. It's unfortunate that it already deviates from standard diffs, bu

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: I'll add a note about preferred "svn diff" way and "diff.py" as a fallback. But first I'd like to see this patch committed to streamline patch submission process by removing requirement to remember "-u" option. Do agree that "diff.py" is not a replacement

[issue8355] diff.py produce unified format by default

Brian Curtin added the comment: > Don't you want to add a recommendation to use diff.py tool so > that Windows users can also send patches? > http://python.org/dev/patches/ We could add that note but it should not be a recommendation. Patches should ideally be generated using "svn diff" at th

[issue8355] diff.py produce unified format by default

Antoine Pitrou added the comment: > Do you really think that Python users shouldn't use tools written in > Python if they are available? Sure, they can. For example, they can use Mercurial and type "hg diff". Or even TortoiseHg and do it all from a GUI. -- nosy: +pitrou __

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: Do you really think that Python users shouldn't use tools written in Python if they are available? -- ___ Python tracker ___ ___

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: I hope this is not a support tracker. =) -- ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue8355] diff.py produce unified format by default

Stefan Krah added the comment: You can use http://gnuwin32.sourceforge.net/packages/diffutils.htm or cygwin or msys. -- nosy: +skrah ___ Python tracker ___ __

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: -0 eric.smith for concerns about people relying on current behaviour -0 brian.curtin the same counterarg: current behavior will be broken anyway with compatibility fix in r80004 +0 r.david.murray the policy that we shouldn't change stdlib interfaces

Re: [issue8355] diff.py produce unified format by default

On 2010-04-09, Eric Smith wrote: > > Eric Smith added the comment: > > I tried -p1 and it failed, but no matter. The contents were clear enough, > and exactly how I would have changed the code. > > $ patch -p1 < 8355.diff-py-unified-by-default.diff > patching file Tools/scripts/diff.py > Hunk #1

[issue8355] diff.py produce unified format by default

Brian Curtin added the comment: I'm with Eric, -0. I don't really think the change is necessary. -- nosy: +brian.curtin ___ Python tracker ___ ___

[issue8355] diff.py produce unified format by default

Éric Araujo added the comment: Your use case and rationale make sense to me. I’d be +0.5 if I had a voice :) Regards -- ___ Python tracker ___ __

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: It is not a diff replacement. Its output, as David noted, is not a diff output format and can not be reliably parsed due to issue7585 and issue7582 combination. For being a diff replacement it will have to get rid of .py extension and gain a dozen of opti

[issue8355] diff.py produce unified format by default

Eric Smith added the comment: I tried -p1 and it failed, but no matter. The contents were clear enough, and exactly how I would have changed the code. $ patch -p1 < 8355.diff-py-unified-by-default.diff patching file Tools/scripts/diff.py Hunk #1 FAILED at 13. Hunk #2 FAILED at 34. 2 out of 2

[issue8355] diff.py produce unified format by default

Éric Araujo added the comment: Some diff-emitting utilities only support unified format, but if diff.py is supposed to be a diff(1) replacement, changing default options seems bad. Eric, I think “patch -p1 < file” would have done the trick, without manual mucking. Regards -- nosy: +

[issue8355] diff.py produce unified format by default

anatoly techtonik added the comment: Attached is 'svn diff'. Previous one was taken directly from Mercurial Queue, which is a pretty awesome thing to use. -- Added file: http://bugs.python.org/file16849/8355.diff-py-unified-by-default.svn.diff ___

[issue8355] diff.py produce unified format by default

R. David Murray added the comment: For what it is worth, the unix 'diff' command does not produce unified format by default. It doesn't produce the format diff.py does by default either, though. Our normal policy is not to change an interface unless there's a strong reason. On the other ha

[issue8355] diff.py produce unified format by default

Eric Smith added the comment: This would be easier to review if the patch were generated with 'svn diff'. That said, it looks okay in concept to me, although I couldn't apply it and test without manually mucking with the patch. 2.6 is in bugfix mode, so it can't be changed there. I added 3.2,

[issue8355] diff.py produce unified format by default

Changes by anatoly techtonik : -- keywords: +patch Added file: http://bugs.python.org/file16840/8355.diff-py-unified-by-default.diff ___ Python tracker ___ __

[issue8355] diff.py produce unified format by default

New submission from anatoly techtonik : Script/diff.py default context diff format is outdated. It makes sense to produce unified diff by default. -- components: Demos and Tools messages: 102701 nosy: techtonik severity: normal status: open title: diff.py produce unified format by defau