Hello,
Following discussion on python-dev, I plan to untabify the C codebase this afternoon. It would probably be better if nobody modified any C files in the meantime (except those that already use 4 space indents).
I expect the whole operation to take a couple of hours.
Regards
Antoine.
On Sun, May 9, 2010 at 2:39 PM, Antoine Pitrou solipsis@pitrou.net wrote:
Following discussion on python-dev, I plan to untabify the C codebase this afternoon. It would probably be better if nobody modified any C files in the meantime (except those that already use 4 space indents).
Are you brave, or mad, or both?
Just joking :) No objections from me.
I expect the whole operation to take a couple of hours.
In which case it might be advisable for anyone who doesn't enjoy receiving half-million line emails to turn off python-checkins delivery for a couple of hours...
Mark
Following discussion on python-dev, I plan to untabify the C codebase this afternoon. It would probably be better if nobody modified any C files in the meantime (except those that already use 4 space indents).
I expect the whole operation to take a couple of hours.
This was done in r81029 (trunk), r81031 (2.6), r81032 (3.x) and r81033 (3.1). I'm mentioning the revision numbers because it seems python-checkins blocked the diffs, sensibly enough.
There may be a couple of places where formatting was slightly worsened (especially comments). Most of the files look totally fine, though. I've done some visual inspection, but I could not examine each of the 500000 diff lines in each branch.
There was one file that I didn't touch: Modules/_cursesmodule.c Indentation is so uncommon there that interested people should reformat it themselves, if desired.
If you have patches pending and they don't apply cleanly anymore, you can either:
- use "patch -l", and then reformat the modified lines manually
- use "untabify.py -p" on your patch
(http://svn.python.org/view/*checkout*/sandbox/trunk/untabify/untabify.py)
Regards
Antoine.
Le dimanche 09 mai 2010 18:56:27, Antoine Pitrou a écrit :
This was done in r81029 (trunk), r81031 (2.6), r81032 (3.x) and r81033 (3.1). I'm mentioning the revision numbers because it seems python-checkins blocked the diffs, sensibly enough.
Does "make patchcheck" detect tab indentation and trailing spaces regressions?
If you have patches pending and they don't apply cleanly anymore, you can either:
- use "patch -l", and then reformat the modified lines manually
- use "untabify.py -p" on your patch
(http://svn.python.org/view/*checkout*/sandbox/trunk/untabify/untabify.py)
Is it documented somewhere? In the developer FAQ?
Le dimanche 09 mai 2010 à 22:04 +0200, Victor Stinner a écrit :
Le dimanche 09 mai 2010 18:56:27, Antoine Pitrou a écrit :
This was done in r81029 (trunk), r81031 (2.6), r81032 (3.x) and r81033 (3.1). I'm mentioning the revision numbers because it seems python-checkins blocked the diffs, sensibly enough.
Does "make patchcheck" detect tab indentation and trailing spaces regressions?
No. As a matter of fact, I've never used "make patchcheck" and therefore always forget about its existence. Do you want to propose a patch for this?
If you have patches pending and they don't apply cleanly anymore, you can either:
- use "patch -l", and then reformat the modified lines manually
- use "untabify.py -p" on your patch
(http://svn.python.org/view/*checkout*/sandbox/trunk/untabify/untabify.py)
Is it documented somewhere? In the developer FAQ?
I don't think it should go into the developer FAQ, since it's only a temporary situation. IMHO it's sufficient to tell people about it when they ask on the tracker, or even to do the reformatting ourselves.
(I don't think there are many patches pending on the set of modified files, but I could be mistaken)
Regards
Antoine.
On Sun, May 9, 2010 at 1:22 PM, Antoine Pitrou solipsis@pitrou.net wrote:
Le dimanche 09 mai 2010 à 22:04 +0200, Victor Stinner a écrit :
Le dimanche 09 mai 2010 18:56:27, Antoine Pitrou a écrit :
This was done in r81029 (trunk), r81031 (2.6), r81032 (3.x) and r81033 (3.1). I'm mentioning the revision numbers because it seems python-checkins blocked the diffs, sensibly enough.
Does "make patchcheck" detect tab indentation and trailing spaces regressions?
No. As a matter of fact, I've never used "make patchcheck" and therefore always forget about its existence. Do you want to propose a patch for this?
If you have patches pending and they don't apply cleanly anymore, you can either: - use "patch -l", and then reformat the modified lines manually - use "untabify.py -p" on your patch (http://svn.python.org/view/*checkout*/sandbox/trunk/untabify/untabify.py)
Is it documented somewhere? In the developer FAQ?
I don't think it should go into the developer FAQ, since it's only a temporary situation. IMHO it's sufficient to tell people about it when they ask on the tracker, or even to do the reformatting ourselves.
(I don't think there are many patches pending on the set of modified files, but I could be mistaken)
Regards
Antoine.
fwiw, untabify.py seemed to work fine to keep the change I had in my svn client in shape across this update.
svn diff Modules/threadmodule.c >foo.diff svn revert Modules/threadmodule.c svn up # update past the untabify changes ../untabify.py <foo.diff >foo-untabbed.diff patch -p0 <foo-untabbed.diff
Thanks for doing this Antoine (belated +1 from me). It may cause some temporary pain today and while dealing with existing patches on the tracker (anyone want to script walking the tracker and auto-untabifying patches that touch .c/.h files?) but it is worth it for the future health of the code base.
-gps
On Sun, May 09, 2010 at 06:56:27PM +0200, Antoine Pitrou wrote:
There was one file that I didn't touch: Modules/_cursesmodule.c Indentation is so uncommon there that interested people should reformat it themselves, if desired.
I'm happy to see the curses module re-indented. Does anyone have a set of settings for Emacs or for GNU indent for Python's C indentation style?
--amk
On Sun, May 9, 2010 at 6:01 PM, A.M. Kuchling amk@amk.ca wrote:
I'm happy to see the curses module re-indented. Does anyone have a set of settings for Emacs or for GNU indent for Python's C indentation style?
This invocation of GNU indent should work reasonably well:
indent
--no-tabs
--indent-level8
--blank-lines-after-procedures
--no-blank-lines-after-declarations
--no-comment-delimiters-on-blank-lines
--start-left-side-of-comments
--braces-on-if-line
--dont-cuddle-else
--cuddle-do-while
--case-indentation0
--dont-space-special-semicolon
--no-space-after-function-call-names
--space-after-for
--space-after-if
--space-after-while
--no-blank-lines-after-commas
--declaration-indentation1
--braces-on-struct-decl-line
--procnames-start-lines
--continue-at-parentheses
--preprocessor-indentation0
--break-after-boolean-operator
-- Alexandre
2010/5/9 Alexandre Vassalotti alexandre@peadrop.com:
On Sun, May 9, 2010 at 6:01 PM, A.M. Kuchling amk@amk.ca wrote:
I'm happy to see the curses module re-indented. Does anyone have a set of settings for Emacs or for GNU indent for Python's C indentation style?
This invocation of GNU indent should work reasonably well:
indent
--no-tabs
--indent-level8
--blank-lines-after-procedures
--no-blank-lines-after-declarations
--no-comment-delimiters-on-blank-lines
--start-left-side-of-comments
--braces-on-if-line
--dont-cuddle-else
--cuddle-do-while
--case-indentation0
--dont-space-special-semicolon
--no-space-after-function-call-names
--space-after-for
--space-after-if
--space-after-while
--no-blank-lines-after-commas
--declaration-indentation1
--braces-on-struct-decl-line
--procnames-start-lines
--continue-at-parentheses
--preprocessor-indentation0
--break-after-boolean-operator
And from the manpage:
... BUGS indent has even more switches than ls(1). ...
-- Alexandre
On May 09, 2010, at 09:01 PM, A.M. Kuchling wrote:
On Sun, May 09, 2010 at 06:56:27PM +0200, Antoine Pitrou wrote:
There was one file that I didn't touch: Modules/_cursesmodule.c Indentation is so uncommon there that interested people should reformat it themselves, if desired.
I'm happy to see the curses module re-indented. Does anyone have a set of settings for Emacs or for GNU indent for Python's C indentation style?
In Emacs, visit a C file and type:
C-c . python RET
'python' is a standard c-mode indentation style, however it's set up to use tabs. It should be updated, maybe to a 'python3' style? Here's a quick and dirty hack:
(c-add-style "python3" '("python" (indent-tabs-mode . nil) (c-basic-offset . 4) ))
-Barry
On Mon, May 10, 2010 at 2:25 PM, Barry Warsaw barry@python.org wrote:
On May 09, 2010, at 09:01 PM, A.M. Kuchling wrote:
I'm happy to see the curses module re-indented. Does anyone have a set of settings for Emacs or for GNU indent for Python's C indentation style?
In Emacs, visit a C file and type:
C-c . python RET
'python' is a standard c-mode indentation style, however it's set up to use tabs. It should be updated, maybe to a 'python3' style? Here's a quick and dirty hack:
(c-add-style "python3" '("python" (indent-tabs-mode . nil) (c-basic-offset . 4) ))
See also
http://wiki.python.org/moin/EmacsEditor
where there's a 'python-new' style that can be added to an .emacs file.
Mark
On Mon, May 10, 2010 at 07:02, Mark Dickinson dickinsm@gmail.com wrote:
On Mon, May 10, 2010 at 2:25 PM, Barry Warsaw barry@python.org wrote:
On May 09, 2010, at 09:01 PM, A.M. Kuchling wrote:
I'm happy to see the curses module re-indented. Does anyone have a set of settings for Emacs or for GNU indent for Python's C indentation style?
In Emacs, visit a C file and type:
C-c . python RET
'python' is a standard c-mode indentation style, however it's set up to
use
tabs. It should be updated, maybe to a 'python3' style? Here's a quick
and
dirty hack:
(c-add-style "python3" '("python" (indent-tabs-mode . nil) (c-basic-offset . 4) ))
See also
http://wiki.python.org/moin/EmacsEditor
where there's a 'python-new' style that can be added to an .emacs file.
And for those of you using the python.vim file from Misc/Vim, you have been covered automatically. =)
On Mon, May 10, 2010 at 03:25:05PM +0200, Barry Warsaw wrote:
'python' is a standard c-mode indentation style, however it's set up to use tabs. It should be updated, maybe to a 'python3' style? Here's a quick and dirty hack:
Thanks! I've carried out a re-indentation and whitespace cleanup in the sandbox/curses/ directory; it still compiles & passes its tests, such as they are. Does someone want to take a brief glance at the resulting code to double-check?
http://svn.python.org/view/sandbox/trunk/curses/_cursesmodule.c?revision=810...
I can commit this to trunk. Presumably merging this change to 3.x would fail horribly; for 3.x, should I just carry out the same set of steps (apply some small coding cleanups that could probably be merged from trunk, then re-indent using Emacs)?
--amk
Le lundi 10 mai 2010 03:01:11, A.M. Kuchling a écrit :
On Sun, May 09, 2010 at 06:56:27PM +0200, Antoine Pitrou wrote:
There was one file that I didn't touch: Modules/_cursesmodule.c Indentation is so uncommon there that interested people should reformat it themselves, if desired.
I'm happy to see the curses module re-indented. Does anyone have a set of settings for Emacs or for GNU indent for Python's C indentation style?
Done: revisions 81213, 81214-81216
I used untabify.py + emacs (python3 mode) + manual edit for Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS.
On May 09, 2010, at 03:39 PM, Antoine Pitrou wrote:
Following discussion on python-dev, I plan to untabify the C codebase this afternoon. It would probably be better if nobody modified any C files in the meantime (except those that already use 4 space indents).
Thanks for doing something we've only been talking about for at least 10 years. :)
You are my new best friend.
-Barry
Barry Warsaw wrote:
On May 09, 2010, at 03:39 PM, Antoine Pitrou wrote:
Following discussion on python-dev, I plan to untabify the C codebase this afternoon. It would probably be better if nobody modified any C files in the meantime (except those that already use 4 space indents).
Thanks for doing something we've only been talking about for at least 10 years. :)
Indeed :)
Cheers, Nick.
Nick Coghlan wrote:
Barry Warsaw wrote:
On May 09, 2010, at 03:39 PM, Antoine Pitrou wrote:
Following discussion on python-dev, I plan to untabify the C codebase this afternoon. It would probably be better if nobody modified any C files in the meantime (except those that already use 4 space indents).
Thanks for doing something we've only been talking about for at least 10 years. :)
Indeed :)
Cheers, Nick.
And ever afterwards that time was known as the Epoch of the Great Untabification; and children heard stories of what programmers they had been.
fanciful-ly y'rs - steve
Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000
On May 11, 2010, at 08:48 AM, Steve Holden wrote:
Nick Coghlan wrote:
Barry Warsaw wrote:
On May 09, 2010, at 03:39 PM, Antoine Pitrou wrote:
Following discussion on python-dev, I plan to untabify the C codebase this afternoon. It would probably be better if nobody modified any C files in the meantime (except those that already use 4 space indents).
Thanks for doing something we've only been talking about for at least 10 years. :)
Indeed :)
Cheers, Nick.
And ever afterwards that time was known as the Epoch of the Great Untabification; and children heard stories of what programmers they had been.
fanciful-ly y'rs - steve
Who remembers the Great Renaming? :)
-Barry
On Tue, May 11, 2010 at 9:25 AM, Barry Warsaw barry@python.org wrote:
Who remembers the Great Renaming? :)
Oooh! Oooh! I know that one! :-)
-Fred
On Tue, May 11, 2010 at 10:13 AM, Fred Drake fdrake@acm.org wrote:
On Tue, May 11, 2010 at 9:25 AM, Barry Warsaw barry@python.org wrote:
Who remembers the Great Renaming? :)
Oooh! Oooh! I know that one! :-)
-Fred
http://python-history.blogspot.com/2009/03/great-or-grand-renaming.html
Le mardi 11 mai 2010 20:15:49, Guido van Rossum a écrit :
http://python-history.blogspot.com/2009/03/great-or-grand-renaming.html
"Great or Grand Renamings are often traumatic events for software developer communities ... and complicate the integration of patches created before the renaming but applied after. (This is especially problematic when unrenamed branches exist.)"
Antoine patched the 4 most important branches. Do we you have other active branches?
Victor
Victor Stinner wrote:
Antoine patched the 4 most important branches. Do we you have other active branches?
Any other active feature branches (such as c-decimal and the branch for the signal work) should pick up the tab changes next time they do an svnmerge (or the moral equivalent for Tarek's hg branch).
Cheers, Nick.
Barry Warsaw wrote:
On May 11, 2010, at 08:48 AM, Steve Holden wrote:
Nick Coghlan wrote:
Barry Warsaw wrote:
On May 09, 2010, at 03:39 PM, Antoine Pitrou wrote:
Following discussion on python-dev, I plan to untabify the C codebase this afternoon. It would probably be better if nobody modified any C files in the meantime (except those that already use 4 space indents).
Thanks for doing something we've only been talking about for at least 10 years. :)
Indeed :)
Cheers, Nick.
And ever afterwards that time was known as the Epoch of the Great Untabification; and children heard stories of what programmers they had been.
fanciful-ly y'rs - steve
Who remembers the Great Renaming? :)
Wasn't it the /Grand/ Renaming?
Regards, Martin
Barry Warsaw wrote:
On May 11, 2010, at 09:20 PM, Martin v. Löwis wrote:
Barry Warsaw wrote:
Who remembers the Great Renaming? :)
Wasn't it the /Grand/ Renaming?
See Guido's link! (btw, what a great blog :).
While studying this history, I ran into
http://www.rmi.net/%7Elutz/errata-book-fixes.html
Mark Lutz calls it *both* Great and Grand renaming on a single page :-)
Regards, Martin
Martin v. Löwis wrote:
Barry Warsaw wrote:
On May 11, 2010, at 09:20 PM, Martin v. Löwis wrote:
Barry Warsaw wrote:
Who remembers the Great Renaming? :)
Wasn't it the /Grand/ Renaming?
See Guido's link! (btw, what a great blog :).
While studying this history, I ran into
http://www.rmi.net/%7Elutz/errata-book-fixes.html
Mark Lutz calls it *both* Great and Grand renaming on a single page :-)
Exceptionally pythonic.
regards Steve
On Tue, May 11, 2010 at 3:20 PM, "Martin v. Löwis" martin@v.loewis.de wrote:
Wasn't it the /Grand/ Renaming?
Rest assured, the Grand Renaming was a Great and Wondrous Event.
-Fred
Barry Warsaw wrote:
And ever afterwards that time was known as the Epoch of the Great Untabification; and children heard stories of what programmers they had been.
fanciful-ly y'rs - steve
Who remembers the Great Renaming? :)
Heh, I almost responded to Steve with "In before someone mentions the Great/Grand Renaming" (I wasn't here for it, but I did hear mention of it).
Cheers, Nick.
-
"Martin v. Löwis" -
A.M. Kuchling -
Alexandre Vassalotti -
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Fred Drake -
Gregory P. Smith -
Guido van Rossum -
Guilherme Polo -
Mark Dickinson -
Nick Coghlan -
Steve Holden -
Victor Stinner