| msg102701 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-09 08:54 |
| Script/diff.py default context diff format is outdated. It makes sense to produce unified diff by default. |
|
|
| msg102729 - (view) |
Author: Eric V. Smith (eric.smith) *  |
Date: 2010-04-09 15:53 |
| 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, since it should probably agree with 2.7. What I can't answer is if this should actually be done. I don't know if anyone's relying on the current behavior. I do agree that unified diffs are more desirable. |
|
|
| msg102736 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-04-09 17:54 |
| 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 hand, Tools probably don't need to be held to as high a standard as library code. I guess I'm +0 on this change. |
|
|
| msg102747 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-09 20:53 |
| Attached is 'svn diff'. Previous one was taken directly from Mercurial Queue, which is a pretty awesome thing to use. |
|
|
| msg102748 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2010-04-09 21:03 |
| 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 |
|
|
| msg102751 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2010-04-09 21:28 |
| 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 hunks FAILED -- saving rejects to file Tools/scripts/diff.py.rej The new patch worked for me. I'm -0 on this change, for what it's worth. It's probably all irrelevant, anyway. I can't imagine anyone actually generates their diffs with diff.py. As a useful demonstration of how difflib works, it does its job as it currently stands. |
|
|
| msg102752 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-09 21:33 |
| 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 and combination. For being a diff replacement it will have to get rid of .py extension and gain a dozen of options. Such as --normal, -p, -w, -q, -r etc. Without these options diff.py can not be considered diff replacement. This script is more useful on its own, providing reasonable defaults for a cross-platform way of making patches for Python users. |
|
|
| msg102753 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2010-04-09 21:41 |
| Your use case and rationale make sense to me. I’d be +0.5 if I had a voice :) Regards |
|
|
| msg102755 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-04-09 21:46 |
| I'm with Eric, -0. I don't really think the change is necessary. |
|
|
| msg103019 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-13 08:03 |
| -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 without a strong reason, but Tools is not stdlib +0.5 merwok as diff.py can not be considered unix diff replacement Wouldn't it be nice if you haven't need to say your tool how to do the thing you like? 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/ |
|
|
| msg103036 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-13 11:24 |
| You can use http://gnuwin32.sourceforge.net/packages/diffutils.htm or cygwin or msys. |
|
|
| msg103037 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-13 11:34 |
| I hope this is not a support tracker. =) |
|
|
| msg103038 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-13 11:34 |
| Do you really think that Python users shouldn't use tools written in Python if they are available? |
|
|
| msg103054 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-04-13 15:02 |
| > 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. |
|
|
| msg103056 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-04-13 15:28 |
| > 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 the moment, and "hg diff" when we switch. |
|
|
| msg103059 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-13 16:16 |
| 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 for "diff (1)", but our own custom tool that produces diffs? If that's true when why don't you let this tool produce unified diffs by default if you and everybody else here want diffs in this format? |
|
|
| msg103062 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-13 17:04 |
| 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, but that's no reason to deviate further. |
|
|
| msg103063 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-13 17:08 |
| Stefan, do you use "diff.py"? |
|
|
| msg103073 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-13 19:13 |
| 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 know. More customers would be happy if the basic version included their favorite flavor. From another side unix 'diff' users are smart enough to read command line help for 'diff.py' if they won't like default unified output and choose the option they need. BTW, what option should I specify to unix diff to get HTML or ndiff output? Let me remind that there are tools like 'svnmerge' that do even more things that standard 'svn merge' does not. Your arguments could be more convincing if you could show at least one real world example against "diff.py" that outweighs the benefit of having unified diff generated without any additional options. IIUC Python scripts are installed with .py extension even on Unix platform, and you can't execute 'diff.py' instead of 'diff' by mistake. |
|
|
| msg103074 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2010-04-13 19:19 |
| 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-world reports of users (Windows or otherwise) who would use this tool, if only it had a different default? |
|
|
| msg103075 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-04-13 19:20 |
| > 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 know. > More customers would be happy if the basic version included their > favorite flavor. Hey, could you please stop complaining? You opened the issue, you are the own bikeshedding here. Besides, Python's goal is /not/ to produce a tool chain of replacement programs for the standard Unix utilities. There are certainly more constructive things to do for the Python community, than to keep insisting on this issue. Micro-problems don't warrant stressing everyone's patience with aggressive hand-waving. Thanks in advance. |
|
|
| msg103083 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-13 20:14 |
| 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 resolution for the next issue in my list like #7582 or # 7584 |
|
|
| msg103085 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2010-04-13 20:31 |
| Tentatively closing as rejected. There were quite a lot of -0 or -1, and you can include one from me as well. |
|
|
| msg103303 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-16 08:16 |
| 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. |
|
|
| msg103304 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-16 08:26 |
| 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 that accepts only unified diffs without any options, so it would be nice if diff.py generated unified diffs without any options as well -1 - I don't use diff.py to generate my diffs, I do not care that it is not a part of standard library, I know that it's output format is incompatible with unix diff(1) format, and I still want diff.py to generate incompatible context diffs by default, even though I could always generate them with -c option |
|
|
| msg103371 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2010-04-16 22:00 |
| -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. |
|
|
| msg103378 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2010-04-16 22:41 |
| I concur with Benjamin. |
|
|
| msg103465 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-18 07:52 |
| 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-patch/ |
|
|
| msg103466 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-18 07:59 |
| But I still think sticking to -c behavior by default is too conservative for clear minds. =) |
|
|
| msg163447 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2012-06-22 17:58 |
| Reopening for Python 3. Does anybody still use context diffs nowadays? |
|
|
| msg163450 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2012-06-22 18:20 |
| The reasons for rejecting this still apply. |
|
|
| msg163451 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2012-06-22 18:28 |
| > The reasons for rejecting this still apply. Which specifically are valid for 3.3? |
|
|
| msg163859 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2012-06-24 21:00 |
| All of them, especially the last one by Benjamin. |
|
|
| msg163869 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2012-06-24 21:57 |
| Eric, you're refering to argument: > -1 Even if diff.py is not exaclty a diff replacement, it still makes > sense to emulate what's in people's minds. Could you explain it in your own words, because I don't posess the skills to read people's minds. > I really don't find having to type 3 more characters a very convincing argument. Which basically reads "my argument against is that your argument for is not a convincing argument", which I read as - "ok, your argument is valid - I don't mind, I don't have arguments - I just don't agree". So, Eric, it will help me understand you better it you could state your own opinion and list arguments that are valid for you in your own words. It is easy to be a part of a public opinion, so without explicit arguments it is hard to say if people just follow the majority to get rid of annoyance or really have the point. |
|
|
| msg163879 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2012-06-25 00:44 |
| Status quo wins a stalemate (and this isn't even really a stalemate. Languishing is for bugs/enhancements no one has stepped up to implement. This one is rejected. |
|
|