Re: [Python-Dev] Strange segfault in Python threads and linux kernel 2.6

On Thursday 20 January 2005 12:43, Donovan Baarda wrote: > On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote: > > The main oddness about python threads (before 2.3) is that they run > > with all signals masked. You could play with a C wrapper (call > > setprocmask, then exec fop) to see if t

[Python-Dev] Re: PyCon: The Spam Continues ;-)

Huh? I get a mostly blank page. Perhaps there are no authors by thatname.tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org

[Python-Dev] Re: [PyCON-Organizers] PyCon: The Spam Continues ;-)

Steve Holden wrote: Dear python-dev: The current (as of even date) summary of my recent contributions to Python -dev appears to be spam about PyCon. Not being one to break habits, even not those of a lifetime sometimes, I spam you yet again to show you what a beautiful summary ActiveState have

[Python-Dev] Re: [PyCON-Organizers] PyCon: The Spam Continues ;-)

Steve Holden wrote: [some things followed by] If I remember Trent Lott (?) described at an IPC the SQL Server database that drives this system, and it was a great example of open source technology driving a proprietary (but I expect (?) relatively portable) repository. Please forgive me for thi

[Python-Dev] PyCon: The Spam Continues ;-)

Dear python-dev: The current (as of even date) summary of my recent contributions to Python -dev appears to be spam about PyCon. Not being one to break habits, even not those of a lifetime sometimes, I spam you yet again to show you what a beautiful summary ActiveState have provided (I don't kn

Re: [Python-Dev] Speed up function calls

Neal Norwitz wrote: EXT_POP() modifies stack_pointer on the stack. In call_function(), stack_pointer is PyObject ***. But in new_fast_function(), stack_pointer is only PyObject **. So the modifications by EXT_POP to stack_pointer (moving it down) are lost in new_fast_function(). Thanks - that i

Re: [Python-Dev] Improving the Python Memory Allocator

On Jan 24, 2005, at 18:16, Martin v. Löwis wrote: - please don't post patches here; post them to SF You may ask for comments here after you posted them to SF. Sure. This should be done even for patches which should absolutely not be committed? - please follow Python coding style. In particular,

Re: [Python-Dev] Speed up function calls

On Tue, 25 Jan 2005 00:30:44 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > >>Where are the Py_DECREFs done for the function arguments? > > > > The original code path still handles the Py_DECREFs. > > This is the while loop at the end of call_function(). > > Can you pl

Re: [Python-Dev] Speed up function calls

On Mon, 24 Jan 2005 03:11:05 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > Replacing METH_O and METH_NOARGS seems straight-forward, but > METH_VARARGS has much broader capabilities. How would you handle the > simple case of "O|OO"? How could you determine useful default values > (NULL,

Re: [Python-Dev] Speed up function calls

Neal Norwitz wrote: Where are the Py_DECREFs done for the function arguments? The original code path still handles the Py_DECREFs. This is the while loop at the end of call_function(). Can you please elaborate? For METH_O and METH_ARGS, the arguments have already been popped off the stack, and the

Re: [Python-Dev] Improving the Python Memory Allocator

Here my comments, from more general to more subtle: - please don't post patches here; post them to SF You may ask for comments here after you posted them to SF. - please follow Python coding style. In particular, don't write if ( available_arenas == NULL ) { but write if (available_aren

Re: [Python-Dev] Speed up function calls

On Mon, 24 Jan 2005 23:36:24 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > I would like feedback on whether the approach is desirable. > > I'm probably missing something really essential, but... > > Where are the Py_DECREFs done for the function arguments? The ori

Re: [Python-Dev] Speed up function calls

Neal Norwitz wrote: I would like feedback on whether the approach is desirable. I'm probably missing something really essential, but... Where are the Py_DECREFs done for the function arguments? Also, changing PyArg_ParseTuple is likely incorrect. Currently, chr/unichr expects float values; with you

RE: [Python-Dev] Allowing slicing of iterators

Title: RE: [Python-Dev] Allowing slicing of iterators [Guido van Rossum] #- > As a trivial example, here's how to skip the head of a #- zero-numbered list: #- > #- >    for i, item in enumerate("ABCDEF")[1:]: #- >  print i, item #- > #- > Is this idea a non-starter, or should I spend

Re: [Python-Dev] Allowing slicing of iterators

> I just wrote a new C API function (PyItem_GetItem) that supports slicing for > arbitrary iterators. A patch for current CVS is at > http://www.python.org/sf/1108272 > > For simple indices it does the iteration manually, and for extended slices it > returns an itertools.islice object. > > As a

Re: [Python-Dev] Improving the Python Memory Allocator

[Evan Jones] : -- 2. Every N memory operations (or some other measurement of "time"), reset this value and calculate a moving average of the number of pages. This estimates the current memory requirements of the application. > The challenge is how to determine a good measurement of "t

Re: [Python-Dev] Improving the Python Memory Allocator

On Jan 24, 2005, at 7:00, Rodrigo Dias Arruda Senra wrote: Depending on the cost of arena allocation, it might help to define a lower threshold keeping a minimum of empty arena_objects permanently available. Do you think this can bring any speedup ? Yes, I think it might. I have to do some more b

Re: [Python-Dev] Improving the Python Memory Allocator

Evan Jones wrote: This message is a follow up to a thread I started on python-dev back in October, archived here: First, there is slightly more overhead with programs that allocate a lot of memory, release it, then reallocate it. Summary of the changes: - When freeing a page, if the arena is co

[Python-Dev] Allowing slicing of iterators

I just wrote a new C API function (PyItem_GetItem) that supports slicing for arbitrary iterators. A patch for current CVS is at http://www.python.org/sf/1108272 For simple indices it does the iteration manually, and for extended slices it returns an itertools.islice object. As a trivial example

RE: [Python-Dev] Speed up function calls

[Neal Norwitz] > I would like feedback on whether the approach is desirable. > > The patch adds a new method type (flags) METH_ARGS that is used in > PyMethodDef. METH_ARGS means the min and max # of arguments are > specified in the PyMethodDef by adding 2 new fields. This information > can be use