On 11/25/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>
> Can you move the call to codecs.register_error() out of test_callbacks()
> and retry?
It then leaks 3 refs on each call to test_callbacks().
n
--
>>> import codecs
[24540 refs]
>>>
[24541 refs]
>>> def handler(exc):
... l = [u"<%d>" %
On Fri, Nov 25, 2005, Victor STINNER wrote:
>
> I found a bug in bz2 python module. Example:
>
> Details and *patch* at:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1366000&group_id=5470&atid=105470
Thanks! Particularly with the Thanksgiving weekend, you may not get any
other resp
Hi all,
I've implemented a patch, please visit bug 1366311 for details.
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&group_id=5470
This patch only release the GIL when the engine perform a low level
search *and* if the object searched is a string or a unicode string.
Th
Hi,
I found a bug in bz2 python module. Example:
import bz2
bz2.BZ2File("test.bz2","r")
bz2.seek(0,2)
assert bz2.tell() != 0
Details and *patch* at:
http://sourceforge.net/tracker/index.php?func=detail&aid=1366000&group_id=5470&atid=105470
Please CC-me for all your answers.
Bye, Victor
--
Neal Norwitz wrote:
> [...]
> test_codeccallbacks
>
> import codecs
> def test_callbacks():
> def handler(exc):
> l = [u"<%d>" % ord(exc.object[pos]) for pos in xrange(exc.start, exc.end)]
> return (u"[%s]" % u"".join(l), exc.end)
> codecs.register_error("test.handler", handler)
Hi Neal,
On Thu, Nov 24, 2005 at 07:35:06PM -0800, Neal Norwitz wrote:
> The itertools.tee() fix I thought was quite obvious:
>
> +++ Modules/itertoolsmodule.c (working copy)
> @@ -356,7 +356,8 @@
> {
> if (tdo->nextlink == NULL)
> tdo->nextlink = teedataobject_new(tdo-
Neal Norwitz <[EMAIL PROTECTED]> writes:
> There are still a few reference leaks I've been able to identify. I
> didn't see an obvious solution to these (well, I saw one obvious
> solution which crashed, so obviously I was wrong).
>
> When running regrtest with -R here are the ref leaks reported:
Hi Jim,
You wrote:
> >(2) Is he allocating new _types_, which I think don't get properly
> > collected.
(Off-topic) For reference, as far as I know new types are properly
freed. There has been a number of bugs and lots of corner cases to fix,
but I know of no remaining one. This assumes that t
Martin v. Löwis wrote:
> Formally: no; it access a Python string/Python unicode object all
> the time.
>
> Now, since all the shared objects it accesses are immutable, likely
> no harm would be done releasing the GIL. I think SRE was originally
> also intended to operate on array.array objects; th
