Am 03.05.2010 18:40, schrieb Guido van Rossum:
> On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw wrote:
>> On May 01, 2010, at 07:12 AM, Martin v. Löwis wrote:
>>
IIRC in the IETF this is done by the committee chair. I think it's a
good idea to have this be a single person to avoid endless
Le mercredi 05 mai 2010 00:41:04, Nick Coghlan a écrit :
> Howver, if we delay fixing the C file indentation until we're already on
> hg, the merge tools should offer the best chance of being able to apply
> pre-fix patches and have the software figure out where the whitespace
> changes need to be
Le mercredi 05 mai 2010 à 08:41 +1000, Nick Coghlan a écrit :
>
> Howver, if we delay fixing the C file indentation until we're already on
> hg, the merge tools should offer the best chance of being able to apply
> pre-fix patches and have the software figure out where the whitespace
> changes nee
Eric Smith wrote:
> 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 an
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
Le Tue, 04 May 2010 11:27:58 -0400, Zvezdan Petkovic a écrit :
>
> A simple replacement of a tab with 4 spaces as you propose does not work
> on such a code.
Right, I was simplifying a bit.
I've just written a script which does a slightly more elaborate
reindentation of C files, but still with
Hi,
I'm sorry I neglected to mention this before. I'm delaying all 2.7
releases a week because of beta 1's lateness. I've now updated PEP
373. So, beta 2 will be this Saturday.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http:
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 01:24:37, Antoine Pitrou a écrit :
> 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
Le mardi 04 mai 2010 01:24:37, Antoine Pitrou a écrit :
> Would it be finally time to standardize all C files on a 4-spaces
> indentation rule?
Indentation is painful on some files mixing tabs and spaces (sometimes in the
same function!).
> I understand the "svn annotate" argument, but we edit c
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
18 matches
Mail list logo
