[Python-Dev] Backporting tempfile.NamedTemporaryFile context management fix
In 2.5, tempfile.NamedTemporaryFile passes requests for __enter__ and __exit__ through to the underlying file object, which ends up breaking in a couple of different ways (by a fortuitous coincidence, it actually works in most respects on Windows, so tempfile.TemporaryFile will mostly do the right thing in with statements no matter what platform you are on). This has been fixed on the trunk in response to issue 2021, but I'm not sure of the current status of the 2.5 maintenance branch. Should I wait until after 2.5.2 is released before backporting? Or backport it now? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting tempfile.NamedTemporaryFile context management fix
Assuming the fix isn't going to break other things, I'd say now is the time, unless Martin says otherwise. Waiting until after 2.5.2 doesn't make a lot of sense -- either it is a backportable fix, or it isn't. If it is backportable, it can go in as long as the 2.5.2 code freeze isn't in effect. On Feb 10, 2008 4:53 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > In 2.5, tempfile.NamedTemporaryFile passes requests for __enter__ and > __exit__ through to the underlying file object, which ends up breaking > in a couple of different ways (by a fortuitous coincidence, it actually > works in most respects on Windows, so tempfile.TemporaryFile will mostly > do the right thing in with statements no matter what platform you are on). > > This has been fixed on the trunk in response to issue 2021, but I'm not > sure of the current status of the 2.5 maintenance branch. Should I wait > until after 2.5.2 is released before backporting? Or backport it now? > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting tempfile.NamedTemporaryFile context management fix
> This has been fixed on the trunk in response to issue 2021, but I'm not > sure of the current status of the 2.5 maintenance branch. Should I wait > until after 2.5.2 is released before backporting? Or backport it now? Please backport it now. The code freeze for the 2.5 branch will come Wednesday night; there will be release candidate first. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Confused about test_bsddb failures on Mac OS X
I'm having trouble with test_bsddb on my new MacBook Pro (OS X 10.5.1). Many tests give this error: Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/test/test_bsddb.py", line 18, in setUp self.f = self.openmethod[0](self.fname, self.openflag, cachesize=32768) File "/Users/skip/src/python/trunk/Lib/bsddb/__init__.py", line 327, in btopen d.open(file, db.DB_BTREE, flags, mode) DBFileExistsError: (17, 'File exists -- __fop_file_setup: Retry limit (100) exc eeded') In TestBSDDB.setUp I added a print statement to the start: print os.path.abspath(self.fname), os.path.exists(self.fname) It always prints: /Users/skip/src/python/trunk/build/@test False I'm using the MacPorts version of Berkeley DB. I've tried both 4.5 and 4.4: % otool -L build/lib.macosx-10.3-i386-2.6/_bsddb.so build/lib.macosx-10.3-i386-2.6/_bsddb.so: /opt/local/lib/db44/libdb-4.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) Any idea what the problem might be? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Confused about test_bsddb failures on Mac OS X
I recall seeing this too, though my memory is fuzzy. I believe there's a temp file or directory left behind from a previous run that you need to delete. Maybe the source around that error will give you a hint on what its name is. I know I eventually got over is. On Feb 10, 2008 11:34 AM, <[EMAIL PROTECTED]> wrote: > I'm having trouble with test_bsddb on my new MacBook Pro (OS X 10.5.1). > Many tests give this error: > > Traceback (most recent call last): > File "/Users/skip/src/python/trunk/Lib/test/test_bsddb.py", line 18, in > setUp > self.f = self.openmethod[0](self.fname, self.openflag, > cachesize=32768) > File "/Users/skip/src/python/trunk/Lib/bsddb/__init__.py", line 327, in > btopen > d.open(file, db.DB_BTREE, flags, mode) > DBFileExistsError: (17, 'File exists -- __fop_file_setup: Retry limit > (100) exc > eeded') > > In TestBSDDB.setUp I added a print statement to the start: > > print os.path.abspath(self.fname), os.path.exists(self.fname) > > It always prints: > > /Users/skip/src/python/trunk/build/@test False > > I'm using the MacPorts version of Berkeley DB. I've tried both 4.5 and 4.4: > > % otool -L build/lib.macosx-10.3-i386-2.6/_bsddb.so > build/lib.macosx-10.3-i386-2.6/_bsddb.so: > /opt/local/lib/db44/libdb-4.4.dylib (compatibility version 0.0.0, > current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 111.0.0) > > Any idea what the problem might be? > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Confused about test_bsddb failures on Mac OS X
Guido> I recall seeing this too, though my memory is fuzzy. I believe Guido> there's a temp file or directory left behind from a previous run Guido> that you need to delete. Thanks. I zapped my build directory then reran configure ;; make ;; make test Seems to be working better now. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Bug Day on Feb. 23
After the success of January's bug day, which closed 37 issues, let's have another one this month! Here's the brief announcement: Python Bug Day: Saturday, February 23 2008. Meet in the #python-dev IRC channel on irc.freenode.net and help improve Python. For more information, see http://wiki.python.org/moin/PythonBugDay . --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] int/float freelists vs pymalloc
Andrew MacIntyre wrote: > I tried a LIFO stack implementation (though I won't claim to have done it > well), and found it slightly slower than no freelist at all. The > advantage of such an approach is that the known size of the stack makes > deallocating excess objects easy (and thus no need for > sys.compact_free_list() ). I've tried a single linked free list myself. I used the ob_type field to daisy chain the int and float objects. Although the code was fairly short it was slightly slower than an attempt without a free list at all. pymalloc is fast. It's very hard to beat it though. A fixed size LIFO array like PyFloatObject *free_list[PyFloat_MAXFREELIST] increased the speed slightly. IMHO a value of about 80-200 floats and ints is realistic for most apps. More objects in the free lists could keep too many pymalloced areas occupied. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] int/float freelists vs pymalloc
I've done my own profiling with a different script. I was able to verify Andrews results. The pymalloc approach makes int creation slightly slower and has almost no effect on floats. The creation of 1000 times a list of 1000 ints (range(1000)) is about 20msec slower. It almost doubles the time for a trivial test "for i in range(1000): range(1000)" but that's an artificial test. Current allocation schema - for i in range(1000): [float(x) for x in range(1000)] 10 loops, best of 3: 760 msec per loop for i in range(1000): range(1000) 10 loops, best of 3: 27 msec per loop for i in range(1000): [x for x in range(1000)]" 10 loops, best of 3: 218 msec per loop Without a free list --- for i in range(1000): [float(x) for x in range(1000)] 10 loops, best of 3: 792 msec per loop for i in range(1000): range(1000)" 10 loops, best of 3: 51.5 msec per loop for i in range(1000): [x for x in range(1000)] 10 loops, best of 3: 241 msec per loop With a fixed free list of 2,500 objects each for i in range(1000): [float(x) for x in range(1000)]" 10 loops, best of 3: 736 msec per loop for i in range(1000): range(1000)" 10 loops, best of 3: 25 msec per loop for i in range(1000): [x for x in range(1000)]" 10 loops, best of 3: 198 msec per loop As you can clearly see an approach with a small free list in a fixed size array like static PyFloatObject *free_list[PyFloat_MAXFREELIST] is even faster than block allocation. A small free list with 80 objects each would speed up the creation of floats and ints a bit *and* result in a quicker return of memory to the OS. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Confused about test_bsddb failures on Mac OS X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | Guido> I recall seeing this too, though my memory is fuzzy. I believe | Guido> there's a temp file or directory left behind from a previous run | Guido> that you need to delete. | | Thanks. I zapped my build directory then reran | | configure ;; make ;; make test | | Seems to be working better now. Feel free to post a bug in the tracker. I would look at it. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR6+2sJlgi5GaxT1NAQLXfwQAjR43q2FYNta1g2CfkzKGWMMSXSA4Z/vv /dlmkK0iDxLZ9MhVAYefDPEoCyOA408Sh4xzpXgRu9QjXCxBRqu4HFa4Oe3bfV2Y mHlAmWaUtC+MhdL+tWYzQq63uR+llZVZwyqQNPve3ylZ/USfyy89defd7BFotnM5 r4V3FAcv/i4= =FZs/ -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
