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 the
"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 t
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):
>
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
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 mo
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
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 yo
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
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.
>
>
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
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 gr
[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 eventua
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 the
> 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 li
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 disappea
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 choi
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,
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 th
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
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 li
>> 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
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
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
[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 st
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> d
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 th
[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 lea
-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
"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, th
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
"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
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 :).
___
Py
> 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
[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
[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* leav
>> 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 extremel
> 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
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 t
38 matches
Mail list logo
