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/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
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
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
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
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
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
> 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
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:
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
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 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: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: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 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
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 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
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
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
On Nov 06, 2010, at 03:34 PM, Georg Brandl wrote:
>on a request by Martin, I added another alpha to the Python 3.2 release
>schedule. The scheduled releases are now
>
>- 3.2 alpha 4: November 13, 2010
>- 3.2 beta 1: December 4, 2010
>- 3.2 beta 2: December 18, 2010
>- 3.2 candidate 1: January 8,
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
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
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 Sun, Nov 7, 2010 at 21:47, Terry Reedy wrote:
> Wanting to finish up the difflib issue (#2986) with my first commits, I read
> http://www.python.org/dev/faq/
> (especially 2.2.2 and 2.3), loaded TortoiseSVN, and successfully did a
> read-only checkout. But when I try to do the needed read-write
, Terry.
A request to email my password again, in case it was automatically
changed, also failed.
Terry
BEGIN SSH2 PUBLIC KEY
Comment: "py-dsa-key-20101108"
B3NzaC1kc3MAAACBANQpuD8eeC7QMvLEgmJyqnuqheOJHwU9Up
On Mon, 08 Nov 2010 14:24:57 -0500, Terry Reedy wrote:
> A request to email my password again, in case it was automatically
> changed, also failed.
Are you sure you are using the email address under which you
are subscribed?
--
R. David Murray www.bitdance.c
On Mon, Nov 8, 2010 at 11:24, Terry Reedy wrote:
>
>> Just reply to your email with your new public key attached. There are
>> a couple of us that can replace your old key.
>
> Here. I also sent it to Martin an hour or so ago.
Done, although I had to manually alter the format to be correct so let
> 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.
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
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
30 matches
Mail list logo
