[Python-Dev] Allowing slicing of iterators

2005-01-24 Thread Nick Coghlan
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

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

2005-01-24 Thread Rodrigo Dias Arruda Senra
[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

Re: [Python-Dev] Allowing slicing of iterators

2005-01-24 Thread Guido van Rossum
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

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

2005-01-24 Thread Martin v. Lwis
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

Re: [Python-Dev] Speed up function calls

2005-01-24 Thread Martin v. Lwis
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

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

2005-01-24 Thread Evan Jones
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

Re: [Python-Dev] Speed up function calls

2005-01-24 Thread Martin v. Lwis
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

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

2005-01-24 Thread Steve Holden
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

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

2005-01-24 Thread Steve Holden
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

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

2005-01-24 Thread Terry Reedy
http://aspn.activestate.com/ASPN/Mail/Browse/ByAuthor/python-dev?author=cHljb25AcHl0aG9uLm9yZw--Huh? I get a mostly blank page. Perhaps there are no authors by thatname.tjr ___ Python-Dev mailing list Python-Dev@python.org

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

2005-01-24 Thread Anthony Baxter
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 this is