If you don't write or otherwise maintain Python Extension Modules
written in C (or C++) or embed Python in your application,
you can stop reading.
Python 2.5 alpha 1 was released April 5, 2006. The second alpha
should be released in a few weeks. There are several changes
which can cause C extens
[Neal Norwitz]
> ...
> I'm concerned about the negative ref leak in test_contextlib. I
> wonder if this was a result of PJE's fix for generators?
I don't know, but if you do
while 1:
test_contextlib.test_main()
gc.collect()
under a debug build it eventually (> 500 iterations) crashes wi
Ok, then how about prefixing with _, adding a comment saying in big,
bold letters: FOR DEBUGGING PURPOSES ONLY, THIS LEAKS, and only
defining in a debug build?
n
--
On 4/11/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> It's intended as an internal debugging API. I find it very convenient
> for a
On 4/11/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> I'd whine about not checking buildbot health after a code change,
> except that it's much more tempting to point out that Thomas couldn't
> have run the test suite successfully on his own box in this case :-)
Tsk, tsk, Thomas. Should be fixed
All the trunk buildbots started failing about 5 hours ago, in
test_parser. There have been enough checkins since then that the
boundary between passing and failing is about to scroll off forever.
So, here's the blamelist before it vanishes:
"""
1.
Changed by: thomas.wouters
Chang
I've done a lot of the work to get Python to build with g++ - this was
suggested a while ago as a useful thing to take advantage of C++'s
more stringent type checking. There's a few more little bits and
pieces to be done, and it looks like a bunch of extern "C" {}s need
to be sprinkled through
It's intended as an internal debugging API. I find it very convenient
for adding with a printf() here and there, which is how it got added
long ago. It should really have a comment mentioning that it leaks
the repr object, and starting with an _ wouldn't be bad either.
Jeremy
On 4/11/06, Neal N
On 4/11/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> > It strikes me that it should not be used, or maybe renamed to
> > _PyObject_REPR.
> > Should removing or renaming it be done in 2.5 or in Py3K?
>
> Since it is intrinsically buggy, I would support removal in Py2.5
+1 on removal. Goog
> I may not be right, but I don't see how this can't help but not free the
> intermediate PyString object.
Good catch.
> It doesn't seem to be used, except for in situations where Python is not
> going
> to continue working
> much longer anyway (specifically, in compile.c and ceval.c.)
Those
I hadn't noticed this macro defined in Include/object.h before:/* Helper for passing objects to printf and the like */#define PyObject_REPR(obj) PyString_AS_STRING(PyObject_Repr(obj))I may not be right, but I don't see how this can't help but not free the intermediate PyString object. It doesn't se
[Delaney, Timothy (Tim)]
> Definitely seems to me that it would be worthwhile in debug mode adding
> a field specifying which memory allocator was used, and checking for
> mismatches in the deallocators.
>
> I know this has been suggested before, but with number of mismatches
> being found now it s
At 07:43 AM 4/12/2006 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
> > I propose to create a new API, 'imp.find_loader()' and have it return a
> PEP
> > 302-compatible loader object, even for cases that would normally be
> handled
> > via 'imp.load_module()'. In such cases, the loader retur
Phillip J. Eby wrote:
> I propose to create a new API, 'imp.find_loader()' and have it return a PEP
> 302-compatible loader object, even for cases that would normally be handled
> via 'imp.load_module()'. In such cases, the loader returned would be an
> instance of one of a loader class similar
Neal Norwitz wrote:
> I partially reverted my fix from last night. It appears to work for
> both Guido's original problem and Phillip's subsequent problem. YMMV.
> It would be great if someone could review all the PyMem_* and
> PyObject_* allocs and frees to ensure consistency.
Definitely seem
I just noticed that two stdlib modules (runpy and test.test_importhooks)
contain reimplementations of the base PEP 302 algorithm, or loaders
wrapping the standard (pre-302) import machinery.
Meanwhile, the 'imp' module exports an undocumented IMP_HOOK constant
(since Python 2.3), that is used i
[Martin v. Löwis]
> Several places in the documentation claim that Py_Finalize will
> release all memory:
>
> http://docs.python.org/api/embedding.html
>
> says that literally,
It's wrong ;-).
> and
>
> http://docs.python.org/api/initialization.html#l2h-778
>
> suggests it is a bug when memory is
Guido van Rossum wrote:
> I'm afraid it was wishful thinking on my part.
>
> The best we can try to hope for is to ensure that repeatedly calling
> Py_Initialize and Py_Finalize doesn't leak too much memory.
Ok. Unless somebody still claims to the contrary, I will go ahead
and weaken the promises
I'm afraid it was wishful thinking on my part.
The best we can try to hope for is to ensure that repeatedly calling
Py_Initialize and Py_Finalize doesn't leak too much memory.
--Guido
On 4/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Several places in the documentation claim that Py_Fin
Steven Bethard wrote:
> Ok, if I summarize any more of python-dev, my brain's going to explode. ;-)
>
> Here's the summaries for the first half of March. Let me know what to fix!
>
> ---
> Maintaining ctypes in SVN trunk
> ---
>
> Thomas
Several places in the documentation claim that Py_Finalize will
release all memory:
http://docs.python.org/api/embedding.html
says that literally, and
http://docs.python.org/api/initialization.html#l2h-778
suggests it is a bug when memory is not freed in Py_Finalize.
This has left people to be
On 4/10/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 4/10/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >
> > It appears the problem is an object/mem mismatch: both PyOS_Readline in
> > pgenmain.c, and PyOS_StdioReadline use PyObject_MALLOC, but bltinmodule.c
> > is freeing the pointer with P
21 matches
Mail list logo
