On Thu, May 6, 2010 at 08:09, Ronald Oussoren wrote:
>
> 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 analyzer again just b
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 analyzer again just before 3.2 is released and possibly catching
> more chan
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
http://www.ha
On Wed, May 5, 2010 at 14:01, Victor Stinner
wrote:
> 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 variabl
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 (compilatio
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
point)
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 Cog
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 check
On Tue, May 4, 2010 at 08:27, Zvezdan Petkovic wrote:
> 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 t
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.
Le mardi 04 mai 2010 14:41:42, Antoine Pitrou a écrit :
> Barry Warsaw 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?
Dirkjan Ochtman wrote:
On Tue, May 4, 2010 at 14:41, 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.
If the script is robust en
On Tue, May 4, 2010 at 14:41, 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.
If the script is robust enough, I can run it as
Barry Warsaw 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 ex
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 bra
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 wan
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
> 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
On Mon, May 3, 2010 at 7:34 PM, Barry Warsaw 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?
-- Alexandre
___
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 finall
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
> indent
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
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" wrote:
Benjamin Peterson pyth
Benjamin Peterson python.org> writes:
>
> 2010/5/3 Brett Cannon 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 files, so the
2010/5/3 Brett Cannon :
> 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 returne
25 matches
Mail list logo
