On Fri, Oct 10, 2008 at 9:46 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
>>
>> On Fri, Oct 10, 2008 at 1:45 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
>>> The advantage of the decorator version is that the compiler or module
>>> loader
>>> could be special cased to recognize
Brett Cannon wrote:
On Fri, Oct 10, 2008 at 1:45 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
The advantage of the decorator version is that the compiler or module loader
could be special cased to recognize the 'C' decorator and try it first
*before* using the Python version, which would serve a
Terry Reedy wrote:
> Jim Jewett wrote:
>> Nick Coghlan's explanation of what justifies a syntax change (most of
>> message
>> http://mail.python.org/pipermail/python-dev/2008-October/082831.html )
>> should probably be added to the standard docs/FAQs somewhere.
>
> I agree that this was a helpful
It seems to me that Skip was asking whether the "memory leak" impacted
the 2.6 branch, and the answer should have been "No": the change that
introduced the memory leak had just been committed 10 minutes before.
You are probably right (although it's not quite clear from Skip's question).
On Fri, Oct 10, 2008 at 1:45 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>>
>> On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote:
>>>
>>> Background
>>> --
>>> In the itertools module docs, I included pure python equivalents for each
>>> of the C functions. Necessarily,
Jim Jewett wrote:
Nick Coghlan's explanation of what justifies a syntax change (most of message
http://mail.python.org/pipermail/python-dev/2008-October/082831.html )
should probably be added to the standard docs/FAQs somewhere.
I agree that this was a helpful explanation. A link to the origin
[EMAIL PROTECTED] wrote:
On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote:
Background
--
In the itertools module docs, I included pure python equivalents for
each of the C functions. Necessarily, some of those equivalents are
only approximate but they seem to have greatly enhanced the doc
On Fri, Oct 10, 2008 at 8:51 AM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Nick Coghlan's explanation of what justifies a syntax change (most of message
> http://mail.python.org/pipermail/python-dev/2008-October/082831.html )
> should probably be added to the standard docs/FAQs somewhere.
>
> At the
On Thu, Oct 9, 2008 at 8:37 PM, <[EMAIL PROTECTED]> wrote:
>
> On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote:
>>
>> Background
>> --
>> In the itertools module docs, I included pure python equivalents for each
>> of the C functions. Necessarily, some of those equivalents are only
>> approxi
In http://mail.python.org/pipermail/python-dev/2008-October/082994.html
Martin v. Löwis wrote:
> So 2.6.0 will contain a lot of tests that have never been tested in
> a wide variety of systems. Some are incorrect, and get fixed in 2.6.1,
> and stay fixed afterwards. This is completely different fr
ACTIVITY SUMMARY (10/03/08 - 10/10/08)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2105 open (+49) / 13818 closed (+21) / 15923 total (+70)
Open issues with patches: 690
Average
Nick Coghlan's explanation of what justifies a syntax change (most of message
http://mail.python.org/pipermail/python-dev/2008-October/082831.html )
should probably be added to the standard docs/FAQs somewhere.
At the moment, I'm not sure exactly where, though. At the moment, the
Developer FAQ (h
On Fri, Oct 10, 2008 at 08:44:38AM +0200, "Martin v. Löwis" wrote:
> So 2.6.0 will contain a lot of tests that have never been tested in
> a wide variety of systems. Some are incorrect, and get fixed in 2.6.1,
> and stay fixed afterwards. This is completely different from somebody
> introducing a n
> For the search engine issue, is there any way we can tell robots to
> ignore the rewrite rules so they see the broken links? (although even
> that may not be ideal, since what we really want is to tell the robot
> the link is broken, and provide the new alternative)
I may be missing something ob
> > Correct. But they might well be broken, no?
>
> I would hope some effort is made that they not be. If they generate a
> positive, I would expect that the contributor would try to fix that
> before committing, no? If they discover that it's "false", they fix
> or remove the test; otherwise t
15 matches
Mail list logo
