Le mardi 04 mai 2010 07:12:32, Martin v. Löwis a écrit :
Will changing the indentation of source files to 4 space indents break
patches on the bug tracker?
Plain patch will choke, but patch -l might accept them.
Tested on posixmodule.c: it works :-)
--
Victor Stinner
On Thu, May 6, 2010 at 08:09, Ronald Oussoren ronaldousso...@mac.comwrote:
On 5 May, 2010, at 22:56, Brett Cannon wrote:
I am done running the analysis over trunk. I will not svnmerge these
changes into py3k as the amount of time and effort that would take equates
to running the static
I am done running the analysis over trunk. I will not svnmerge these changes
into py3k as the amount of time and effort that would take equates to
running the static analyzer again just before 3.2 is released and possibly
catching more changes (and maybe even a newer version of Clang at that
Le mardi 04 mai 2010 00:37:22, Brett Cannon a écrit :
Since 2.7 is probably going to exist for a while, I am running Clang 2.7's
static analyzer (``clang --static``) over trunk. It's mostly just finding
stuff like unneeded variable initialization or variables that are never
used (compilation
On Wed, May 5, 2010 at 14:01, Victor Stinner
victor.stin...@haypocalc.comwrote:
Le mardi 04 mai 2010 00:37:22, Brett Cannon a écrit :
Since 2.7 is probably going to exist for a while, I am running Clang
2.7's
static analyzer (``clang --static``) over trunk. It's mostly just finding
stuff
Le mardi 04 mai 2010 04:34:13, Barry Warsaw a écrit :
Now would be a good time to convert the C files to 4 space indents. (...)
I think we only need to convert the py3k branch though.
It will make the port of patches (commits) between trunk and py3k much harder.
Can you explain why do you want
On May 04, 2010, at 07:16 AM, Martin v. Löwis wrote:
I think Mercurial chokes in the light of white space inconsistencies
just as much as Subversion. One reason for not converting in the past
was also that it would break merging, unless that whitespace
normalization is applied to all these
Barry Warsaw barry at python.org writes:
Then let's do py3k and release31-maint, or whatever they will be called under
hg. Once 2.7 is released and we're on hg, how much back porting of revisions
from Python 3 - 2 is going to happen?
Probably quite a bit still; all C extension bug fixes for
On Tue, May 4, 2010 at 14:41, Antoine Pitrou solip...@pitrou.net wrote:
I think we should reindent all 3 branches. Most of the work can probably be
scripted (str.replace(\t, * 4)), and then a visual pass is necessary to
fix vertical alignments and the like.
If the script is robust enough, I
Dirkjan Ochtman wrote:
On Tue, May 4, 2010 at 14:41, Antoine Pitrou solip...@pitrou.net wrote:
I think we should reindent all 3 branches. Most of the work can probably be
scripted (str.replace(\t, * 4)), and then a visual pass is necessary to
fix vertical alignments and the like.
If the
Le mardi 04 mai 2010 14:41:42, Antoine Pitrou a écrit :
Barry Warsaw barry at python.org writes:
Then let's do py3k and release31-maint, or whatever they will be called
under hg. Once 2.7 is released and we're on hg, how much back porting of
revisions from Python 3 - 2 is going to happen?
On May 4, 2010, at 8:41 AM, Antoine Pitrou wrote:
I think we should reindent all 3 branches. Most of the work can probably be
scripted (str.replace(\t, * 4)), and then a visual pass is necessary to
fix vertical alignments and the like.
I think we should reindent all 3 branches. Most of
Victor Stinner wrote:
We should also add pre-commit scripts to avoid the reintroduction of
tabulations in C (and Python?) files.
Python and ReST files are already covered (with reindent.py and
reindent-rst.py to fix any files that get mixed up).
make patchcheck includes the precommit checks
Zvezdan Petkovic wrote:
So, the question is what bothers developers more:
- old C files with tab indentation, or
- a lot of changes in version control to fix them?
Both?
C files that mix tabs and spaces are actually the main source of pain
when editing :)
Cheers,
Nick.
--
Nick Coghlan
Since 2.7 is probably going to exist for a while, I am running Clang 2.7's
static analyzer (``clang --static``) over trunk. It's mostly just finding
stuff like unneeded variable initialization or variables that are never used
(compilation is picking up unused returned values, almost all from
2010/5/3 Brett Cannon br...@python.org:
Since 2.7 is probably going to exist for a while, I am running Clang 2.7's
static analyzer (``clang --static``) over trunk. It's mostly just finding
stuff like unneeded variable initialization or variables that are never used
(compilation is picking up
Benjamin Peterson benjamin at python.org writes:
2010/5/3 Brett Cannon brett at python.org:
When I check in these changes I will do it file by file, but my
question is
how to handle Misc/NEWS. I have gone through the underscores and the
'a's in
Modules and already have six modified
I'll just do a single entry saying that the static analyzer was used and not
list the files.
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
On May 3, 2010 4:00 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit :
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
Would it be finally time to standardize all C files on a 4-spaces
indentation rule?
I understand the
Antoine Pitrou wrote:
Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit :
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
Would it be finally time to standardize all C files on a 4-spaces
indentation
On May 03, 2010, at 10:12 PM, Steve Holden wrote:
Antoine Pitrou wrote:
Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit :
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
Would it be finally time to
On Mon, May 3, 2010 at 7:34 PM, Barry Warsaw ba...@python.org wrote:
Now would be a good time to convert the C files to 4 space indents. We've
only been talking about it for a decade at least.
Will changing the indentation of source files to 4 space indents break
patches on the bug tracker?
Will changing the indentation of source files to 4 space indents break
patches on the bug tracker?
Plain patch will choke, but patch -l might accept them. I have only
read the documentation, though, and don't know whether it does in practice.
Regards,
Martin
Steve Holden wrote:
Antoine Pitrou wrote:
Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit :
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
Would it be finally time to standardize all C files on a
24 matches
Mail list logo
