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
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
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
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
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
[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
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
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
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
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
[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
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
> 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
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
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
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
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
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
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
[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
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
21 matches
Mail list logo
