Re: [Python-Dev] whitespace normalization
Neal Norwitz schrieb: > I just checked in a whitespace normalization change that was way too > big. Should this task be automated? > > Assuming the answer is yes, these are the questions should be answered: > 1) Which branches should this occur on: trunk, 2.5 (last release), 3k > 2) Should there be a special user for these checkins Absolutely, since that will be very helpful when doing "svn praise". > 3) How often should this be done Weekly makes sense. Of course, we could also setup a svn pre-commit hook that rejects trailing whitespace >:-> > 4) Are there any other tasks that can be automated > > My preferences are: > 1) all active branches (ie, trunk and currently 2.5 and p3yk) > 2) Yes, there should be a special user > 3) Once per week > 4) Not that I know of > > The way to fix the files is to run: python ./Tools/scripts/reindent.py -r Lib > At least that's what I did. Hopefully I didn't screw anything up. :-) I looked over it, and everything seems alright ;) Though I was impressed that we had some tab- and 2 space-indents lying around. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
"Neal Norwitz" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > I just checked in a whitespace normalization change that was way too > big. Should this task be automated? IMHO, changing whitespace retrospectively in a version control system is a bad idea. How much overhead would it be to have a checkin hook which compares each modified file against the output of running reindent.py over the same file and rejects the checkin if it changes anything? (With of course an appropriate message suggesting the use of Reindent.py before reatttempting the checkin). That way the whitespace ought to stay normalized so you shouldn't need a separate cleanup step and you won't be breaking diff and blame for the sources (and if the reindent does ever break anything it should be more tracable). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new metaclass error condition checks
Hi Jean-Paul, On Mon, Apr 16, 2007 at 06:53:20PM -0400, Jean-Paul Calderone wrote: > I just noticed r53997 (from some unit tests it broke), which disallowed things > like this: > > class X(object): > def __repr__(self): > return "blah" > > class Y(X, type): > pass > > class Z: > __metaclass__ = Y This is now valid again: I reverted r53997, as I got no answer to http://mail.python.org/pipermail/python-dev/2007-March/071796.html . A bientot, Armin. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
Duncan Booth wrote: > "Neal Norwitz" <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > >> I just checked in a whitespace normalization change that was way too >> big. Should this task be automated? > > IMHO, changing whitespace retrospectively in a version control system is a > bad idea. > > How much overhead would it be to have a checkin hook which compares each > modified file against the output of running reindent.py over the same file > and rejects the checkin if it changes anything? (With of course an > appropriate message suggesting the use of Reindent.py before reatttempting > the checkin). > > That way the whitespace ought to stay normalized so you shouldn't need a > separate cleanup step and you won't be breaking diff and blame for the > sources (and if the reindent does ever break anything it should be more > tracable). +1 Enforcing whitespace correctness on checkin has the added advantage that we will be able to screw another 1% out of uncle Timmy, who will no longer have to make his repeated whitespace correction checkins and will therefore have time for more productive tasks. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Recent Ramblings http://holdenweb.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
On Wednesday 25 April 2007, Steve Holden wrote: > Duncan Booth wrote: > > That way the whitespace ought to stay normalized so you shouldn't need a > > separate cleanup step and you won't be breaking diff and blame for the > > sources (and if the reindent does ever break anything it should be more > > tracable). > > +1 +1 here as well; there's no need to let things like this get out-of-sync from what we want. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
On Wed, Apr 25, 2007 at 08:40:22AM +0100, Duncan Booth wrote: > IMHO, changing whitespace retrospectively in a version control system is a > bad idea. In my experience Duncan's assertion is absolutely true, and all the more so in a project that maintains a large body of pending patches, as Python does. Spurious whitespaces changes in the repo will generate patch rejections that will drive both maintainers (as they check in a patch) and submitters (as they try to refresh patches against head) mad. I'm very much interested in VC systems *not* driving developers mad! Dustin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
Georg Brandl wrote: > Of course, we could also setup a svn pre-commit hook that rejects trailing > whitespace >:-> I was about to suggest a mail to python-checkins when a bad whitespace is detected, but had no idea that a pre-commit check existed in SVN. It'd be great if the system won't let you commit if whitespace is bad. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] some bug reviews
Hi, The following two bugs can be closed with possible document update. I have put my suggestions for doc changes in the SF tracker. -- http://python.org/sf/1615275 - tempile.TemporaryFile differences between linux and windows http://python.org/sf/1633941 - for line in sys.stdin: doesn't notice EOF the first time I opened 1643712 to request doc change for this bug. --- http://python.org/sf/1668596 - distutils chops the first character of filenames This one requires no action and can be closed, IMO. Thanks, Raghu ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
Facundo Batista schrieb: > Georg Brandl wrote: > >> Of course, we could also setup a svn pre-commit hook that rejects trailing >> whitespace >:-> > > I was about to suggest a mail to python-checkins when a bad whitespace > is detected, but had no idea that a pre-commit check existed in SVN. > > It'd be great if the system won't let you commit if whitespace is bad. Well, there are editors that don't intelligently strip whitespace, so that people using them would be constantly pained by such a hook. Things like two-space indents or tabs, however, should really be rejected IMO. Stripping the trailing whitespace automatically on checkin would also be fine, but I don't think that kind of thing is possible with SVN (also, it would mean that your WC is out of date after checkin). Geog -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
Steve Holden schrieb: > Duncan Booth wrote: >> "Neal Norwitz" <[EMAIL PROTECTED]> wrote in >> news:[EMAIL PROTECTED]: >> >>> I just checked in a whitespace normalization change that was way too >>> big. Should this task be automated? >> >> IMHO, changing whitespace retrospectively in a version control system is a >> bad idea. >> >> How much overhead would it be to have a checkin hook which compares each >> modified file against the output of running reindent.py over the same file >> and rejects the checkin if it changes anything? (With of course an >> appropriate message suggesting the use of Reindent.py before reatttempting >> the checkin). >> >> That way the whitespace ought to stay normalized so you shouldn't need a >> separate cleanup step and you won't be breaking diff and blame for the >> sources (and if the reindent does ever break anything it should be more >> tracable). > > +1 > > Enforcing whitespace correctness on checkin has the added advantage that > we will be able to screw another 1% out of uncle Timmy, who will no > longer have to make his repeated whitespace correction checkins and will > therefore have time for more productive tasks. As I said, this might be a pain for users of editors which don't strip indentation whitespace intelligently; e.g. if you write def foo(): print 1 print 2 there might be 4 spaces left on line 3. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
On 4/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Well, there are editors that don't intelligently strip whitespace, so that > people using them would be constantly pained by such a hook. And they should. There really is no excuse for letting one developer's poor choice of tools cause later grief for all other developers. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
[Neal Norwitz] > ... > The way to fix the files is to run: python ./Tools/scripts/reindent.py -r Lib I apply it to everything in the checkout. That is, I run reindent.py from the root of my sandbox, and use "." instead of "Lib". The goal is that every .py file (not just under Lib/) that eventually shows up in a release use whitespace consistently. > At least that's what I did. Hopefully I didn't screw anything up. :-) reindent.py has never been blamed for a "legitimate" screwup. On rare occasions it has broken tests, but only when the code mysteriously relied on significant trailing whitespace in the .py file. Such invisible dependence is considered (by me :-)) to be a bug in the code, not in reindent.py. The other no-brainer is to run Tools/scripts/svneol.py regularly. That finds text files that don't have the svn:eol-style property set, and sets it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
Neal Norwitz schrieb: > I just checked in a whitespace normalization change that was way too > big. Should this task be automated? > > Assuming the answer is yes, these are the questions should be answered: > 1) Which branches should this occur on: trunk, 2.5 (last release), 3k > 2) Should there be a special user for these checkins What *really* should be there is a pre-commit hook that rejects a checkin if the violates the formatting style in force. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
> Well, there are editors that don't intelligently strip whitespace, so that > people using them would be constantly pained by such a hook. Those users can run reindent.py before checking in, or switch editors. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] object.__init__
As a data point, I thought I'd point out that the recent object.__init__ change broke a handful of Twisted unit tests. The fix for this was simple, and I've already implemented it, but it would have been nice if the old behavior had been deprecated first and then removed, instead of just disappearing. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
Guido van Rossum schrieb: On 4/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote: Well, there are editors that don't intelligently strip whitespace, so that people using them would be constantly pained by such a hook. And they should. There really is no excuse for letting one developer's poor choice of tools cause later grief for all other developers. Okay, attached is a pre-commit hook script for that purpose. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. #!/usr/bin/env python SVNLOOK = '/usr/bin/svnlook' SCRIPTS_PATH = '/home/gbr/devel/python/Tools/scripts' import sys sys.path.insert(0, SCRIPTS_PATH) _, repos, txn = sys.argv from subprocess import Popen, PIPE from reindent import Reindenter from StringIO import StringIO def get_output(*command): popen = Popen(command, stdout=PIPE) stdout = popen.communicate()[0] if popen.returncode: sys.exit(1) else: return stdout bad = 0 for line in get_output(SVNLOOK, 'changed', '-t', txn, repos).splitlines(): filename = line[4:].strip() if not filename[-3:] == '.py': continue content = StringIO(get_output(SVNLOOK, 'cat', '-t', txn, repos, filename)) reindenter = Reindenter(content) if reindenter.run(): print >>sys.stderr, "file %s is not whitespace-normalized" % filename bad += 1 if bad: sys.exit(1) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 branch unfrozen
Lars Gustäbel schrieb: > On Sat, Apr 21, 2007 at 04:45:37PM +1000, Anthony Baxter wrote: >> Ok, things seem to be OK. So the release25-maint branch is unfrozen. >> Go crazy. Well, a little bit crazy. > > I'm afraid that I went crazy a little too early. Sorry for that. > Won't happen again. BTW, svn provides a "lock" mechanism by which the branch freezing could be enforced more strictly... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 branch unfrozen
On Wed, 25 Apr 2007 21:28:10 +0200, Georg Brandl <[EMAIL PROTECTED]> wrote: >Lars Gustäbel schrieb: >> On Sat, Apr 21, 2007 at 04:45:37PM +1000, Anthony Baxter wrote: >>> Ok, things seem to be OK. So the release25-maint branch is unfrozen. >>> Go crazy. Well, a little bit crazy. >> >> I'm afraid that I went crazy a little too early. Sorry for that. >> Won't happen again. > >BTW, svn provides a "lock" mechanism by which the branch freezing could >be enforced more strictly... It doesn't work on directories, though. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] object.__init__
2.6 isn't even in alpha. It's not too late to submit a patch that adds the deprecation; I'd be totally fine with that. On 4/25/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > > As a data point, I thought I'd point out that the recent object.__init__ > change > broke a handful of Twisted unit tests. The fix for this was simple, and I've > already implemented it, but it would have been nice if the old behavior had > been > deprecated first and then removed, instead of just disappearing. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 branch unfrozen
Jean-Paul Calderone schrieb: > On Wed, 25 Apr 2007 21:28:10 +0200, Georg Brandl <[EMAIL PROTECTED]> wrote: >>Lars Gustäbel schrieb: >>> On Sat, Apr 21, 2007 at 04:45:37PM +1000, Anthony Baxter wrote: Ok, things seem to be OK. So the release25-maint branch is unfrozen. Go crazy. Well, a little bit crazy. >>> >>> I'm afraid that I went crazy a little too early. Sorry for that. >>> Won't happen again. >> >>BTW, svn provides a "lock" mechanism by which the branch freezing could >>be enforced more strictly... > > It doesn't work on directories, though. Oh, didn't realize that. Thanks. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
>> Well, there are editors that don't intelligently strip whitespace, so >> that people using them would be constantly pained by such a hook. Guido> And they should. There really is no excuse for letting one Guido> developer's poor choice of tools cause later grief for all other Guido> developers. Just a little FYI, python-mode (the one Barry and I manage - dunno about the one distributed w/ GNU Emacs these days) is one of those tools that leaves trailing whitespace behind when advancing to the next line.. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
Tim> ... but only when the code mysteriously Tim> relied on significant trailing whitespace in the .py file. Maybe \s should expand to a single space by the lexer so people who want to rely on trailing spaces can be explicit about it. There already exists non-whitespace escape sequences for tabs and newlines. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attachment Policy?
Yaakov> i want to post a little bit of something I've been working on. Yaakov> Before I post it, i want to know if I'm allowed to post it as an Yaakov> attachment. Coming up, some work on ASTVisitor in the compiler Yaakov> module. If you're proposing that your change be included in Python please create a patch at SourceForge so it doesn't get lost: http://sourceforge.net/tracker/?group_id=5470&atid=305470 Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
[Skip] > Maybe \s should expand to a single space by the lexer so people who want to > rely on trailing spaces can be explicit about it. There already exists > non-whitespace escape sequences for tabs and newlines. Trailing whitspace is never significant on a code line, only inside a multiline string literal. In the extremely rare cases where one of those requires trailing spaces, \x20 works fine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
On 4/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Well, there are editors that don't intelligently strip whitespace, so > >> that people using them would be constantly pained by such a hook. > > Guido> And they should. There really is no excuse for letting one > Guido> developer's poor choice of tools cause later grief for all other > Guido> developers. > > Just a little FYI, python-mode (the one Barry and I manage - dunno about the > one distributed w/ GNU Emacs these days) is one of those tools that leaves > trailing whitespace behind when advancing to the next line.. Funny -- that's not my experience. Perhaps this depends on a separate Emacs setting? That's what I always assumed. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
skip> Just a little FYI, python-mode (the one Barry and I manage - dunno skip> about the one distributed w/ GNU Emacs these days) is one of those skip> tools that leaves trailing whitespace behind when advancing to the skip> next line.. At least so I thiought. I know I've seen these turds before, but a quick check wouldn't reproduce it... Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
[EMAIL PROTECTED] schrieb: > skip> Just a little FYI, python-mode (the one Barry and I manage - dunno > skip> about the one distributed w/ GNU Emacs these days) is one of those > skip> tools that leaves trailing whitespace behind when advancing to the > skip> next line.. > > At least so I thiought. I know I've seen these turds before, but a quick > check wouldn't reproduce it... This isn't my experience either. Also, there's always show-trailing-whitespace and trailing-whitespace-face... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 25, 2007, at 2:37 PM, [EMAIL PROTECTED] wrote: >>> Well, there are editors that don't intelligently strip >>> whitespace, so >>> that people using them would be constantly pained by such a hook. > > Guido> And they should. There really is no excuse for letting one > Guido> developer's poor choice of tools cause later grief for > all other > Guido> developers. > > Just a little FYI, python-mode (the one Barry and I manage - dunno > about the > one distributed w/ GNU Emacs these days) is one of those tools that > leaves > trailing whitespace behind when advancing to the next line.. Maybe we should include this function in the mode: ;; untabify and clean up lines with just whitespace (defun baw-whitespace-normalization () "Like untabify, but also cleans up lines with trailing whitespace." (interactive) (save-excursion (save-restriction (untabify (point-min) (point-max)) (goto-char (point-min)) (while (re-search-forward "[ \t]+$" nil t) (let ((bol (save-excursion (beginning-of-line) (point))) (eol (save-excursion (end-of-line) (point (goto-char (match-beginning 0)) (if (and (bolp) (eq (char-after) ?\ )) (forward-char 1)) (skip-chars-backward " \t" bol) (delete-region (point) eol) )) ;; Now clean up any trailing blank lines (goto-char (point-max)) (skip-chars-backward " \t\n") (if (not (bolp)) (forward-char 1)) (delete-region (point) (point-max)) ;; But make sure the files ends in a newline (if (not (bolp)) (newline)) ))) (defalias 'baw-normalize-whitespace 'baw-whitespace-normalization) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRi+2y3EjvBPtnXfVAQKyCAP5AUwHxTgOCRkkgCRfAP/oWCxf1WT/Y1lk PUrb4eRaR2s5B8XP417V3O/uMPHfiQr9Ci1txoIuq22PRbPvOFT4bfSYXFxPrrGS FOlvivpE8rnXSxv4bJC/3B11GNDoyQJds8D4/13XIZXnFE4W2WtyA0fG1kxQXBEc gvjk/FXuRS8= =3Wll -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 branch unfrozen
"Georg Brandl" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Jean-Paul Calderone schrieb: | > On Wed, 25 Apr 2007 21:28:10 +0200, Georg Brandl <[EMAIL PROTECTED]> wrote: | >>Lars Gustäbel schrieb: | >>> On Sat, Apr 21, 2007 at 04:45:37PM +1000, Anthony Baxter wrote: | Ok, things seem to be OK. So the release25-maint branch is unfrozen. | Go crazy. Well, a little bit crazy. | >>> | >>> I'm afraid that I went crazy a little too early. Sorry for that. | >>> Won't happen again. | >> | >>BTW, svn provides a "lock" mechanism by which the branch freezing could | >>be enforced more strictly... | > | > It doesn't work on directories, though. | | Oh, didn't realize that. Thanks. Does the SVN tracker (presuming there is one) take RFEs? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 branch unfrozen
On Wed, Apr 25, 2007 at 05:00:42PM -0400, Terry Reedy wrote: > Does the SVN tracker (presuming there is one) take RFEs? http://subversion.tigris.org/project_issues.html But I would expect that this proposal will not pass the "buddy system" (which is a cute idea IMHO), as locking is counter to the Subversion Way. Also, you could accomplish what you want (a locked branch) with a pre-commit hook that just scans for paths in that branch. Dustin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | On 4/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote: | > Well, there are editors that don't intelligently strip whitespace, so that | > people using them would be constantly pained by such a hook. | | And they should. There really is no excuse for letting one developer's | poor choice of tools cause later grief for all other developers. In 2.4.3, IDLE leaves trailing whitespace as is, even where senseless :-( I'll check the 2.5.1 version when I install it. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
On 08:15 pm, [EMAIL PROTECTED] wrote: ;; untabify and clean up lines with just whitespace (defun baw-whitespace-normalization () Looks a lot like (whitespace-cleanup), if you've got the right configuration. A function I've used many times :). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 branch unfrozen
> But I would expect that this proposal will not pass the "buddy system" > (which is a cute idea IMHO), as locking is counter to the Subversion > Way. > > Also, you could accomplish what you want (a locked branch) with a > pre-commit hook that just scans for paths in that branch. I think "social engineering" is the appropriate way of dealing with frozen code bases. IMHO, committers do need to consider release mechanics in each and every commit (anticipating the demands of release engineering whether or not a release is immanent); it's not a bad thing if commits get rolled back because the committer violated some constraints of the release manager. The 2.5.1 release happened to reveal some misunderstandings as to how subversion is used in the release process; having these issues cleared up was well worth the trouble. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
[Skip] > Just a little FYI, python-mode (the one Barry and I manage - dunno about the > one distributed w/ GNU Emacs these days) is one of those tools that leaves > trailing whitespace behind when advancing to the next line.. Shouldn't be -- unless the behavior of the Emacs newline-and-indent has changed. The pymode version (py-newline-and-indent) relies in part on newline-and-indent; the intent is documented in the py-newline-and-indent docstring: (defun py-newline-and-indent () "... In general, deletes the whitespace before point, inserts a newline, and takes an educated guess as to how you want the new line indented." IIRC, pymode leaves C-j bound to plain old newline, so if you're in the habit of starting a new line via C-j no changes of any kind are made to whitespace. But that's not the intended way to use pymode. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
[EMAIL PROTECTED] wrote: > Just a little FYI, python-mode (the one Barry and I manage - dunno about the > one distributed w/ GNU Emacs these days) is one of those tools that leaves > trailing whitespace behind when advancing to the next line.. I get extremely annoyed with editors that *don't* leave whitespace at the end of lines alone, at least while you're working on the file. You type part of a line, leave a space, go to copy something from somewhere else to put on the end, and when you get back, the space you deliberately left there is gone. Stripping trailing whitespace on saving wouldn't be so bad, though. Is there an option for that in python-mode? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
>> Just a little FYI, python-mode (the one Barry and I manage - dunno >> about the one distributed w/ GNU Emacs these days) is one of those >> tools that leaves trailing whitespace behind when advancing to the >> next line.. (See my earlier retraction...) Greg> I get extremely annoyed with editors that *don't* leave whitespace Greg> at the end of lines alone, at least while you're working on the Greg> file. You type part of a line, leave a space, go to copy something Greg> from somewhere else to put on the end, and when you get back, the Greg> space you deliberately left there is gone. That's not the way python-mode works. If I enter this: def f(a): b = a * a @ % then hit LF or RET after the statement, it inserts a newline and inserts enough spaces to leave the cursor where I placed the @ sign. If I hit another LF or RET it removes the "trailing" whitespace on the current line, enters a newline and inserts enough spaces to leave the cursor where I placed the % sign. Greg> Stripping trailing whitespace on saving wouldn't be Greg> so bad, though. Is there an option for that in python-mode? Not by default. You could add a hook to write-file-hooks though. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
> Okay, attached is a pre-commit hook script for that purpose.
How does that deal with deletions? What do you think about
the attached alternative?
Regards,
Martin
#!/usr/bin/env python
from svn import repos, fs, core
import sys
from StringIO import StringIO
from reindent import Reindenter
repos_handle = repos.open(sys.argv[1])
fs_handle = repos.fs(repos_handle)
txn_handle = fs.open_txn(fs_handle, sys.argv[2])
txn_root = fs.txn_root(txn_handle)
interesting_changes = (fs.path_change_add, fs.path_change_replace,
fs.path_change_modify)
bad = 0
for path, change in fs.paths_changed(txn_root).iteritems():
if not path.endswith('.py'):continue
if change.change_kind not in interesting_changes: continue
if not change.text_mod: continue
content = StringIO()
file = fs.file_contents(txn_root, path)
while 1:
data = core.svn_stream_read(file, 10)
if not data: break
content.write(data)
content.seek(0)
reindenter = Reindenter(content)
if reindenter.run():
print >>sys.stderr, "file %s is not whitespace-normalized" % path
bad += 1
if bad:
sys.exit(1)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
Martin v. Löwis schrieb: >> Okay, attached is a pre-commit hook script for that purpose. > > How does that deal with deletions? Ah, you'd have to look at the first two chars of every lines that I cut away. > What do you think about > the attached alternative? I'd say it's better since it uses the Python SVN bindings instead of calling external programs... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
