On Mon, Nov 8, 2010 at 11:03 PM, "Martin v. Löwis" wrote:
> Am 08.11.2010 14:19, schrieb Fredrik Lundh:
>> On Mon, Nov 8, 2010 at 2:17 PM, Antoine Pitrou wrote:
>>> Le lundi 08 novembre 2010 à 14:10 +0100, Fredrik Lundh a écrit :
One would have thought that "test cases" referred to test
Am 08.11.2010 14:19, schrieb Fredrik Lundh:
> On Mon, Nov 8, 2010 at 2:17 PM, Antoine Pitrou wrote:
>> Le lundi 08 novembre 2010 à 14:10 +0100, Fredrik Lundh a écrit :
>>>
>>> One would have thought that "test cases" referred to test cases, not
>>> strings in non-test code, and that the "the stdli
> We don't gain anything by not implementing automation.
I certainly gain something: spare time where I can work on other stuff
than fulfilling infrastructure wishes of people.
Regards,
Martin
___
python-committers mailing list
python-committers@python.
On 08/11/2010 17:28, David Malcolm wrote:
On Mon, 2010-11-08 at 12:22 +, Michael Foord wrote:
On 08/11/2010 12:18, Łukasz Langa wrote:
Am 08.11.2010 12:55, schrieb Michael Foord:
On 08/11/2010 11:42, Senthil Kumaran wrote:
We can just customize our environments. It is easy.
I already poi
On Mon, 2010-11-08 at 12:22 +, Michael Foord wrote:
> On 08/11/2010 12:18, Łukasz Langa wrote:
> > Am 08.11.2010 12:55, schrieb Michael Foord:
> >> On 08/11/2010 11:42, Senthil Kumaran wrote:
> >>> We can just customize our environments. It is easy.
> >
> > I already pointed out in my last post
Am 08.11.2010 15:30, schrieb Łukasz Langa:
> Am 08.11.2010 15:04, schrieb Benjamin Peterson:
>> I don't think you can ever automate "checking for mistakes" out of the
>> workflow. There will never be a commit hook that checks whether you
>> created a race condition or deference possibly uninitializ
Am 08.11.2010 15:04, schrieb Benjamin Peterson:
I don't think you can ever automate "checking for mistakes" out of the
workflow. There will never be a commit hook that checks whether you
created a race condition or deference possibly uninitialized memory.
That goes without saying. Then again, w
2010/11/8 Łukasz Langa :
> Am 07.11.2010 19:28, schrieb Benjamin Peterson:
>>
>> 2010/11/7 Victor Stinner:
>>>
>>> I would like to know if it would be
>>> possible to block a commit introducing nonbreaking spaces? A least for me
>>> :-)
>>
>> I don't think add pre-commit hooks for every conceivable
On Mon, Nov 8, 2010 at 2:17 PM, Antoine Pitrou wrote:
> Le lundi 08 novembre 2010 à 14:10 +0100, Fredrik Lundh a écrit :
>>
>> One would have thought that "test cases" referred to test cases, not
>> strings in non-test code, and that the "the stdlib is already supposed
>> to be ASCII only" meant t
Le lundi 08 novembre 2010 à 14:10 +0100, Fredrik Lundh a écrit :
>
> One would have thought that "test cases" referred to test cases, not
> strings in non-test code, and that the "the stdlib is already supposed
> to be ASCII only" meant that the standard library is supposed to be
> ASCII only, not
On Mon, Nov 8, 2010 at 1:59 PM, Nick Coghlan wrote:
> On Mon, Nov 8, 2010 at 10:55 PM, Michael Foord
> wrote:
>> On 08/11/2010 12:53, Nick Coghlan wrote:
>>>
>>> [snip...]
>>> Non-breaking spaces are legal in utf-8 encoded Python source files.
>>> While including them accidentally is less than i
On 08/11/2010 12:59, Nick Coghlan wrote:
On Mon, Nov 8, 2010 at 10:55 PM, Michael Foord wrote:
On 08/11/2010 12:53, Nick Coghlan wrote:
[snip...]
Non-breaking spaces are legal in utf-8 encoded Python source files.
While including them accidentally is less than ideal, it is perfectly
valid to i
On Mon, Nov 8, 2010 at 10:55 PM, Michael Foord wrote:
> On 08/11/2010 12:53, Nick Coghlan wrote:
>>
>> [snip...]
>> Non-breaking spaces are legal in utf-8 encoded Python source files.
>> While including them accidentally is less than ideal, it is perfectly
>> valid to include them deliberately. Tr
On 08/11/2010 12:53, Nick Coghlan wrote:
[snip...]
Non-breaking spaces are legal in utf-8 encoded Python source files.
While including them accidentally is less than ideal, it is perfectly
valid to include them deliberately. Trying to design an automated
check that can make a reasonable guess at
On Mon, Nov 8, 2010 at 10:53 PM, Nick Coghlan wrote:
> Non-breaking spaces are legal in utf-8 encoded Python source files.
> While including them accidentally is less than ideal, it is perfectly
> valid to include them deliberately. Trying to design an automated
> check that can make a reasonable
On Mon, Nov 8, 2010 at 10:33 PM, Antoine Pitrou wrote:
> I personally don't care whether we deny non-breaking spaces or not. I
> see no reason to deny them, since the cause of the test_trace failure
> was ultimately a bug in the trace module, and the non-breaking space
> actually uncovered this bu
2010/11/8 Michael Foord :
> You mean `make patchcheck` isn't *already* part of your workflow?
Seems easier to me if I don't have to issue a separate command for it...
Cheers,
Dirkjan
___
python-committers mailing list
python-committers@python.org
http:
> Automation always pays off. Simplifying the process always pays off.
> Providing yet another step to the workflow would be a move in the
> opposite direction*. Is there any point in weighing each time whether a
> mistake is common enough to be included in the commit hooks? It's not
> like we
On 08/11/2010 12:18, Łukasz Langa wrote:
Am 08.11.2010 12:55, schrieb Michael Foord:
On 08/11/2010 11:42, Senthil Kumaran wrote:
We can just customize our environments. It is easy.
I already pointed out in my last post why that's not going to solve
the problem.
Additional checks could be p
Am 08.11.2010 12:55, schrieb Michael Foord:
On 08/11/2010 11:42, Senthil Kumaran wrote:
We can just customize our environments. It is easy.
I already pointed out in my last post why that's not going to solve the
problem.
Additional checks could be put in `make patchcheck` or a local commit
2010/11/8 Senthil Kumaran :
> On Mon, Nov 08, 2010 at 11:55:39AM +0100, Łukasz Langa wrote:
>> Even if that commit hook prevents a single wrong commit a year, it's
>> worth it. As unpaid volunteers, we don't have time for hunting the
>> same mistakes twice.
>
> For common mistakes, there are commit
On 08/11/2010 11:42, Senthil Kumaran wrote:
On Mon, Nov 08, 2010 at 11:55:39AM +0100, Łukasz Langa wrote:
Even if that commit hook prevents a single wrong commit a year, it's
worth it. As unpaid volunteers, we don't have time for hunting the
same mistakes twice.
For common mistakes, there are c
On Mon, Nov 08, 2010 at 11:55:39AM +0100, Łukasz Langa wrote:
> Even if that commit hook prevents a single wrong commit a year, it's
> worth it. As unpaid volunteers, we don't have time for hunting the
> same mistakes twice.
For common mistakes, there are commit hooks which prevent you from
commit
2010/11/8 Łukasz Langa :
> I see you're basically saying "We're all adults here" and that we should be
> able to control our own environment so these kinds of commits don't happen
> (like Guido said). Well guess what, I believe that isn't going to work. Let
> me tell you why.
I must say I kind of
Am 07.11.2010 19:28, schrieb Benjamin Peterson:
2010/11/7 Victor Stinner:
I would like to know if it would be
possible to block a commit introducing nonbreaking spaces? A least for me :-)
I don't think add pre-commit hooks for every conceivable mistake is
the right way to go.
I see you're bas
2010/11/7 Victor Stinner :
> Hi,
>
> I introduced nonbreaking spaces in Lib/os.py in a comment, because I kept Alt
> Gr. key pressed to write the space after # (stupid Xorg keyboard variant!).
>
> This change introduces a strange bug in "LANG=C ./python -m test.regrtest -v
> test_imp test_trace" co
Hm, tricky, the stdlib is already supposed to be ASCII only except for
author names in comments and a few specific encoding test cases. But
since your non-breaking space was in a comment you'd have to add
another exception to whatever checker exists.
How about fixing your personal tool chain so it
Hi,
I introduced nonbreaking spaces in Lib/os.py in a comment, because I kept Alt
Gr. key pressed to write the space after # (stupid Xorg keyboard variant!).
This change introduces a strange bug in "LANG=C ./python -m test.regrtest -v
test_imp test_trace" command.
The real bug was fixed in iss
28 matches
Mail list logo
