Re: [Python-Dev] Static analysis of CPython using coccinelle/spatch

A.M. Kuchling wrote: On Mon, Nov 16, 2009 at 03:27:53PM -0500, David Malcolm wrote: Has anyone else looked at using Coccinelle/spatch[1] on CPython source code? For an excellent explanation of Coccinelle, see . For those who have not looked, Coccinelle means

Re: [Python-Dev] 2.7 and 3.2 release schedules

Barry Warsaw python.org> writes: > > > If no one else wants to try and ruin Python 3, I'll do it . > > Ha ha ha^H^H^H^H^H^H^H^H^HGreat! Benjamin's the expert now, but I'm > here to help if needed. Well Georg isn't a novice when it comes to ruining things, especially documentation and commit

Re: [Python-Dev] 2.7 and 3.2 release schedules

On Nov 17, 2009, at 4:55 PM, Georg Brandl wrote: Benjamin Peterson schrieb: After more thought, I think that separating the 2.7 and 3.2 releases is not as big of an issue as I once thought. Therefore, I'd like to adopt the schedule I posted a few weeks back for 2.7 only. This only means some o

Re: [Python-Dev] 2.7 and 3.2 release schedules

Benjamin Peterson schrieb: > After more thought, I think that separating the 2.7 and 3.2 releases > is not as big of an issue as I once thought. Therefore, I'd like to > adopt the schedule I posted a few weeks back for 2.7 only. > > This only means some other lucky victi... I mean volunteer can do

Re: [Python-Dev] Static analysis of CPython using coccinelle/spatch

On Mon, Nov 16, 2009 at 03:27:53PM -0500, David Malcolm wrote: > Has anyone else looked at using Coccinelle/spatch[1] on CPython source > code? For an excellent explanation of Coccinelle, see . --amk ___ Python-Dev maili

Re: [Python-Dev] Static analysis of CPython using coccinelle/spatch

On Mon, Nov 16, 2009 at 12:27, David Malcolm wrote: > Has anyone else looked at using Coccinelle/spatch[1] on CPython source > code? Not that has been mentioned on the list before. > > It's a GPL-licensed tool for matching semantic patterns in C source > code. It's been used on the Linux kernel

Re: [Python-Dev] new unbounded memory leak in exception handling?

On Tue, Nov 17, 2009 at 08:40:37AM -0500, R. David Murray wrote: > I think you want to take a look at PEP 3134. And then please file a doc > bug to have someone update the documentation of sys.exc_info, since the > advice in the warning box is no longer valid in Python 3. Thanks for the pointer,

Re: [Python-Dev] Add an optional timeout to lock operations

Guido van Rossum python.org> writes: > > I think the number of platforms > has dwindled to two or three (Posix, Windows, and maybe one minority > OS?), so now's the time to do it. (IOW I think the idea of the patch > is fine.) Thanks. (the minority OS would be OS/2, I think) > Will locks be int

Re: [Python-Dev] Add an optional timeout to lock operations

I think I can answer the "why" question: thread.c is *very* old code, in fact it predates the posix threads standard. When we (actually Sjoerd Mullender) wrote it, we had a number of OS-specific locking APIs to work with and the API was designed to fit all of them. I don't even recall the initial s

Re: [Python-Dev] new unbounded memory leak in exception handling?

On Tue, 17 Nov 2009 at 10:31, Greg Hewgill wrote: I've constructed an example program that does not leak memory in Python 2.x, but causes unbounded memory allocation in Python 3.1. Here is the code: import gc import sys class E(Exception): def __init__(self, fn): self.fn = fn def c

[Python-Dev] Add an optional timeout to lock operations

Hello, I've submitted a patch (*) to add an optional timeout to locking operations (Lock.acquire() etc.). Since it's a pretty basic functionality, I would like to know if there was any good reason for not doing it. (*) http://bugs.python.org/issue7316 Thank you Antoine. _

[Python-Dev] new unbounded memory leak in exception handling?

I've constructed an example program that does not leak memory in Python 2.x, but causes unbounded memory allocation in Python 3.1. Here is the code: import gc import sys class E(Exception): def __init__(self, fn): self.fn = fn def call(self): self.fn() def f(): raise