From report at bugs.python.org Tue Jan 1 00:52:12 2008 From: report at bugs.python.org (Gustavo J. A. M. Carneiro) Date: Mon, 31 Dec 2007 23:52:12 -0000 Subject: [issue1715] Make pydoc list submodules Message-ID: <1199145132.63.0.00647784499418.issue1715@psf.upfronthosting.co.za> New submission from Gustavo J. A. M. Carneiro: Often python extension modules define submodules like this: static PyObject * initfoo_xpto(void) { PyObject *m; m = Py_InitModule3("foo.xpto", foo_xpto_functions, NULL); [...] return m; } PyMODINIT_FUNC initfoo(void) { PyObject *m; PyObject *submodule; m = Py_InitModule3("foo", foo_functions, NULL); [...] submodule = initfoo_xpto(); Py_INCREF(submodule); PyModule_AddObject(m, "xpto", submodule); } Unfortunately pydoc does not list these submodules. Attached patch fixes it. ---------- components: Demos and Tools files: pydoc-submodules.diff messages: 59067 nosy: gustavo severity: normal status: open title: Make pydoc list submodules type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9038/pydoc-submodules.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pydoc-submodules.diff Type: text/x-patch Size: 702 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071231/90b0608d/attachment-0001.bin From report at bugs.python.org Tue Jan 1 03:38:29 2008 From: report at bugs.python.org (Christopher Tur Lesniewski-Laas) Date: Tue, 01 Jan 2008 02:38:29 -0000 Subject: [issue1716] String format operator '%i' fails for large floats Message-ID: <1199155109.22.0.179885625842.issue1716@psf.upfronthosting.co.za> New submission from Christopher Tur Lesniewski-Laas: To reproduce: >>> '%i' % 12345678901.0 TypeError: int argument required Contrast with: >>> '%i' % 1234567890.0 '1234567890' Previous experience led me to expect that the '%i' format code would work for all numerical types. Admittedly, there's nothing in the docs promising this, but it works *almost* all the time. In fact, the operator fails to convert floats which are too big to fit into a machine long. The code for the '%i' operator handles objects of type long specially, and then uses PyInt_AsLong to handle all other objects (in formatint). The ideal solution would be to ask the object to convert itself into an int *before* the special test for type long; this would give the expected behavior. An acceptable solution would be to make the behavior consistent by refusing all floats passed as the argument to '%i', but I expect this would break a lot of code. Of course, right now most of that code is broken anyway, since it will throw a TypeError when the input float happens to be large. ---------- components: Interpreter Core messages: 59068 nosy: ctl severity: normal status: open title: String format operator '%i' fails for large floats versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 04:02:58 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Jan 2008 03:02:58 -0000 Subject: [issue1716] String format operator '%i' fails for large floats Message-ID: <1199156578.79.0.145964567098.issue1716@psf.upfronthosting.co.za> Guido van Rossum added the comment: On the one hand, if you want to format a float like that, you should use "%.0f". On the other hand, this should either consistently fail or succeed, not depending on how large the float is. I think in 2.6 we can't change this, but in 3.0, I propose that all these accept only integers. I find the behavior of %x and %o with floats particularly anti-intuitive. On the third hand, we're expecting % to be phased out in favor of .format(), which allows floats of any value with the i, d, o, x format specifiers. So perhaps we should leave this alone? ---------- nosy: +gvanrossum priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 05:07:04 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Jan 2008 04:07:04 -0000 Subject: [issue1693] Please check merge from trunk Message-ID: <1199160424.72.0.406377715224.issue1693@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 59636. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 15:46:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 01 Jan 2008 14:46:53 -0000 Subject: [issue1715] Make pydoc list submodules Message-ID: <1199198813.59.0.89385811118.issue1715@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl keywords: +patch nosy: +georg.brandl priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 15:47:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 01 Jan 2008 14:47:32 -0000 Subject: [issue1694] floating point number round failures under Linux Message-ID: <1199198852.03.0.196464355061.issue1694@psf.upfronthosting.co.za> Changes by Christian Heimes: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 15:49:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 01 Jan 2008 14:49:08 -0000 Subject: [issue1692] Syntax Error exception dosen't print string; not informative Message-ID: <1199198948.88.0.979789478674.issue1692@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Interpreter Core keywords: +py3k priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 17:31:54 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Jan 2008 16:31:54 -0000 Subject: [issue1703] getpass broken in Py3k: must flush() Message-ID: <1199205114.66.0.605055563505.issue1703@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 59646. ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 17:39:25 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Jan 2008 16:39:25 -0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ Message-ID: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> New submission from Guido van Rossum: Should I apply this? There are more places that reference __cmp__ in the library. OTOH there are some folks who would like to see __cmp__ make a come-back as a shorthand for defining 6 comparison operators, for totally-ordered types. (I'm still waiting for a PEP describing this though.) Even in that case I'm not sure that the code I'm proposing to delete here would be useful. ---------- assignee: gvanrossum components: Interpreter Core files: nocmp.diff keywords: patch messages: 59072 nosy: gvanrossum priority: low severity: normal status: open title: Get rid of more refercenes to __cmp__ type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9039/nocmp.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 20:05:23 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Jan 2008 19:05:23 -0000 Subject: [issue1713] posixpath.ismount() claims symlink to a mountpoint is a mountpoint. Message-ID: <1199214323.71.0.135522039877.issue1713@psf.upfronthosting.co.za> Guido van Rossum added the comment: Go ahead then! ---------- assignee: -> tiran nosy: +gvanrossum resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 20:06:51 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Jan 2008 19:06:51 -0000 Subject: [issue1711] socket functions that should return unsigned int return signed int Message-ID: <1199214411.86.0.278958616385.issue1711@psf.upfronthosting.co.za> Guido van Rossum added the comment: This should be fixed. Maarten, can you create a patch that works for you? (Since few of us have access to the platform where it breaks.) ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 22:40:08 2008 From: report at bugs.python.org (Maarten Thibaut) Date: Tue, 01 Jan 2008 21:40:08 -0000 Subject: [issue1711] socket functions that should return unsigned int return signed int Message-ID: <1199223608.12.0.898348270275.issue1711@psf.upfronthosting.co.za> Maarten Thibaut added the comment: Guido, the problem is that my python foo is severely lacking - but I'll have a stab at it. Python believes that the number coming back from the C library is negative. We can fool it by packing the "signed short" into a system-native format, and then unpacking it explicitly into an unsigned short. So I propose to do precisely that on big endian systems using sys.byteorder: wrap these functions with a converter. Would that be acceptible? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 22:53:53 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Jan 2008 21:53:53 -0000 Subject: [issue1711] socket functions that should return unsigned int return signed int Message-ID: <1199224433.03.0.515684371922.issue1711@psf.upfronthosting.co.za> Guido van Rossum added the comment: Maarten, can you build Python 2.6 from svn? (See http://www.python.org/dev/faq/#subversion-svn for help.) It looks like this has been fixed there, per r53434. Perhaps the same changes can be backported. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 23:55:35 2008 From: report at bugs.python.org (Ismail Donmez) Date: Tue, 01 Jan 2008 22:55:35 -0000 Subject: [issue1718] Tarfile fails to fully extract tar.bz2/tar.gz package Message-ID: <1199228135.83.0.661994029416.issue1718@psf.upfronthosting.co.za> New submission from Ismail Donmez: Running python 2.5 maintainance branch, Test code is : import tarfile f = file(r"nss-3.12_alpha2.tar.bz2", "rb") tar = tarfile.open(fileobj=f, mode="r|bz2") try: for m in tar: tar.extract(m) finally: tar.close() f.close() You can get the file from http://cekirdek.pardus.org.tr/~ismail/dist/nss-3.12_alpha2.tar.bz2 . When the script finishes it only creates mozilla/security/nss directory, if you extract with tar you will see that it also creates mozilla/security/coreconf directory. Tarfile created with 1.19 on Linux i686. I can reproduce the same problem with tar.gz version of the same file. ---------- components: Library (Lib) messages: 59077 nosy: cartman severity: normal status: open title: Tarfile fails to fully extract tar.bz2/tar.gz package versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 1 23:56:37 2008 From: report at bugs.python.org (Ismail Donmez) Date: Tue, 01 Jan 2008 22:56:37 -0000 Subject: [issue1718] Tarfile fails to fully extract tar.bz2/tar.gz package Message-ID: <1199228197.63.0.888742474455.issue1718@psf.upfronthosting.co.za> Changes by Ismail Donmez: ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 00:02:59 2008 From: report at bugs.python.org (Ismail Donmez) Date: Tue, 01 Jan 2008 23:02:59 -0000 Subject: [issue1718] Tarfile fails to fully extract tar.bz2/tar.gz package Message-ID: <1199228579.54.0.625012210279.issue1718@psf.upfronthosting.co.za> Ismail Donmez added the comment: Argh stupid me, this is due a patch on my side, grr. ? am really sorry. Please close as invalid :( __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 01:46:33 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 00:46:33 -0000 Subject: [issue1718] Tarfile fails to fully extract tar.bz2/tar.gz package Message-ID: <1199234793.64.0.992186918361.issue1718@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 03:42:49 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 02:42:49 -0000 Subject: [issue1705] trace module does not annotate global statement Message-ID: <1199241769.78.0.8154470814.issue1705@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't see a bug here. It is as Amaury explains. ---------- nosy: +gvanrossum status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 03:43:56 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 02:43:56 -0000 Subject: [issue1702] Word "alias" used in confusing way to compare open() and file() Message-ID: <1199241836.81.0.213700240799.issue1702@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks like a doc change that Georg could easily apply. ---------- assignee: nnorwitz -> georg.brandl nosy: +georg.brandl, gvanrossum priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 03:48:42 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 02:48:42 -0000 Subject: [issue1700] Regular Expression inline flags not handled correctly for some unicode characters Message-ID: <1199242122.06.0.941890591842.issue1700@psf.upfronthosting.co.za> Guido van Rossum added the comment: I see this too. Maybe Fredrik understands? ---------- assignee: -> effbot nosy: +effbot, gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 03:55:56 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 02:55:56 -0000 Subject: [issue1707] probable bug in code.py with Python 3.0a2 Message-ID: <1199242556.34.0.491772597031.issue1707@psf.upfronthosting.co.za> Guido van Rossum added the comment: Good catch! Committed revision 59659. I wonder how many other places have the same problem... ---------- nosy: +gvanrossum resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 04:03:48 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 03:03:48 -0000 Subject: [issue1709] logging: log actual function name Message-ID: <1199243028.89.0.165070899133.issue1709@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> vsajip nosy: +vsajip priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 04:20:38 2008 From: report at bugs.python.org (Andre Roberge) Date: Wed, 02 Jan 2008 03:20:38 -0000 Subject: [issue1707] probable bug in code.py with Python 3.0a2 Message-ID: <1199244038.92.0.0902350614353.issue1707@psf.upfronthosting.co.za> Changes by Andre Roberge: __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 04:24:03 2008 From: report at bugs.python.org (Andre Roberge) Date: Wed, 02 Jan 2008 03:24:03 -0000 Subject: [issue1707] probable bug in code.py with Python 3.0a2 Message-ID: <1199244243.34.0.482161005007.issue1707@psf.upfronthosting.co.za> Andre Roberge added the comment: I did a quick search on the *.py files in the distribution. I only found two questionable places. 1. site.py has "raw_input" (python 2.5, line 311) replaced by the more complicated 3 lines (python 3.0a2, lines 313-315) rather than the simpler one-liner replacement. However, I do not see any reason why this could cause problems. 2. pydoc.py: raw_input is still present in 3.0a2 on line 1711; it should be replaced by input imo. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 04:45:52 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 03:45:52 -0000 Subject: [issue1696] Distutils ignore dry-run flag at clean-up of distutils.command.build_scripts.copy_scripts Message-ID: <1199245552.47.0.470350369615.issue1696@psf.upfronthosting.co.za> Guido van Rossum added the comment: Actually, only the f.close() call should be conditionalized. Does this patch fix the issue for you? ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: -> normal Added file: http://bugs.python.org/file9040/distutils.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 04:54:02 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 03:54:02 -0000 Subject: [issue1707] probable bug in code.py with Python 3.0a2 Message-ID: <1199246042.17.0.473507892891.issue1707@psf.upfronthosting.co.za> Guido van Rossum added the comment: site.py is already fixed in svn; it actually did cause problems, see issue #1667. I fixed pydoc.py. Committed revision 59660. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 05:11:41 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 02 Jan 2008 04:11:41 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1199247101.42.0.169330225514.issue1177@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r58207 and r58247 patch logic is reversed. ---------- assignee: facundobatista -> kbk nosy: +kbk resolution: fixed -> status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 05:13:55 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 02 Jan 2008 04:13:55 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1199247235.36.0.593140240031.issue1177@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Reversed the logic of the previous patches to urllib.py and added a test case. I noticed the problem when I tried to retrieve a file which required auth. r59661 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 05:22:39 2008 From: report at bugs.python.org (toxik) Date: Wed, 02 Jan 2008 04:22:39 -0000 Subject: [issue1696] Distutils ignore dry-run flag at clean-up of distutils.command.build_scripts.copy_scripts Message-ID: <1199247759.8.0.400822596261.issue1696@psf.upfronthosting.co.za> toxik added the comment: It doesn't die now, but AFAICT, it doesn't even try to copy the script now. (With your patch.) I might also add that this is for package_data. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 05:30:04 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 02 Jan 2008 04:30:04 -0000 Subject: [issue1719] Cosmetic patch for doc/code mismatch (msilib.UuidCreate) Message-ID: <1199248204.42.0.654207997691.issue1719@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto: Doc says msilib.UUIDCreate(), while code says msilib.UuidCreate() (Case differs) maybe doc is wrong? ---------- components: Documentation files: msilib.patch messages: 59089 nosy: ocean-city severity: normal status: open title: Cosmetic patch for doc/code mismatch (msilib.UuidCreate) versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9041/msilib.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 07:44:30 2008 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 02 Jan 2008 06:44:30 -0000 Subject: [issue1709] logging: log actual function name Message-ID: <1199256270.23.0.35908664244.issue1709@psf.upfronthosting.co.za> Vinay Sajip added the comment: This must be some kind of SVN issue. Works fine on 2.5.1: Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import logging >>> def myLoggingFunc(): ... logging.warning("Be warned!") ... >>> logging.basicConfig(format="%(funcName)s %(message)s") >>> myLoggingFunc() myLoggingFunc Be warned! >>> ---------- resolution: -> invalid status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 09:42:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Jan 2008 08:42:18 -0000 Subject: [issue1719] Cosmetic patch for doc/code mismatch (msilib.UuidCreate) Message-ID: <1199263338.76.0.800943514834.issue1719@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl nosy: +georg.brandl priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 10:34:52 2008 From: report at bugs.python.org (umaxx) Date: Wed, 02 Jan 2008 09:34:52 -0000 Subject: [issue1709] logging: log actual function name Message-ID: <1199266492.48.0.311109710362.issue1709@psf.upfronthosting.co.za> umaxx added the comment: oops... i looked at python 2.4, not the latest trunk. my fault :( please close this issue. sorry for the noise... __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 12:17:44 2008 From: report at bugs.python.org (Fredrik Lundh) Date: Wed, 02 Jan 2008 11:17:44 -0000 Subject: [issue1700] Regular Expression inline flags not handled correctly for some unicode characters Message-ID: <1199272664.49.0.151851078289.issue1700@psf.upfronthosting.co.za> Fredrik Lundh added the comment: Looks like the wrong execution flags are being passed to the function that creates the actual pattern object; the SRE compiler does the right thing, but the engine isn't running with the right flags in the last case. Changing the call to _sre.compile in sre_compile.py to: return _sre.compile( pattern, flags | p.pattern.flags, code, p.pattern.groups-1, groupindex, indexgroup ) should do the trick, I think. (got no time to fix my broken Python SVN setup right now, but if someone wants to verify this and add the necessary tests to the test suite, be my guest). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 13:45:21 2008 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 02 Jan 2008 12:45:21 -0000 Subject: [issue1709] logging: log actual function name Message-ID: <1199277921.95.0.58753251727.issue1709@psf.upfronthosting.co.za> Changes by Vinay Sajip: ---------- status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 15:11:02 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 02 Jan 2008 14:11:02 -0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1199283062.73.0.195295750348.issue1700463@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I updated the patch. - Added missing _msi support - Workaround for PC/msvcrtmodule.c (getwch not exists on VC6) Added file: http://bugs.python.org/file9042/vc6-trunk-ver3.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 2 15:46:34 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 02 Jan 2008 14:46:34 -0000 Subject: [issue1720] VC6 build patch for release-maint25 Message-ID: <1199285194.09.0.0105963062735.issue1720@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto: Hello. This patch adds missing _msi support. I confirmed msi file was successfully created for simple .py extension via "setup.py bdist_msi". Thank you. ---------- components: Build files: vc6-release-maint25.patch messages: 59094 nosy: ocean-city severity: normal status: open title: VC6 build patch for release-maint25 versions: Python 2.5 Added file: http://bugs.python.org/file9043/vc6-release-maint25.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 17:12:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Jan 2008 16:12:59 -0000 Subject: [issue1721] _tkinter.c:903: AsObj: Assertion `size < size * sizeof(Tcl_UniChar)' failed Message-ID: <1199290379.17.0.733909203656.issue1721@psf.upfronthosting.co.za> New submission from Christian Heimes: $ ./python Lib/idlelib/idle.py python: /home/heimes/dev/python/py3k/Modules/_tkinter.c:903: AsObj: Assertion `size < size * sizeof(Tcl_UniChar)' failed. Aborted The code works when I change the assertion from "<" to "<=". My Python 3.0 is compiled with unicode=UCS-4 and Tcl is the default installation of Ubuntu (probably UCS-2?). ---------- components: IDLE, Tkinter keywords: py3k messages: 59095 nosy: tiran priority: normal severity: normal status: open title: _tkinter.c:903: AsObj: Assertion `size < size * sizeof(Tcl_UniChar)' failed versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 17:15:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Jan 2008 16:15:04 -0000 Subject: [issue1720] VC6 build patch for release-maint25 Message-ID: <1199290504.59.0.698404367606.issue1720@psf.upfronthosting.co.za> Christian Heimes added the comment: Do you have time to check and fix the VC6 build directories of Python 2.6 and 3.0, too? I don't think that they are up to date. ---------- assignee: -> loewis keywords: +patch nosy: +loewis, tiran priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 18:44:16 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 17:44:16 -0000 Subject: [issue1696] Distutils ignore dry-run flag at clean-up of distutils.command.build_scripts.copy_scripts Message-ID: <1199295856.28.0.137753591061.issue1696@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm not a big distutils expert myself, I can't quite interpret your feedback. In dry-run mode, it shouldn't try to copy the script, correct? ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 18:44:58 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 17:44:58 -0000 Subject: [issue1721] _tkinter.c:903: AsObj: Assertion `size < size * sizeof(Tcl_UniChar)' failed Message-ID: <1199295898.51.0.374487209819.issue1721@psf.upfronthosting.co.za> Guido van Rossum added the comment: How about 2.6? ---------- assignee: -> loewis nosy: +gvanrossum, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 18:45:12 2008 From: report at bugs.python.org (toxik) Date: Wed, 02 Jan 2008 17:45:12 -0000 Subject: [issue1696] Distutils ignore dry-run flag at clean-up of distutils.command.build_scripts.copy_scripts Message-ID: <1199295912.48.0.655073516252.issue1696@psf.upfronthosting.co.za> toxik added the comment: It shouldn't try to copy the script anywhere, it should just tell me what it was going to do, by means of console. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 19:28:44 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 18:28:44 -0000 Subject: [issue1696] Distutils ignore dry-run flag at clean-up of distutils.command.build_scripts.copy_scripts Message-ID: <1199298524.51.0.929038991385.issue1696@psf.upfronthosting.co.za> Guido van Rossum added the comment: So that's correct behavior right? (I looked at the code for copy_file() in cmd.py and it passes the dry_run parameter to the file utility function that does the actual copying. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 19:31:39 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 02 Jan 2008 18:31:39 -0000 Subject: [issue1722] Undocumented urllib functions Message-ID: <1199298699.61.0.103680011754.issue1722@psf.upfronthosting.co.za> Changes by Barry A. Warsaw: ---------- components: Documentation nosy: barry priority: low severity: normal status: open title: Undocumented urllib functions versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 19:32:02 2008 From: report at bugs.python.org (toxik) Date: Wed, 02 Jan 2008 18:32:02 -0000 Subject: [issue1696] Distutils ignore dry-run flag at clean-up of distutils.command.build_scripts.copy_scripts Message-ID: <1199298722.73.0.901865186523.issue1696@psf.upfronthosting.co.za> toxik added the comment: Mmh, well, as far as I could tell when I tested your patch, it didn't say it's going to copy the file, but it didn't say it isn't going to either. As far as this ticket is concerned however, I'd say the behavior is now fixed. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 19:33:00 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 02 Jan 2008 18:33:00 -0000 Subject: [issue1722] Undocumented urllib functions Message-ID: <1199298780.6.0.893928826633.issue1722@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: urllib.splithost() and .splittype() are included in urllib's __all__ but are not documented in urllib's module documentation. They are used quite extensively in the module so they should be documented __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 19:47:22 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 18:47:22 -0000 Subject: [issue1722] Undocumented urllib functions Message-ID: <1199299642.2.0.174385235765.issue1722@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 20:01:05 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 19:01:05 -0000 Subject: [issue1696] Distutils ignore dry-run flag at clean-up of distutils.command.build_scripts.copy_scripts Message-ID: <1199300465.13.0.611683498421.issue1696@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 59668. (2.5 branch) Committed revision 59669. (2.6 trunk) ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 20:55:06 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 02 Jan 2008 19:55:06 -0000 Subject: [issue1721] _tkinter.c:903: AsObj: Assertion `size < size * sizeof(Tcl_UniChar)' failed Message-ID: <1199303706.3.0.0873267605641.issue1721@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think this is a duplicate of #1301 (reopen if you think it's not), where I think Facundo makes an excellent point. ---------- resolution: -> duplicate status: open -> closed superseder: -> Bad assertion in _tkinter.c __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 23:16:30 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 22:16:30 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1199312190.61.0.967816557078.issue1301@psf.upfronthosting.co.za> Guido van Rossum added the comment: So what's the correct fix? Skip the whole block if size==0? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 2 23:18:02 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 22:18:02 -0000 Subject: [issue1708] improvements for linecache Message-ID: <1199312282.64.0.530855860462.issue1708@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll look at this when I have time. If you find someone else interested in reviewing, please give them the patch! ---------- assignee: -> gvanrossum keywords: +patch nosy: +gvanrossum priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 00:08:49 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Jan 2008 23:08:49 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1199315329.34.0.682786572984.issue1301@psf.upfronthosting.co.za> Christian Heimes added the comment: I've hit the same bug today. I vote for the removal of the assert() and a skip of the entire block if size == 0. I don't see what the assert() should test. ---------- nosy: +tiran versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 00:10:55 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 23:10:55 -0000 Subject: [issue1692] Syntax Error exception dosen't print string; not informative Message-ID: <1199315455.2.0.574138544537.issue1692@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yup. Same if the exception comes in a file. I'll try to free up some cycles to look into this. Thanks for the report! ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 00:14:19 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 23:14:19 -0000 Subject: [issue1698] urlparse and usernames containing @ Message-ID: <1199315659.53.0.341723117629.issue1698@psf.upfronthosting.co.za> Guido van Rossum added the comment: Could you please add a unit test for this? Then I can check it in. I'm thinking this could safely be fixed in 2.5.2. ---------- assignee: -> gvanrossum nosy: +gvanrossum resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 00:16:53 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 23:16:53 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1199315813.78.0.788530141888.issue1205@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 00:16:57 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 02 Jan 2008 23:16:57 -0000 Subject: =?utf-8?q?[issue1723]_Respuesta_autom=C3=A1tica_de_Yahoo!?= Message-ID: <750844.18848.qm@web32806.mail.mud.yahoo.com> New submission from Gabriel Genellina: Estoy de vacaciones hasta el 15 de enero! On holiday until Jan 15! ---------- messages: 59110 nosy: gagenellina severity: normal status: open title: Respuesta autom?tica de Yahoo! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 00:21:16 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Jan 2008 23:21:16 -0000 Subject: =?utf-8?q?[issue1723]_Respuesta_autom=C3=A1tica_de_Yahoo!?= Message-ID: <1199316076.07.0.381330118718.issue1723@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- nosy: -gagenellina resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 00:43:20 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Jan 2008 23:43:20 -0000 Subject: [issue1724] Py_SIZE() macro used as an lvalue Message-ID: <1199317400.01.0.0409797151443.issue1724@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Don't know if this was intended. Here's a example from rev 56476 in arraymodule.c: - op->ob_size = size; + Py_Size(op) = size; ---------- assignee: loewis components: Interpreter Core messages: 59111 nosy: loewis, rhettinger severity: normal status: open title: Py_SIZE() macro used as an lvalue versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 00:46:36 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 02 Jan 2008 23:46:36 -0000 Subject: [issue1724] Py_SIZE() macro used as an lvalue Message-ID: <1199317596.53.0.0645531090663.issue1724@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Certainly. This macro definitely *is* an lvalue. ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 01:04:55 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 00:04:55 -0000 Subject: [issue1725] -1e-1000 converted incorrectly Message-ID: <1199318695.81.0.228774290881.issue1725@psf.upfronthosting.co.za> New submission from Guido van Rossum: Since 1e-1000 == 0.0 (on an IEEE-754 platform anyway), I would expect -1e-1000 to be -0.0. But it does not appear that way: >>> 1e-1000 0.0 >>> -0.0 -0.0 >>> -1e-1000 0.0 However (correctly): >>> (-1.0) * 1e-1000 -0.0 >>> -(1e-1000) -0.0 I suspect the optimization for -x where x is a float literal is incorrectly triggering here. ---------- messages: 59113 nosy: gvanrossum severity: normal status: open title: -1e-1000 converted incorrectly versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 01:07:49 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 00:07:49 -0000 Subject: [issue1725] -1e-1000 converted incorrectly Message-ID: <1199318868.99.0.468459477321.issue1725@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW this was on x86 Linux. On x86 OSX (10.4, Tiger) it works correctly: >>> -1e-1000 -0.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 01:11:00 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 00:11:00 -0000 Subject: [issue1640] Enhancements for mathmodule Message-ID: <1199319060.95.0.0776451148099.issue1640@psf.upfronthosting.co.za> Guido van Rossum added the comment: One nit: you added a blank line to the end of test_math.py. This will cause the checkin to fail. :-) One bigger issue: the sign() function doesn't seem to work properly for nans. E.g. on Linux I get: >>> inf = 1e1000 >>> nan = inf/inf >>> mnan = -nan >>> math.sign(nan) -1 >>> math.sign(mnan) 1 IOW a positive nan is considered negative and vice versa. (This is probably due to the way nans defy testing, always returning false.) I'm also curious why math.sign(0.0) returns 1 -- this is going to cause a lot of confusion. This is also missing doc patches. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 01:15:01 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 00:15:01 -0000 Subject: [issue1567] Patch for new API method _PyImport_ImportModuleNoLock(char *name) Message-ID: <1199319301.14.0.660468160584.issue1567@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you produce a version of the patch that applies cleanly to 2.6? Then we can apply it there first and merge into 3.0 later. But I wonder. It seems this changes every single call to PyImport_ImportModule() in the core to _PyImport_ImportModuleNoLock(). What's the point of the lock at that point? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 02:15:02 2008 From: report at bugs.python.org (Francesco Cosoleto) Date: Thu, 03 Jan 2008 01:15:02 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1199322902.47.0.9077222788.issue1205@psf.upfronthosting.co.za> Francesco Cosoleto added the comment: Sorry, but I don't understand reason to close this issue with resolution "wont fix". The problem was reproducible and his logic explained by more developers. If the problem has been resolved, then, please, change "resolution" field to "fixed", else a patch request is pending (see msg56162). No? :-( Of course - it was predictable - the bug isn't reproducible now also using previous Python version: $ wget -c http://www.recherche.fr/encyclopedie/Thomas-Robert_Bugeaud [..omisss..] 02:08:34 (4.28 KB/s) - "Thomas-Robert_Bugeaud" salvato [65107] ---- Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) >>> url = "http://www.recherche.fr/encyclopedie/Thomas-Robert_Bugeaud" >>> a = urllib.urlopen(url) ; c = a.read(1024 * 1024 * 2) >>> len(c) 65169 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 02:50:08 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 01:50:08 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1199325008.79.0.589514345986.issue1205@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm just following the last post's suggestion "Should we close this then?" My message (somebody "should" submit a patch) was sarcastic --- it was in reference to the comment that Python "should" be more practical. Since no patch was applied, I don't know why "won't fix" isn't a perfectly adequate description of the reason for closure. If you want me to reopen this, please submit a patch. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 03:24:00 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Thu, 03 Jan 2008 02:24:00 -0000 Subject: [issue1689] Backport PEP 3141 to 2.6 Message-ID: <1199327040.67.0.162018620421.issue1689@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I've committed this as r59671, except that round() returns a float again to make sure we keep compatibility. Let me know if you find anything that needs fixing. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 04:05:28 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Jan 2008 03:05:28 -0000 Subject: [issue1725] -1e-1000 converted incorrectly Message-ID: <1199329528.16.0.77758330898.issue1725@psf.upfronthosting.co.za> Mark Dickinson added the comment: Tracing the calls through ast_for_factor -> ast_for_atom -> parsenumber -> PyOS_ascii_atof -> PyOS_ascii_strtod -> strtod, it looks as though the cause is simply that strtod behaves differently on the two platforms. I get that the following code: #include #include int main() { char *fail_pos; double x; x = strtod("-1e-1000", &fail_pos); printf("Result: %f\n", x); return 0; } produces 0.000000 on Linux (SuSE 10.2) and -0.000000 on OS X 10.4.11. ---------- nosy: +marketdickinson __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 04:40:41 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 03 Jan 2008 03:40:41 -0000 Subject: [issue1720] VC6 build patch for release-maint25 Message-ID: <1199331641.71.0.883156906981.issue1720@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: The patch for 2.6 is in issue1700463. I don't have a patch for 3.0 yet, but I'll try to make it. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 05:47:11 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 03 Jan 2008 04:47:11 -0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1199335631.41.0.0332121321689.issue1700463@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Sorry, I updated the patch again. - Add Python/pystrcmp.c to pythoncore.dsp. - Rev59671 contains intptr_t unavailable on VC6, avoid compile error by using PyLong_FromVoidPtr(). Added file: http://bugs.python.org/file9044/vc6-trunk-ver4.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 3 05:58:39 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 03 Jan 2008 04:58:39 -0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1199336318.98.0.637321409446.issue1700463@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Ummm, I realized my change is probably inproper... Index: Objects/intobject.c =================================================================== --- Objects/intobject.c (revision 59671) +++ Objects/intobject.c (working copy) @@ -1053,7 +1053,7 @@ static PyObject * int_getN(PyIntObject *v, void *context) { - return PyInt_FromLong((intptr_t)context); + return PyLong_FromVoidPtr(context); } I recreated the patch against rev59669 for now. Please try my patch on that revision. Currently, VC6 cannot compile python on HEAD. Added file: http://bugs.python.org/file9045/vc6-trunk-ver4b.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 3 06:09:28 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 03 Jan 2008 05:09:28 -0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1199336968.06.0.581052933713.issue1700463@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Umm, I found Py_intptr_t... OK, VC6 can compile HEAD. Please forget previous patch. I confirmed test_long.py, test_math.py, test_builtin.py successfully runs. Added file: http://bugs.python.org/file9046/vc6-trunk-ver4c.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 3 07:15:00 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 06:15:00 -0000 Subject: [issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2 Message-ID: <1199340900.36.0.483404716503.issue1688@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think I understand what's going on. The trail leads from the last "if (tty) {" block in builtin_input() to PyOS_Readline() which in turn ends up calling PyOS_StdioReadline() (because that's the most likely initialization of PyOS_ReadlineFunctionPointer). And this, finally, uses fprintf() to stderr to print the prompt. That apparently doesn't use the same encoding, or perhaps by now the string has been encoded as UTF-8. This is clearly a problem. But what to do about it... ---------- keywords: +py3k nosy: +gvanrossum, tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 11:32:48 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 03 Jan 2008 10:32:48 -0000 Subject: [issue1726] Remove Python/atof.c from PCBuild/pythoncore.vcproj Message-ID: <1199356368.04.0.413165256482.issue1726@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto: Probably this file is not needed for VisualC++. I don't know this is harmful or not. ---------- components: Build files: remove_atof_c.patch messages: 59126 nosy: ocean-city severity: minor status: open title: Remove Python/atof.c from PCBuild/pythoncore.vcproj versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9047/remove_atof_c.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 11:44:43 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 03 Jan 2008 10:44:43 -0000 Subject: [issue1727] VC6 build patch for python3000 Message-ID: <1199357082.52.0.581010434607.issue1727@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto: Build succeeded. So many errors on test_mailbox.py, and following error on test_float.py were reported. ====================================================================== FAIL: test_nan_from_str (__main__.InfNanTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_float.py", line 203, in test_nan_from_str self.assert_(isnan(float("nan"))) AssertionError: None # I renamed 'fortran' in Include/abstract.h to 'fort' because VC6 said 'fortran' is preserved word for compatibility sake. ---------- components: Build files: vc6-py3k.patch messages: 59127 nosy: ocean-city severity: normal status: open title: VC6 build patch for python3000 versions: Python 3.0 Added file: http://bugs.python.org/file9048/vc6-py3k.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 11:47:57 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 03 Jan 2008 10:47:57 -0000 Subject: [issue1720] VC6 build patch for release-maint25 Message-ID: <1199357277.46.0.784321926371.issue1720@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I have submitted the patch for py3k as issue1727. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 12:50:35 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 03 Jan 2008 11:50:35 -0000 Subject: [issue1727] VC6 build patch for python3000 Message-ID: <1199361035.8.0.907918965346.issue1727@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Hello. I noticed PC/VS7.1/pythoncore.vcproj lacks Modules/md5module.c while creating this patch. Thank you. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 15:39:09 2008 From: report at bugs.python.org (Fredrik Lundh) Date: Thu, 03 Jan 2008 14:39:09 -0000 Subject: [issue1698167] xml.etree document element.tag Message-ID: <1199371149.93.0.214302222411.issue1698167@psf.upfronthosting.co.za> Fredrik Lundh added the comment: This is fixed in the development version, so I'm closing this for now. The updated docs can be found here: http://docs.python.org/dev/library/xml.etree.elementtree.html ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 3 15:56:28 2008 From: report at bugs.python.org (Fredrik Lundh) Date: Thu, 03 Jan 2008 14:56:28 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib Message-ID: <1199372188.85.0.52019364305.issue1327@psf.upfronthosting.co.za> Fredrik Lundh added the comment: That changes to ceval should have introduced some kind of XML-RPC package limit seems a bit unlikely. If you can still reproduce this, can you try instrumenting the xmlrpclib.py library to see where it gets stuck? (passing in verbose=True to the Server[Proxy] constructor might be good enough) ---------- nosy: +effbot __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 16:25:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 15:25:59 -0000 Subject: [issue1725] -1e-1000 converted incorrectly Message-ID: <1199373959.29.0.3581529168.issue1725@psf.upfronthosting.co.za> Christian Heimes added the comment: I think we have found a bug in glibc's math code. I'm hanging around in #glibc and see if I can get an opinion on the matter. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 16:29:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 15:29:59 -0000 Subject: [issue1725] -1e-1000 converted incorrectly Message-ID: <1199374199.55.0.724336526768.issue1725@psf.upfronthosting.co.za> Christian Heimes added the comment: On Windows -1E-1000 returns 0.0, too. We may need to fix it in your own code and set the sign bit ourself. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 16:33:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 15:33:19 -0000 Subject: [issue1726] Remove Python/atof.c from PCBuild/pythoncore.vcproj Message-ID: <1199374399.19.0.911054533848.issue1726@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> tiran keywords: +patch, py3k nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 16:42:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 15:42:36 -0000 Subject: [issue1726] Remove Python/atof.c from PCBuild/pythoncore.vcproj Message-ID: <1199374956.71.0.325203924756.issue1726@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59672 Thanks! I'm not sure if it was causing any trouble but better be safe than sorry. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 17:05:41 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Jan 2008 16:05:41 -0000 Subject: [issue1725] -1e-1000 converted incorrectly Message-ID: <1199376341.28.0.0294507060155.issue1725@psf.upfronthosting.co.za> Mark Dickinson added the comment: Presumably float('-1e-1000') should also give -0. (?) If so, then it looks as though the fix ought to go in PyOS_ascii_strtod: one obvious possibility would be to replace any leading '-' sign by a '+' sign before calling the system strtod, then negate the result afterwards. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 17:45:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 16:45:26 -0000 Subject: [issue1567] Patch for new API method _PyImport_ImportModuleNoLock(char *name) Message-ID: <1199378726.88.0.264357452009.issue1567@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch does't replace all PyImport_ImportModule() calls with the new function. It replaces only the calls which may occure more than once and have a fixed name like "time". I've renamed the function to PyImport_ImportModuleNoBlock(). It should explain the purpose of the function better. It imports a module without blocking. Added file: http://bugs.python.org/file9049/trunk_import_noblock.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 17:45:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 16:45:31 -0000 Subject: [issue1567] Patch for new API method _PyImport_ImportModuleNoLock(char *name) Message-ID: <1199378731.88.0.469139913934.issue1567@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8888/import_nolock.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 17:57:46 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 16:57:46 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1199319060.95.0.0776451148099.issue1640@psf.upfronthosting.co.za> Message-ID: <477D1407.4070006@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > One nit: you added a blank line to the end of test_math.py. > This will cause the checkin to fail. :-) *grr* stupid white space check hook > One bigger issue: the sign() function doesn't seem to work properly for > nans. E.g. on Linux I get: > >>>> inf = 1e1000 >>>> nan = inf/inf >>>> mnan = -nan >>>> math.sign(nan) > -1 >>>> math.sign(mnan) > 1 > > IOW a positive nan is considered negative and vice versa. (This is > probably due to the way nans defy testing, always returning false.) If I recall the definition correctly NaNs don't have a sign. The content of the sign bit is not defined for NaNs. I could fix the sign but it's just eye candy and a waste of CPU cycles. IMO it would be more appropriate to return 0 for NaNs instead of +1 or -1. > I'm also curious why math.sign(0.0) returns 1 -- this is going to > cause a lot of confusion. math.sign(0.0) == 1 and math.sign(-0.0) == -1 is the main purpose of the sign() function. Most ordinary users are still going to use x > 0.0 or x < 0.0 instead of math.sign(). math.sign() is for the power users who need to determinate whether an operation hits the 0 from the left or right side of the number line. Because 0.0 == -0.0 it's not possible the distinguish a positive from a negative zero with comparison operations. if x == 0.0 and str(x).startswith("-") was the only existing way to detect a negative zero. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 18:28:15 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 17:28:15 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <477D1407.4070006@cheimes.de> Message-ID: Guido van Rossum added the comment: > > One nit: you added a blank line to the end of test_math.py. > > This will cause the checkin to fail. :-) > > *grr* stupid white space check hook No, you edited a line that didn't need editing. :-) > > One bigger issue: the sign() function doesn't seem to work properly for > > nans. E.g. on Linux I get: > > > >>>> inf = 1e1000 > >>>> nan = inf/inf > >>>> mnan = -nan > >>>> math.sign(nan) > > -1 > >>>> math.sign(mnan) > > 1 > > > > IOW a positive nan is considered negative and vice versa. (This is > > probably due to the way nans defy testing, always returning false.) > > If I recall the definition correctly NaNs don't have a sign. The content > of the sign bit is not defined for NaNs. I could fix the sign but it's > just eye candy and a waste of CPU cycles. IMO it would be more > appropriate to return 0 for NaNs instead of +1 or -1. Perhaps you recall wrong, as negating the nan returns one with the opposite sign? This seems to indicate that there are positive and negative nans. > > I'm also curious why math.sign(0.0) returns 1 -- this is going to > > cause a lot of confusion. > > math.sign(0.0) == 1 and math.sign(-0.0) == -1 is the main purpose of the > sign() function. Most ordinary users are still going to use x > 0.0 or x > < 0.0 instead of math.sign(). math.sign() is for the power users who > need to determinate whether an operation hits the 0 from the left or > right side of the number line. > > Because 0.0 == -0.0 it's not possible the distinguish a positive from a > negative zero with comparison operations. if x == 0.0 and > str(x).startswith("-") was the only existing way to detect a negative zero. Hm, OK, but then passing a zero of some other type (e.g. int) should also return +1 as the sign. I also think the function's name should be changed, because I (and I assume many others) have grown up with a sign() function that essentially returns cmp(x, 0.0). Perhaps it would be better to have a function math.isneg() that returns True for -0.0 and anything smaller and False for +0.0 and anything larger. It could also return the proper sign of a nan. I suggest that you check in the isinf() and isnan() functions and their tests once you have docs for them, and hold off on the sign() function until we've got agreement on it. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 18:57:43 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 17:57:43 -0000 Subject: [issue1567] Patch for new API method _PyImport_ImportModuleNoLock(char *name) Message-ID: <1199383063.52.0.353941222409.issue1567@psf.upfronthosting.co.za> Guido van Rossum added the comment: I see. I think there's still something uncomfortable with this function though -- it looks in sys.modules, but if it doesn't find it there, it invokes the full-blown import machinery, which calls the (possibly overridden) __import__ builtin, which in turn might do a relative import (at least in 2.6) or any amount of funny business. The only thing that really worries me here is the possibility of relative import. I'm thinking that relative import is really never meant to be when called from C, so perhaps it would be sufficient to modify the call to __import__ at the end of PyImport_Import() to add a 5th parameter, zero, to always force absolute import. A quick concept test shows that this doesn't break anything, though it is worth checking the docs. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 19:19:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 18:19:44 -0000 Subject: [issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2 Message-ID: <1199384384.26.0.969552508128.issue1688@psf.upfronthosting.co.za> Christian Heimes added the comment: Windows needs its own PyOS_StdioReadline() function in order to support wide chars. We can either use the low level functions _putwch() and _getwche(). Or we could probably use the more higher functions _cwprintf_s() (secure console wide char print format, oh I love MS' naming schema) and _cgetws_s(). __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 19:40:34 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 18:40:34 -0000 Subject: [issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2 Message-ID: <1199385634.58.0.194926657524.issue1688@psf.upfronthosting.co.za> Guido van Rossum added the comment: Cool. I suspect Unix will also require a customized version to be used in case GNU readline isn't present. And I wouldn't be surprised if GNU readline itself doesn't handle UTF-8 properly either! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 19:51:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 18:51:15 -0000 Subject: [issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2 In-Reply-To: <1199385634.58.0.194926657524.issue1688@psf.upfronthosting.co.za> Message-ID: <477D2EA0.3030500@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > I suspect Unix will also require a customized version to be used in case > GNU readline isn't present. > > And I wouldn't be surprised if GNU readline itself doesn't handle UTF-8 > properly either! GNU readline can handle UTF-8 chars fine on my system: ???: ? ? My locales are set to de_DE.UTF-8 Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 20:13:07 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 19:13:07 -0000 Subject: [issue1700] Regular Expression inline flags not handled correctly for some unicode characters Message-ID: <1199387587.63.0.477760676641.issue1700@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 59674. (2.5.2 branch) Committed revision 59675. (2.6 trunk) ---------- resolution: -> fixed status: open -> closed versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 20:18:31 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 03 Jan 2008 19:18:31 -0000 Subject: [issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2 Message-ID: <1199387911.7.0.20713891548.issue1688@psf.upfronthosting.co.za> Martin v. L?wis added the comment: If possible, I would like to see the C library phased out of Python on Windows, for file I/O. In this case, it would mean that ReadConsoleW is used directly for character input. Notice that _cgetws does not take a file handle as a parameter, but implicitly uses _coninpfh. As a consequence, PyOS_StdioReadline probably should change its parameter from FILE* to "file handle", and consequently rename it to, say, PyOS_Readline. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 20:26:30 2008 From: report at bugs.python.org (astronouth7303) Date: Thu, 03 Jan 2008 19:26:30 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199388390.0.0.11060735615.issue1728@psf.upfronthosting.co.za> New submission from astronouth7303: Something about distutils/cmd.py breaks inspect.findsource(). I am unsure if this is a bug with DistUtils or the inspect module. >>> import inspect, distutils.cmd >>> inspect.findsource(distutils.cmd.install_misc.get_outputs) Causes findsource() to receive an IndexError. >From some hacking, I've found that the root cause appears to be that linecache.getlines() returns a number of lines that do not match the actual file. (In my case, getlines() returns 405 lines when distutils/cmd.py has 478 lines.) This bug causes pydoc to break when it is pointed at distutils.cmd. This is on Ubuntu Gutsy, Python 2.5.1 ---------- components: None messages: 59145 nosy: astronouth7303 severity: normal status: open title: distutils.cmd breaks inspect versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 20:39:27 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Jan 2008 19:39:27 -0000 Subject: [issue1729] Allow float('infinity') as well as float('inf') Message-ID: <1199389167.5.0.55009136517.issue1729@psf.upfronthosting.co.za> New submission from Mark Dickinson: This request relates to issue 1635: http://bugs.python.org/issue1635 which allows cross-platform creation of infinities and nans. The IEEE754 standard, the C99 standard, and the standard on which Decimal is based all allow creation of an infinity from the string 'Infinity' (case-independent), as well as from 'inf'. Is there any reason not to allow this for floats? I'm happy to create a patch. ---------- components: Interpreter Core messages: 59146 nosy: marketdickinson severity: minor status: open title: Allow float('infinity') as well as float('inf') type: rfe versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 20:42:28 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 03 Jan 2008 19:42:28 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199389348.7.0.394625005536.issue1728@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I can't reproduce it with 2.5.1 on SuSE 10. Can you please report the exact traceback you see? ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 20:45:59 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Jan 2008 19:45:59 -0000 Subject: [issue1725] -1e-1000 converted incorrectly Message-ID: <1199389559.72.0.392082270962.issue1725@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a possible fix for this issue; it parses a number by first stripping leading whitespace and any sign, then passing the remaining string to the system strtod. This patch also fixes another bug in pystrtod.c, where ValueError is not raised on a hex float with a leading + sign: >>> float('0x3') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for float(): 0x3 >>> float('+0x3') # expect ValueError 3.0 Added file: http://bugs.python.org/file9050/pystrtod.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 20:50:19 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Jan 2008 19:50:19 -0000 Subject: [issue1729] Allow float('infinity') as well as float('inf') Message-ID: <1199389819.1.0.519546984557.issue1729@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sorry: brain not working. Please close as invalid. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 20:55:33 2008 From: report at bugs.python.org (astronouth7303) Date: Thu, 03 Jan 2008 19:55:33 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199390133.82.0.241697248969.issue1728@psf.upfronthosting.co.za> astronouth7303 added the comment: sqlite3/test/types.py also seems to cause the same error, although the difference is much wider (101 lines vs. 351). __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 20:57:07 2008 From: report at bugs.python.org (astronouth7303) Date: Thu, 03 Jan 2008 19:57:07 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199390227.76.0.381800526024.issue1728@psf.upfronthosting.co.za> astronouth7303 added the comment: The exact traceback is as follows: >>> findsource(distutils.cmd.install_misc.get_outputs) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/inspect.py", line 510, in findsource if pat.match(lines[lnum]): break IndexError: list index out of range __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 21:11:46 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Thu, 03 Jan 2008 20:11:46 -0000 Subject: [issue1472] Small bat files to build docs on Windows Message-ID: <1199391106.09.0.631055633028.issue1472@psf.upfronthosting.co.za> Changes by Joseph Armbruster: ---------- components: +Windows __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 21:19:56 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Thu, 03 Jan 2008 20:19:56 -0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1199391596.57.0.986788993791.issue1700463@psf.upfronthosting.co.za> Changes by Joseph Armbruster: ---------- components: +Windows _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 3 21:21:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 20:21:15 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: Message-ID: <477D43B9.3000109@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Hm, OK, but then passing a zero of some other type (e.g. int) should > also return +1 as the sign. I also think the function's name should be > changed, because I (and I assume many others) have grown up with a > sign() function that essentially returns cmp(x, 0.0). > > Perhaps it would be better to have a function math.isneg() that > returns True for -0.0 and anything smaller and False for +0.0 and > anything larger. It could also return the proper sign of a nan. I'm fine with a isneg() function but I wouldn't "fix" it for NaN. It has probably some kind of obscure meaning. The best explanation I was able to find, is http://www.cisl.ucar.edu/docs/trap.error/errortypes.html "Note: Since NaN is "not a number," there really isn't a "+" or "-" sign associated with it." Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 21:25:14 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Thu, 03 Jan 2008 20:25:14 -0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows Message-ID: <1199391914.98.0.105967797337.issue1677@psf.upfronthosting.co.za> Changes by Joseph Armbruster: ---------- components: +Windows __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 21:29:15 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Jan 2008 20:29:15 -0000 Subject: [issue1640] Enhancements for mathmodule Message-ID: <1199392155.37.0.611458347733.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Why not implement copysign? It's a standard, familiar function with well- documented meaning all over the web, and it can easily be used to create whatever sign test is necessary, letting the user decide what results (s)he wants for +/-0, +/-nan, etc. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 21:33:52 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 20:33:52 -0000 Subject: [issue1729] Allow float('infinity') as well as float('inf') Message-ID: <1199392432.43.0.0514686572316.issue1729@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 21:35:13 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 20:35:13 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1199392155.37.0.611458347733.issue1640@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Why not implement copysign? It's a standard, familiar function with well- > documented meaning all over the web, and it can easily be used to create > whatever sign test is necessary, letting the user decide what results > (s)he wants for +/-0, +/-nan, etc. Good idea. Since you seem to like providing patches, can you create one for math.copysign()? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 21:42:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 20:42:19 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: Message-ID: <477D48AA.2080502@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Good idea. Since you seem to like providing patches, can you create > one for math.copysign()? Don't forget it's copysign() on Unix but _copysign() on Windows. #if defined(MS_WINDOWS) || defined(HAVE_COPYSIGN) #ifdef MS_WINDOWS FUNC2(copysign, _copysign, #else FUNC2(copysign, copysign, #endif "doc"); #endif should work on all systems. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 21:50:25 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 20:50:25 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <477D48AA.2080502@cheimes.de> Message-ID: Guido van Rossum added the comment: > Guido van Rossum wrote: > > Good idea. Since you seem to like providing patches, can you create > > one for math.copysign()? > > Don't forget it's copysign() on Unix but _copysign() on Windows. > > #if defined(MS_WINDOWS) || defined(HAVE_COPYSIGN) > #ifdef MS_WINDOWS > FUNC2(copysign, _copysign, > #else > FUNC2(copysign, copysign, > #endif > "doc"); > #endif > > should work on all systems. Well, the Python API in the math module should always be called copysign(). :-) And what to do if neither is present? Are there any systems without it? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 21:53:17 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 20:53:17 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199393597.58.0.281796196538.issue1728@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can't repro either. I strongly suspect that this is because somehow linecache finds a different version of the module on sys.path. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 22:03:12 2008 From: report at bugs.python.org (Stephen P. Schaefer) Date: Thu, 03 Jan 2008 21:03:12 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1199394192.53.0.0616522209847.issue1301@psf.upfronthosting.co.za> Stephen P. Schaefer added the comment: I'm not sure of the scope of the "block" to which you're referring. As patched, the code returns a Tcl_Obj representing 0 length unicode string, which appears to me to be the correct behavior, and works for the applications I use (originally developed in python 2.3 and python 2.4). I doubt that it's worth special-casing away the call for a 0 length outbuf, the skipped for loop, plus the call to free the 0 length outbuf. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 22:30:50 2008 From: report at bugs.python.org (astronouth7303) Date: Thu, 03 Jan 2008 21:30:50 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199395850.66.0.486550720878.issue1728@psf.upfronthosting.co.za> astronouth7303 added the comment: Indeed. For the distutils.cmd case, linecache.updatecache() takes "cmd.py" and tracks that down to /usr/lib/python2.5/cmd.py. This would also explain the sqlite3.tests.types problem. The bug seems to be that the inspect module doesn't pass enough context information to linecache to unambiguously locate the file. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 22:32:00 2008 From: report at bugs.python.org (Robin Stocker) Date: Thu, 03 Jan 2008 21:32:00 -0000 Subject: [issue1730] Documentation corrections for os module Message-ID: <1199395920.46.0.540210712887.issue1730@psf.upfronthosting.co.za> New submission from Robin Stocker: I saw a minor inconsistency in the documentation of the os module and then somehow ended up proof-reading the whole file :). The result of this is attached as a patch against trunk. Summary of the changes: - Use the imperative tense in method descriptions - Some more links using semantic markup - Added example for file.seek - Consistently use "" instead of '' in text - or-ed, OR'd replaced with ORed - bit-wise replaced with bitwise Diffstat for the patch:: Doc/c-api/newtypes.rst | 2 Doc/library/fcntl.rst | 2 Doc/library/functions.rst | 2 Doc/library/msvcrt.rst | 2 Doc/library/os.rst | 155 +++++++++++++++++++++--------------------- Doc/library/stdtypes.rst | 9 +- Doc/library/winsound.rst | 2 Doc/reference/expressions.rst | 18 ++-- Lib/test/test_doctest.py | 2 Modules/fcntlmodule.c | 2 10 files changed, 101 insertions(+), 95 deletions(-) I hope the changes are ok. ---------- components: Documentation files: os-module-corrections.patch messages: 59160 nosy: robin.stocker severity: normal status: open title: Documentation corrections for os module Added file: http://bugs.python.org/file9051/os-module-corrections.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 22:35:13 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 21:35:13 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199396113.18.0.909333417977.issue1728@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you trace this a bit further? Can you suggest a specific modification that would fix this issue? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 22:41:02 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 03 Jan 2008 21:41:02 -0000 Subject: [issue1728] distutils.cmd breaks inspect In-Reply-To: <1199396113.18.0.909333417977.issue1728@psf.upfronthosting.co.za> Message-ID: <2c51ecee0801031341h615397aex9211b1eb4b9bf5ba@mail.gmail.com> Raghuram Devarakonda added the comment: When I printed the file name that is being passed to linecache.getlines() by findsource(), the file name is absolute path. So there may be nothing wrong with linecache itself. Can you see what is the name being passed in your case? We still need to trace what specific setting on OP's system is causing the problem. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 22:42:26 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 21:42:26 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1199396546.59.0.418760354316.issue1301@psf.upfronthosting.co.za> Guido van Rossum added the comment: I suspect the assert is an overflow check. But since asserts are compiled into no-ops unless we're using debug mode, I don't see the point of using an assert. Just to close the issue I'll replace it with a proper overflow check. ---------- assignee: -> gvanrossum priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 22:49:22 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 21:49:22 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1199396962.05.0.768996006947.issue1301@psf.upfronthosting.co.za> Guido van Rossum added the comment: Before I make a fool out of myself, what do folks think of this patch? Added file: http://bugs.python.org/file9052/tkinter.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 23:03:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 22:03:31 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: Message-ID: <477D5BAF.201@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Well, the Python API in the math module should always be called copysign(). :-) > > And what to do if neither is present? Are there any systems without it? takes care of it. It's a macro to define a function which accepts two floats and returns a float: FUNC2(funcname, func, docstring). On Windows _copysign is always defined and on other systems we can use HAVE_COPYSIGN. I added it to configure.in a while ago. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 23:04:28 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 22:04:28 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <477D5BAF.201@cheimes.de> Message-ID: Guido van Rossum added the comment: OK, just check it in then, but do add docs! On Jan 3, 2008 2:03 PM, Christian Heimes wrote: > > Christian Heimes added the comment: > > Guido van Rossum wrote: > > Well, the Python API in the math module should always be called copysign(). :-) > > > > And what to do if neither is present? Are there any systems without it? > > takes care of it. It's a macro to define a function which accepts two > floats and returns a float: FUNC2(funcname, func, docstring). > > On Windows _copysign is always defined and on other systems we can use > HAVE_COPYSIGN. I added it to configure.in a while ago. > > Christian > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 23:07:29 2008 From: report at bugs.python.org (Jamie Bliss) Date: Thu, 03 Jan 2008 22:07:29 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199398049.48.0.625117947284.issue1728@psf.upfronthosting.co.za> Jamie Bliss added the comment: depending on the use case, updatecache() will be passed 'distutils/cmd.py', but still turn that into '/usr/lib/python2.5/cmd.py'. I have not messed with my stock Python modules. My sys.path is: * /usr/lib/python2.5/site-packages/recaptcha_client-1.0.1-py2.5.egg * /usr/lib/python25.zip * /usr/lib/python2.5/lib-dynload * /usr/lib/python2.5/site-packages/Numeric * /usr/lib/python2.5/site-packages/PIL * /usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode * /usr/lib/python2.5/site-packages * /usr/lib/python2.5 * /usr/lib/python2.5/plat-linux2 * /usr/lib/python2.5/lib-tk * /usr/local/lib/python2.5/site-packages * /usr/lib/python2.5/site-packages/gst-0.10 * /var/lib/python-support/python2.5/pyinotify * /var/lib/python-support/python2.5 * /usr/lib/python2.5/site-packages/gtk-2.0 * /var/lib/python-support/python2.5/gtk-2.0 * /usr/lib/site-python I've also attached the script I used to discover the bug originally. (Much larger than the snippets I've been pasting here.) Just be warned that it writes a large number of files and produces considerable output. Added file: http://bugs.python.org/file9053/regen __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 23:14:05 2008 From: report at bugs.python.org (Stephen P. Schaefer) Date: Thu, 03 Jan 2008 22:14:05 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1199398445.88.0.62116667959.issue1301@psf.upfronthosting.co.za> Stephen P. Schaefer added the comment: It looks good to me (to the extent that means anything). I'm doing an rpmbuild now with your patch applied to the Fedora 7 .src.rpm, and I'll start using the result on my workstation ASAP. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 23:18:50 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 22:18:50 -0000 Subject: [issue1567] Patch for new API method _PyImport_ImportModuleNoLock(char *name) In-Reply-To: <1199383063.52.0.353941222409.issue1567@psf.upfronthosting.co.za> Message-ID: <477D5F48.6000704@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > The only thing that really worries me here is the possibility of > relative import. I'm thinking that relative import is really never > meant to be when called from C, so perhaps it would be sufficient to > modify the call to __import__ at the end of PyImport_Import() to add a > 5th parameter, zero, to always force absolute import. A quick concept > test shows that this doesn't break anything, though it is worth checking > the docs. Committed in r59678 I've changed PyImport_Import to always use absolute imports as requested. The docs didn't promise relative imports. It's probably a mistake to allow relative imports in the first place. I've also updated the docs and NEWS. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 3 23:20:16 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 22:20:16 -0000 Subject: [issue1730] Documentation corrections for os module Message-ID: <1199398816.37.0.218167642938.issue1730@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl keywords: +patch nosy: +georg.brandl priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 00:10:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:10:39 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199401839.64.0.15479176549.issue1728@psf.upfronthosting.co.za> Christian Heimes added the comment: The issue is probably related to http://bugs.python.org/issue1665 ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 00:10:50 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:10:50 -0000 Subject: [issue1727] VC6 build patch for python3000 Message-ID: <1199401850.05.0.390644527457.issue1727@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch, py3k priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 00:12:07 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 23:12:07 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199401927.86.0.754608809594.issue1728@psf.upfronthosting.co.za> Guido van Rossum added the comment: Do you happen to be on Ubuntu? Maybe this is the same as issue #1665 ? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 00:13:16 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:13:16 -0000 Subject: [issue1591] popen2.Popen3 class (Unix) documentation misleading / confusing Message-ID: <1199401996.44.0.0265894718048.issue1591@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> low versions: +Python 2.6 -Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 00:18:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:18:34 -0000 Subject: [issue761863] readline module that checks signals Message-ID: <1199402314.98.0.367521144826.issue761863@psf.upfronthosting.co.za> Christian Heimes added the comment: In Python 2.6 the readline module does check for signals. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 00:25:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:25:02 -0000 Subject: [issue906405] Build fails on XP w/mingw Message-ID: <1199402702.94.0.274854920737.issue906405@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug report is old and I haven't heard from problems with mingw recently. Please open a new bug report if it still fails for 2.5 and newer. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 00:28:41 2008 From: report at bugs.python.org (Thomas Dybdahl Ahle) Date: Thu, 03 Jan 2008 23:28:41 -0000 Subject: [issue1731] Random errors on interpreter shutdown Message-ID: <1199402921.07.0.182156121035.issue1731@psf.upfronthosting.co.za> New submission from Thomas Dybdahl Ahle: I have a pygtk program, that uses a fairly lot of threads in a pool. All of these threads are setDaemon to ensure the application shuts down when I call gtk.main_quit() About every second time I close the app, I get one or more errors from places in the program where a thread seams to have woken up, and now find all attributes None. This time I even got a message relating til the GIL: ... for errortype in (IOError, LogOnError, socket.error, EOFError): exceptions.AttributeError 'NoneType' object has no attribute 'error' python: Python/pystate.c:497: PyGILState_Ensure: Assertion (assertion) 'autoInterpreterState' failed. Afbrudt (SIGABRT) the socket reference simply comes from "import socket" in the beginning of the module. As the errors only occur during application shutdown, it has no practical effect, but it confuses users to post tons of bug reports. ---------- components: Interpreter Core messages: 59174 nosy: lobais severity: normal status: open title: Random errors on interpreter shutdown type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 00:29:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:29:10 -0000 Subject: [issue681515] smtpd.py move setuid, allow dashes Message-ID: <1199402950.98.0.478531584806.issue681515@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch is outdated, about 5 years old and not in unified diff format. Please create a new patch if you are still interested in the feature. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 00:32:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:32:36 -0000 Subject: [issue789290] Minor FP bug in object.c Message-ID: <1199403156.14.0.132322409043.issue789290@psf.upfronthosting.co.za> Christian Heimes added the comment: Tim, you are the expert in numbers. Is the patch still relevant for 2.5 and newer? ---------- assignee: -> tim_one keywords: +patch nosy: +tiran versions: +Python 2.5 -Python 2.2 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 00:33:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:33:54 -0000 Subject: [issue896330] pyconfig.h is not placed in --includedir Message-ID: <1199403234.2.0.0867339969517.issue896330@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm able to reproduce the bug with 2.6 ---------- nosy: +tiran priority: normal -> low severity: normal -> minor versions: +Python 2.6, Python 3.0 -Python 2.2 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 00:42:29 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 23:42:29 -0000 Subject: [issue1731] Random errors on interpreter shutdown Message-ID: <1199403749.8.0.505369784794.issue1731@psf.upfronthosting.co.za> Guido van Rossum added the comment: This has been fixed in 2.6, see revision 57216. We won't be fixing this in 2.4, although a vendor might consider this. Should we be fixing this in 2.5? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 00:43:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:43:53 -0000 Subject: [issue891930] configure argument --libdir is ignored Message-ID: <1199403833.86.0.705770777229.issue891930@psf.upfronthosting.co.za> Christian Heimes added the comment: The Python configure and make system could use a general overhaul but simply replacing lib/ with lib64/ isn't the right way. The topic should be discussed on python-dev and maybe PEPed, too. ---------- nosy: +tiran resolution: -> invalid status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 00:45:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:45:54 -0000 Subject: [issue708007] TelnetPopen3, TelnetBase, Expect split Message-ID: <1199403954.48.0.564022673938.issue708007@psf.upfronthosting.co.za> Christian Heimes added the comment: Are you still interested in the matter? Please discuss the idea on the python-dev mailing list and possible create a new patch for Python 2.6. ---------- nosy: +tiran resolution: -> out of date status: open -> pending ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 00:49:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:49:51 -0000 Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks Message-ID: <1199404191.65.0.00921331281921.issue1235@psf.upfronthosting.co.za> Christian Heimes added the comment: The quoting issue on Windows can easily be fixed by using subprocess instead of popen() ---------- nosy: +tiran priority: -> low versions: +Python 2.5, Python 2.6, Python 3.0 -Python 2.3 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 00:55:10 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Jan 2008 23:55:10 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1199404510.06.0.479496412605.issue1301@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 59685. (2.5.2 branch) Committed revision 59686. (2.6 trunk) ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 00:58:40 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:58:40 -0000 Subject: [issue1279] os.system() oddity under Windows XP SP2 Message-ID: <1199404720.63.0.0459789019483.issue1279@psf.upfronthosting.co.za> Christian Heimes added the comment: It might happen when the program hasn't terminated yet. You have to make sure the program has terminated before you read the file. Subprocess and its wait() should help. ---------- nosy: +tiran resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 00:59:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2008 23:59:53 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1199404793.13.0.0878907495096.issue1243@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal versions: -Python 2.3, Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 01:05:35 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:05:35 -0000 Subject: [issue1687] plistlib.py restricts to Python int when writing Message-ID: <1199405135.14.0.501023260559.issue1687@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in trunk r59688 Should it be backported to 2.5? ---------- nosy: +tiran resolution: -> fixed status: open -> pending versions: +Python 2.6, Python 3.0 -Python 2.3, Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 01:06:38 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:06:38 -0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1199405198.41.0.489515720321.issue815646@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:09:39 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 00:09:39 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1199405379.71.0.982394451578.issue1243@psf.upfronthosting.co.za> Guido van Rossum added the comment: Ping? I was hoping for a patch? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 01:10:00 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:10:00 -0000 Subject: [issue775964] fix test_grp failing on RedHat 6.2 Message-ID: <1199405400.49.0.540487471072.issue775964@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch versions: +Python 2.5 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:12:49 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:12:49 -0000 Subject: [issue683658] PyErr_Warn may cause import deadlock Message-ID: <1199405569.62.0.156565555592.issue683658@psf.upfronthosting.co.za> Christian Heimes added the comment: Is this still an issue for 2.5? If Python 2.5 may still dead lock then somebody should back port my PyImport_ImportModuleNoBlock() function. ---------- nosy: +tiran priority: normal -> high versions: +Python 2.5 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:16:11 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:16:11 -0000 Subject: [issue731991] find correct socklen_t type Message-ID: <1199405771.71.0.106242640287.issue731991@psf.upfronthosting.co.za> Christian Heimes added the comment: Martin, should the patch be ported and applied in 2.5 and 2.6? ---------- assignee: -> loewis nosy: +tiran versions: +Python 2.5, Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:18:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:18:31 -0000 Subject: [issue770280] PyMarshal_ReadLastObjectFromFile Message-ID: <1199405911.7.0.957777905964.issue770280@psf.upfronthosting.co.za> Christian Heimes added the comment: Is the patch still interesting for Python 2.6? ---------- nosy: +tiran resolution: -> remind status: open -> pending versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:22:14 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:22:14 -0000 Subject: [issue774751] slow socket binding & netinfo lookups Message-ID: <1199406134.25.0.890204229689.issue774751@psf.upfronthosting.co.za> Christian Heimes added the comment: Skip, I'm going over ancient bug reports. Has the problem been fixed? ---------- assignee: -> skip.montanaro nosy: +tiran versions: +Python 2.5, Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:25:38 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:25:38 -0000 Subject: [issue813453] restrictions in _tkinter built with threaded tk undocumented Message-ID: <1199406338.0.0.249327727558.issue813453@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Tkinter versions: +Python 2.5, Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:28:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:28:15 -0000 Subject: [issue860134] socketmodule.c does not pickup all symbols with MS visC++ Message-ID: <1199406495.98.0.560467400233.issue860134@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:33:44 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 00:33:44 -0000 Subject: [issue683658] PyErr_Warn may cause import deadlock Message-ID: <1199406824.66.0.917285138891.issue683658@psf.upfronthosting.co.za> Guido van Rossum added the comment: No, backporting that to 2.5 isn't an option; it introduces a new feature and breaks binary backwards compatibility by removing the PyImport_ImportModuleEx entry point from the executable (turning it into a macro). ---------- assignee: gvanrossum -> keywords: +64bit priority: high -> low resolution: remind -> ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:35:12 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 00:35:12 -0000 Subject: [issue683658] PyErr_Warn may cause import deadlock Message-ID: <1199406912.94.0.102844570137.issue683658@psf.upfronthosting.co.za> Guido van Rossum added the comment: Let's close this unless there's a response from one of the original stakeholders within a week (i.e. by Jan 11 2008). ---------- keywords: +patch -64bit ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:35:37 2008 From: report at bugs.python.org (Stephen P. Schaefer) Date: Fri, 04 Jan 2008 00:35:37 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1199406937.63.0.307796832354.issue1301@psf.upfronthosting.co.za> Stephen P. Schaefer added the comment: Mr. van Rossum's patch, applied to the Fedora 7 .src.rpm, is working for me. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 01:38:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:38:08 -0000 Subject: [issue1481296] long(float('nan'))!=0L Message-ID: <1199407088.3.0.626050432025.issue1481296@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59689 trunk Backport it to 2.5? ---------- nosy: +tiran resolution: -> fixed status: open -> pending versions: +Python 2.5 -Python 2.3 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 01:39:03 2008 From: report at bugs.python.org (Thomas Dybdahl Ahle) Date: Fri, 04 Jan 2008 00:39:03 -0000 Subject: [issue1731] Random errors on interpreter shutdown Message-ID: <1199407143.6.0.208875359313.issue1731@psf.upfronthosting.co.za> Thomas Dybdahl Ahle added the comment: The fix looks nice. I'll just implement it locally in my app for python < 2.4. Thanks __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 01:39:33 2008 From: report at bugs.python.org (Jamie Bliss) Date: Fri, 04 Jan 2008 00:39:33 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199407173.34.0.0227433683446.issue1728@psf.upfronthosting.co.za> Jamie Bliss added the comment: They might be the same bug, with different manifestations. That bug is starting to get rather annoying. (At first, I thought it wasn't. Surprise, surprise.) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 01:40:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:40:18 -0000 Subject: [issue945861] dir(object) does not list __name__ Message-ID: <1199407218.45.0.320634416021.issue945861@psf.upfronthosting.co.za> Christian Heimes added the comment: __name__ comes from object's meta class type just as other attributes like __bases__. It's a bit surprising at first. ---------- nosy: +tiran resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:40:57 2008 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 04 Jan 2008 00:40:57 -0000 Subject: [issue774751] slow socket binding & netinfo lookups Message-ID: <1199407257.24.0.428047374102.issue774751@psf.upfronthosting.co.za> Skip Montanaro added the comment: I have no idea, but you can close this as far as I'm concerned. Skip ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:42:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:42:10 -0000 Subject: [issue798876] windows sys.path contains nonexistant directory Message-ID: <1199407330.7.0.630441738996.issue798876@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 -Python 2.3, Python 2.4 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:43:06 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:43:06 -0000 Subject: [issue1081879] Pydoc can't find browser (bug+solution!) Message-ID: <1199407386.35.0.390559129199.issue1081879@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low versions: +Python 2.5, Python 2.6 -Python 2.3 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 01:43:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:43:58 -0000 Subject: [issue614555] Rewrite _reduce and _reconstructor in C Message-ID: <1199407438.17.0.995603746557.issue614555@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:44:12 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:44:12 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1199407452.68.0.407049776302.issue1234@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: -Python 2.3, Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 01:45:42 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:45:42 -0000 Subject: [issue774751] slow socket binding & netinfo lookups Message-ID: <1199407542.43.0.117202985977.issue774751@psf.upfronthosting.co.za> Christian Heimes added the comment: Closed as requested. Side note: I don't recall having the bug during my Zope and Plone development time on Mac OS X 10.3 (PPC). ---------- resolution: postponed -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:57:20 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:57:20 -0000 Subject: [issue779218] 2.3c2 test_pwd fails on Mac OS X 10.2.6 Message-ID: <1199408240.69.0.922180165355.issue779218@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> duplicate status: open -> closed superseder: -> fix test_grp failing on RedHat 6.2 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 01:59:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 00:59:41 -0000 Subject: [issue828743] bdist_rpm failure when no setup.py Message-ID: <1199408381.71.0.154346593916.issue828743@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low type: -> rfe versions: +Python 2.5, Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 02:10:56 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 01:10:56 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1199409056.22.0.114181710212.issue1234@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, accepted for 2.5 and 2.6. Can someone with a stake and submit access (e.g. lemburg) check it in? ---------- assignee: -> lemburg resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 02:11:43 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 01:11:43 -0000 Subject: [issue1728] distutils.cmd breaks inspect Message-ID: <1199409103.95.0.497069091276.issue1728@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> duplicate status: open -> closed superseder: -> re.match.func_code.co_filename returns "re.py" __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 02:13:18 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 01:13:18 -0000 Subject: [issue614555] Rewrite _reduce and _reconstructor in C Message-ID: <1199409198.01.0.021771949748.issue614555@psf.upfronthosting.co.za> Guido van Rossum added the comment: I just don't see this happening. Possibly it's out of date. Lots of things have changed in the pickle world since 2002. ---------- resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 02:16:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 01:16:26 -0000 Subject: [issue1028697] Problem linking on windows using mingw32 and C++ Message-ID: <1199409386.47.0.182359134992.issue1028697@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> duplicate status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 02:18:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 01:18:41 -0000 Subject: [issue730473] Add Py_AtInit() startup hook for extenders Message-ID: <1199409521.12.0.736559560958.issue730473@psf.upfronthosting.co.za> Christian Heimes added the comment: Where is the new patch? :) ---------- nosy: +tiran type: -> rfe versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 02:22:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 01:22:10 -0000 Subject: [issue837577] cryptic os.spawnvpe() return code Message-ID: <1199409730.25.0.965537261114.issue837577@psf.upfronthosting.co.za> Christian Heimes added the comment: Neal? ---------- nosy: +tiran priority: normal -> low severity: normal -> minor title: cryptic os.spawnvpe() return code -> cryptic os.spawnvpe() return code type: -> rfe versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 02:21:07 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 01:21:07 -0000 Subject: [issue1054943] Python may contain NFC/NFKC bug per Unicode PRI #29 Message-ID: <1199409667.66.0.993821676698.issue1054943@psf.upfronthosting.co.za> Christian Heimes added the comment: Python 2.6 and probably also 2.5 contains still the line if (comb1 && comb == comb1) {...} ---------- nosy: +tiran versions: +Python 2.5, Python 2.6 -Python 2.3 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 02:24:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 01:24:02 -0000 Subject: [issue935117] pkgutil doesn't understand case-senseless filesystems Message-ID: <1199409842.0.0.809581991879.issue935117@psf.upfronthosting.co.za> Christian Heimes added the comment: Fred, do you still want to fix the bug? ---------- nosy: +tiran type: -> rfe versions: +Python 2.5, Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 02:30:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 01:30:45 -0000 Subject: [issue886488] WinPython 2.3.3 crashes using popen2 to spawn lots of child Message-ID: <1199410245.1.0.669475629363.issue886488@psf.upfronthosting.co.za> Christian Heimes added the comment: Modules/posixmodule.c:_PyPopen() needs to check for NULL after the _fdopen() calls. ---------- nosy: +tiran priority: normal -> high versions: +Python 2.5, Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 02:32:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 01:32:32 -0000 Subject: [issue763708] Failures in test_macostools for --enable-unicode=ucs4 Message-ID: <1199410352.86.0.225633967829.issue763708@psf.upfronthosting.co.za> Christian Heimes added the comment: Happy New Year Jack! How are you :) *scnr* ---------- nosy: +tiran versions: +Python 2.5, Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 02:33:47 2008 From: report at bugs.python.org (Thomas Dybdahl Ahle) Date: Fri, 04 Jan 2008 01:33:47 -0000 Subject: [issue1731] Random errors on interpreter shutdown Message-ID: <1199410427.74.0.466188498062.issue1731@psf.upfronthosting.co.za> Thomas Dybdahl Ahle added the comment: I run this now in the beginning of my code. As far as I can see it works fine. if not hasattr(Thread, "_Thread__bootstrap_inner"): class SafeThread (Thread): def encaps(self): try: self._Thread__bootstrap_inner() except: if self.__daemonic and sys_ is None: return raise setattr(SafeThread, "_Thread__bootstrap_inner", SafeThread._Thread__bootstrap) setattr(SafeThread, "_Thread__bootstrap", SafeThread.encaps) threading.Thread = SafeThread __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 02:34:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 01:34:41 -0000 Subject: [issue1005895] curses for win32 Message-ID: <1199410481.42.0.61394321724.issue1005895@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Windows versions: +Python 2.6 -Python 2.3 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 02:55:46 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 01:55:46 -0000 Subject: [issue1548687] C modules reloaded on certain failed imports Message-ID: <1199411746.91.0.57043854746.issue1548687@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5 -Python 2.3 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 02:58:48 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 01:58:48 -0000 Subject: [issue1433886] pointer aliasing causes core dump, with workaround Message-ID: <1199411928.71.0.666692866751.issue1433886@psf.upfronthosting.co.za> Christian Heimes added the comment: Should we fix the general issue in Python 3.0 now that Python 3.0 is fast apace? CAN we fix it? ---------- nosy: +tiran versions: +Python 3.0 -Python 2.3 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 04:01:37 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 04 Jan 2008 03:01:37 -0000 Subject: [issue1732] Doc build fails with a KeyError Message-ID: <1199415697.63.0.117760365705.issue1732@psf.upfronthosting.co.za> New submission from Raymond Hettinger: . . . Traceback (most recent call last): File "tools/sphinx-build.py", line 24, in sys.exit(main(sys.argv)) File "/home/rhettinger/py26/Doc/tools/sphinx/__init__.py", line 141, in main builderobj.build_update() File "/home/rhettinger/py26/Doc/tools/sphinx/builder.py", line 199, in build_update summary='%d source files that are out of date' % len(to_build)) File "/home/rhettinger/py26/Doc/tools/sphinx/builder.py", line 249, in build self.finish() File "/home/rhettinger/py26/Doc/tools/sphinx/builder.py", line 440, in finish download_base_url = self.config['download_base_url'], KeyError: 'download_base_url' make: *** [build] Error 1 ---------- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 59209 nosy: georg.brandl, rhettinger severity: normal status: open title: Doc build fails with a KeyError versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 04:24:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 03:24:45 -0000 Subject: [issue1732] Doc build fails with a KeyError Message-ID: <1199417085.49.0.673385667313.issue1732@psf.upfronthosting.co.za> Christian Heimes added the comment: You have to update the tools with make update. I had some issues with the update so I removed the tools directory followed by svn up and make update. ---------- nosy: +tiran resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 04:51:26 2008 From: report at bugs.python.org (Tim Peters) Date: Fri, 04 Jan 2008 03:51:26 -0000 Subject: [issue1640] Enhancements for mathmodule Message-ID: <1199418685.94.0.940898681977.issue1640@psf.upfronthosting.co.za> Tim Peters added the comment: The functionality of what was called (and I agree confusingly so) "sign()" here is supplied by "signbit()" in C99. That standard isn't free, but the relevant part is incorporated in the free Open Group standards: http://www.opengroup.org/onlinepubs/000095399/functions/signbit.html The 754 standard says NaNs have sign bits, but assigns no meaning to them. In particular, the value of the sign bit of a NaN resulting from a string->double routine applied to the string "nan" isn't defined by 754, or (AFAICT) by C99 either. ---------- nosy: +tim_one __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 05:00:44 2008 From: report at bugs.python.org (Tim Peters) Date: Fri, 04 Jan 2008 04:00:44 -0000 Subject: [issue789290] Minor FP bug in object.c Message-ID: <1199419244.91.0.747201982312.issue789290@psf.upfronthosting.co.za> Tim Peters added the comment: Unassigned myself -- I don't care about this 4 years later either ;-) ---------- assignee: tim_one -> nobody nosy: +nobody ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 05:10:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 04:10:28 -0000 Subject: [issue953599] asyncore misses socket closes when poll is used Message-ID: <1199419828.36.0.669320562843.issue953599@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 05:11:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 04:11:04 -0000 Subject: [issue1598083] Top-level exception handler writes to stdout unsafely Message-ID: <1199419864.59.0.397162491799.issue1598083@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 05:17:57 2008 From: report at bugs.python.org (Senthil) Date: Fri, 04 Jan 2008 04:17:57 -0000 Subject: [issue1698] urlparse and usernames containing @ In-Reply-To: <1199315659.53.0.341723117629.issue1698@psf.upfronthosting.co.za> Message-ID: <20080104042916.GD3607@gmail.com> Senthil added the comment: Hi Guido, I have added the unit tests, tested it on my system and created a new patch combining the previous one against the trunk. You can verify and check in this. Thank you, Senthil Added file: http://bugs.python.org/file9054/issue1698-withtests.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: issue1698-withtests.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080104/f573c1e6/attachment.txt From report at bugs.python.org Fri Jan 4 05:37:19 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Fri, 04 Jan 2008 04:37:19 -0000 Subject: [issue1572210] help(x) for keywords too Message-ID: <1199421439.94.0.578843554359.issue1572210@psf.upfronthosting.co.za> Joseph Armbruster added the comment: This issue should probably be closed. Performing the decompile on the command line as directed by the interpreter is as trivial as firing up the interpreter itself. It would make more sense to add an option to the installer that would automagically perform the decompile of the docs via an option or something at the users request. Your Thoughts? ---------- nosy: +JosephArmbruster _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 05:42:37 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 04:42:37 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199421757.36.0.603753218149.issue932563@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 05:42:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 04:42:57 -0000 Subject: [issue1193610] Expat Parser to supply document locator in incremental parse Message-ID: <1199421777.95.0.72918689858.issue1193610@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 06:42:43 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 04 Jan 2008 05:42:43 -0000 Subject: [issue1733] Maybe PC/VS7.1/pythoncore.vcproj is missing Modules/md5module.c Message-ID: <1199425362.34.0.0306392142535.issue1733@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto: I addressed this in issue1727, but I thought it could be better to create new tracker item. Probably attached patch is needed. Thank you. ---------- components: Build files: md5module.patch messages: 59215 nosy: ocean-city severity: normal status: open title: Maybe PC/VS7.1/pythoncore.vcproj is missing Modules/md5module.c versions: Python 3.0 Added file: http://bugs.python.org/file9055/md5module.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 06:50:40 2008 From: report at bugs.python.org (L. Peter Deutsch) Date: Fri, 04 Jan 2008 05:50:40 -0000 Subject: [issue1734] no effect if metaclass modifies dict Message-ID: <1199425839.96.0.974178478266.issue1734@psf.upfronthosting.co.za> New submission from L. Peter Deutsch: In the following, dir(Node) should include the name 'z', and Node.z should be 'Node'. However, dir(Node) does not include 'z', and Node.z is undefined (AttributeError). This is directly contrary to the Python documentation, which says "metaclasses can modify dict". class MetaNode(type): def __init__(cls, name, bases, cdict): cdict['z'] = name type.__init__(name, bases, cdict) class Node(object): __metaclass__ = MetaNode print dir(Node) print Node.z ---------- components: Interpreter Core messages: 59216 nosy: lpd severity: normal status: open title: no effect if metaclass modifies dict versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 07:35:17 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 04 Jan 2008 06:35:17 -0000 Subject: [issue1481296] long(float('nan'))!=0L Message-ID: <1199428517.66.0.172850715735.issue1481296@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The change in the trunk seems like a good backport candidate, it fixes an issue with float conversion on OSX compared to other platforms. That said, I don't like the patch. This makes the current behaviour of converting float NaN's to 0 the defined behaviour, which feels wrong (he says without having the slightest idea of what the relevant standards might say about this). Shouldn't this raise an exception instead of silently converting? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 09:39:42 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 04 Jan 2008 08:39:42 -0000 Subject: [issue1734] no effect if metaclass modifies dict Message-ID: <1199435982.35.0.329810993025.issue1734@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: When designing a metaclass, you should override __new__, not __init__: class MetaNode(type): def __new__(cls, name, bases, cdict): cdict['z'] = name return type.__new__(cls, name, bases, cdict) class Node(object): __metaclass__ = MetaNode ---------- nosy: +amaury.forgeotdarc resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 12:02:40 2008 From: report at bugs.python.org (Eric Andresen) Date: Fri, 04 Jan 2008 11:02:40 -0000 Subject: [issue1735] tarfile.TarFile.extractall not setting directory permissions correctly Message-ID: <1199444560.86.0.587752807874.issue1735@psf.upfronthosting.co.za> New submission from Eric Andresen: The tarfile.TarFile.extractall() method is [by default] silently failing to set directory permissions and times on all but the lexically-latest directory extracted. This is due to an unintentional re-use of the 'path' variable. The provided patch renames the second 'path' variable to 'dirpath' which resolves the problem. ---------- components: Library (Lib) files: python-tarfile-extractall-fix.patch messages: 59219 nosy: eandres severity: normal status: open title: tarfile.TarFile.extractall not setting directory permissions correctly versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9056/python-tarfile-extractall-fix.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 12:04:27 2008 From: report at bugs.python.org (Eric Andresen) Date: Fri, 04 Jan 2008 11:04:27 -0000 Subject: [issue1735] tarfile.TarFile.extractall not setting directory permissions correctly Message-ID: <1199444667.1.0.755882795296.issue1735@psf.upfronthosting.co.za> Changes by Eric Andresen: ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 12:37:04 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 04 Jan 2008 11:37:04 -0000 Subject: [issue1735] tarfile.TarFile.extractall not setting directory permissions correctly Message-ID: <1199446624.79.0.81210777018.issue1735@psf.upfronthosting.co.za> Changes by Lars Gust?bel: ---------- assignee: -> lars.gustaebel nosy: +lars.gustaebel __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 13:58:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 12:58:18 -0000 Subject: [issue1733] Maybe PC/VS7.1/pythoncore.vcproj is missing Modules/md5module.c Message-ID: <1199451498.95.0.859335984537.issue1733@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59708 Thanks again! I don't have VC 6 and VS 7.1 on my machine to test the build directories and your fixes. I hope they are fine. It looks ok :) ---------- nosy: +tiran resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 13:58:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 12:58:59 -0000 Subject: [issue1735] tarfile.TarFile.extractall not setting directory permissions correctly Message-ID: <1199451539.11.0.137537238144.issue1735@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch priority: -> high versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 14:11:40 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 13:11:40 -0000 Subject: [issue1687] plistlib.py restricts to Python int when writing Message-ID: <1199452300.18.0.565761934927.issue1687@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal resolution: fixed -> remind versions: -Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 14:14:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 13:14:41 -0000 Subject: [issue1567] Patch for new API method _PyImport_ImportModuleNoLock(char *name) Message-ID: <1199452481.25.0.422321276863.issue1567@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 14:23:11 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 13:23:11 -0000 Subject: [issue1713] posixpath.ismount() claims symlink to a mountpoint is a mountpoint. Message-ID: <1199452991.15.0.500755876801.issue1713@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59709 (trunk) and r59710 (2.5) ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 14:34:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 13:34:05 -0000 Subject: [issue1727] VC6 build patch for python3000 Message-ID: <1199453645.4.0.0184072255974.issue1727@psf.upfronthosting.co.za> Christian Heimes added the comment: I've applied a fraction of your patch in r59711 but the part for PC/VS6 didn't apply. It may be a newline problem. Can you send me the files in a zip or tar archive, please? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 14:36:09 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 13:36:09 -0000 Subject: [issue1527] Problem with static libs on Windows Message-ID: <1199453769.0.0.143803366417.issue1527@psf.upfronthosting.co.za> Christian Heimes added the comment: Already fixed in svn ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 15:02:50 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 04 Jan 2008 14:02:50 -0000 Subject: [issue1735] tarfile.TarFile.extractall not setting directory permissions correctly Message-ID: <1199455370.37.0.113104774504.issue1735@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Thanks for the patch. I added a testcase and applied it to the trunk, see r59712. Python 2.5 follows later on. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 15:08:52 2008 From: report at bugs.python.org (lafcadio) Date: Fri, 04 Jan 2008 14:08:52 -0000 Subject: [issue1687] plistlib.py restricts to Python int when writing Message-ID: <1199455732.51.0.860845410184.issue1687@psf.upfronthosting.co.za> lafcadio added the comment: tiran wrote: > Should it be backported to 2.5? I'm sure to understand what 'backport' means. Of course it would be nice if in future 2.5 versions the read data could be written. But for me its not important. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 15:47:18 2008 From: report at bugs.python.org (Alan McIntyre) Date: Fri, 04 Jan 2008 14:47:18 -0000 Subject: [issue1739648] zipfile.testzip() using progressive file reads Message-ID: <1199458037.99.0.321685341575.issue1739648@psf.upfronthosting.co.za> Alan McIntyre added the comment: This sort of change definitely needs to be made to avoid reading huge files into memory for testzip(). I've attached a modified patch as zipfile_testzip_amcintyre.diff; it didn't seem appropriate to have a module-level variable for the size of the test read, and I made a few other minor tweaks. ---------- nosy: +alanmcintyre Added file: http://bugs.python.org/file9057/zipfile_testzip_amcintyre.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 15:47:23 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 04 Jan 2008 14:47:23 -0000 Subject: [issue1735] tarfile.TarFile.extractall not setting directory permissions correctly Message-ID: <1199458043.59.0.777378401724.issue1735@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Committed to release25-maint branch as r59713. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 15:53:49 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 04 Jan 2008 14:53:49 -0000 Subject: [issue1736] Three bugs of FCICreate (PC/_msi.c) Message-ID: <1199458428.92.0.688794479817.issue1736@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto: I have fixed three bugs of msilib.FCICreate() 1. msilib.FCICreate("a.cab") creates ".a.cab" (extra leading dot) In recent cab SDK's FCI-FDI.doc, # quote start The szCab field should contain a string which contains the name of the first cabinet to be created (e.g. ?APP1.CAB?). In the event of multiple cabinets being created, the GetNextCab function called by the FCIAddFile API allows subsequent cabinet names to be specified. The szCabPath field should contain the complete path of where to create the cabinet (e.g. ?C:\MYFILES\?). # quote end Currently, _msi.c separate "C:\\MYFILES\\APP1.CAB" to szCabPath "C:" and szCab "\\MYFILES\\APP1.CAB". 2. Probably, "long names" error check doesn't count null-terminator now. 3. Usually, multibyte character may contain "\\" as trailing-byte. (like "?" in Japanese) Not to count this as path separator, I used CharNext(). Thank you. ---------- components: Library (Lib) files: _msi.patch messages: 59228 nosy: ocean-city severity: normal status: open title: Three bugs of FCICreate (PC/_msi.c) versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9058/_msi.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 16:04:12 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 04 Jan 2008 15:04:12 -0000 Subject: [issue1727] VC6 build patch for python3000 Message-ID: <1199459052.7.0.123712357983.issue1727@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Thank you. This file is zipped file. Added file: http://bugs.python.org/file9059/PC_VC6.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 16:24:12 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 15:24:12 -0000 Subject: [issue889544] win32 raw socket support Message-ID: <1199460252.79.0.795023627108.issue889544@psf.upfronthosting.co.za> Christian Heimes added the comment: I've implemented the WSAIoctl wrapper myself and added a working example for a network sniffer. IPPROTO_RAW is wrong, it must be IPPROTO_IP. ---------- nosy: +tiran resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 16:25:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 15:25:57 -0000 Subject: [issue1736] Three bugs of FCICreate (PC/_msi.c) Message-ID: <1199460357.97.0.506285328387.issue1736@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> loewis components: +Windows keywords: +patch, py3k nosy: +loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 16:29:59 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 04 Jan 2008 15:29:59 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1199460599.51.0.689507606717.issue1243@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I was under the impression that no change is necessary but I will take a closer look and will see if something needs to be done. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 16:35:17 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 15:35:17 -0000 Subject: [issue1727] VC6 build patch for python3000 Message-ID: <1199460917.44.0.438341327912.issue1727@psf.upfronthosting.co.za> Christian Heimes added the comment: Committed in 59720 Thanks Hiro! I still wonder why you are still using VS6 :) ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 16:49:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 15:49:29 -0000 Subject: [issue846388] Check for signals during regular expression matches Message-ID: <1199461769.74.0.385632484983.issue846388@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> rfe versions: +Python 2.5, Python 2.6 -Python 2.4 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 16:50:24 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 15:50:24 -0000 Subject: [issue1089358] need siginterrupt() on Linux - impossible to do timeouts Message-ID: <1199461824.02.0.765378139105.issue1089358@psf.upfronthosting.co.za> Christian Heimes added the comment: Next time please give the patch a more meaningful name than "patch" :) ---------- components: +Interpreter Core keywords: +patch nosy: +tiran versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 17:03:35 2008 From: report at bugs.python.org (Dariusz Suchojad) Date: Fri, 04 Jan 2008 16:03:35 -0000 Subject: [issue1737] Windows installer issue (ObjectBrowser.py) Message-ID: <1199462615.21.0.577334644902.issue1737@psf.upfronthosting.co.za> New submission from Dariusz Suchojad: Hello, for some reasons I cannot install Python 2.5.1 using the default MSI package which may be found here http://www.python.org/ftp/python/2.5.1/python-2.5.1.msi. This only happens on two of my PC's at work but I cannot reproduce it at home. The only difference I could find between those Windows is that the PC's at work are connected to Active Directory domain whereas my home machine isn't. I tried to install Python as a domain user and also as a local administrator but every time I encountered the very same screen (see attached file objectbrowser.png) and then the installation process rollbacks. I'd like to investigate it further but I have no slightest idea where to start. Do you perhaps have any suggestions? It's all Windows XP SP2. ---------- components: Installation, Windows files: objectbrowser.png messages: 59234 nosy: dsuch severity: normal status: open title: Windows installer issue (ObjectBrowser.py) type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9060/objectbrowser.png __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 17:11:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 16:11:52 -0000 Subject: [issue1737] Windows installer issue (ObjectBrowser.py) Message-ID: <1199463112.47.0.588564326974.issue1737@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> loewis nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 17:17:56 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 04 Jan 2008 16:17:56 -0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1199463476.01.0.169636759827.issue1700463@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I zipped PC/VC6/* as files. Added file: http://bugs.python.org/file9061/vc6-trunk-ver4c.zip _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 17:18:25 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 04 Jan 2008 16:18:25 -0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1199463505.9.0.905496385167.issue1700463@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I zipped PC/VC6/* as files. Added file: http://bugs.python.org/file9062/vc6-trunk-ver4c.zip _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 17:23:07 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 04 Jan 2008 16:23:07 -0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1199463787.87.0.424154550406.issue1700463@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Oops, sorry for double post. My network provider now stucks somehow... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 17:29:55 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Fri, 04 Jan 2008 16:29:55 -0000 Subject: [issue798876] windows sys.path contains nonexistant directory Message-ID: <1199464195.86.0.617554700715.issue798876@psf.upfronthosting.co.za> Joseph Armbruster added the comment: If I look at Lib/plat-win back at rev 16910, winreg.py could be found there. Everything I see in the tree referencing plat-win is documentation, except the PYTONPATH define itself. It looks like Lib/plat-win was removed back in revision 16911 [Aug 20,2000]. Log output: Remove the winreg module from the project. I don't believe any docs changes are needed (only reference to winreg I could find was in libwinreg.tex, which is documenting _winreg, and merely mentions that a higher-level winreg module *may* appear someday; that's still true). And made its way back in, in 27697 [July 19, 2002]. Log output: Land Patch [ 566100 ] Rationalize DL_IMPORT and DL_EXPORT. I'm thinking this is stale code. As per the test app, I know from a previous inquiry of mine that C:\WINNT\system32\python25.zip (and the like on different systems / version) is in fact necessary. Your thoughts? ---------- nosy: +JosephArmbruster ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 17:55:26 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Fri, 04 Jan 2008 16:55:26 -0000 Subject: [issue1442] pythonstartup addition of minor error checking Message-ID: <1199465726.79.0.415592838873.issue1442@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Backport to 2.6a0 and tested with: Python 2.6a0 (trunk:59710M, Jan 4 2008, 11:36:45) [MSC v.1500 32 bit (Intel)] on win32 Added file: http://bugs.python.org/file9063/pythonstartup.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 18:07:34 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 17:07:34 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1199466454.4.0.682932328455.issue1243@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm, perhaps I misinterpreted the discussion. If no patch is necessary, please close as won't fix or invalid. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 18:13:52 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 04 Jan 2008 17:13:52 -0000 Subject: [issue1243] option.dest not set when callback called with optparse In-Reply-To: <1199466454.4.0.682932328455.issue1243@psf.upfronthosting.co.za> Message-ID: <2c51ecee0801040913l31a9fd45hbcbe7c3d8a171163@mail.gmail.com> Raghuram Devarakonda added the comment: > Hm, perhaps I misinterpreted the discussion. If no patch is necessary, > please close as won't fix or invalid. I spent some time looking at optparse code and OP's request. _check_dest has a clear comment that says "dest" will be set iff a "store" action is selected (which callback is not) or if a "type" is given. But from the code itself, I don't see how setting "dest" in all cases would be bad. Do you want to assign this to Greg Ward to ask his opinion? Also, it doesn't look like we can directly patch optparse.py as it seems to be auto-generated. On a side note, I don't have tracker permissions to change status. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 18:19:17 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 04 Jan 2008 17:19:17 -0000 Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input Message-ID: <1199467157.77.0.0764766217247.issue1195@psf.upfronthosting.co.za> Ralf Schmitt added the comment: The following patch fixes it. The end-of-file indicator is still set, fgets returns NULL when ctrl-c is pressed, and the code checks for feof(fp) which is true. PyErr_CheckSignals() isn't called. This patch calls clearerr on the filepointer and consequently after ctrl-c feof(fp) is false and PyErr_CheckSignals is called. What I don't understand is why the backtrace says the KeyboardInterrupt happens in raw_input. PyErr_CheckSignals must be called on the "pass" statement otherwise something would be fundamentally broken (But I guess then python somehow saves the last real bytecode command). ~/Python-2.5.1/ hg diff diff --git a/Parser/myreadline.c b/Parser/myreadline.c --- a/Parser/myreadline.c +++ b/Parser/myreadline.c @@ -44,6 +44,7 @@ my_fgets(char *buf, int len, FILE *fp) if (PyOS_InputHook != NULL) (void)(PyOS_InputHook)(); errno = 0; + clearerr(fp); p = fgets(buf, len, fp); if (p != NULL) return 0; /* No error */ ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 18:21:19 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 17:21:19 -0000 Subject: [issue1089358] need siginterrupt() on Linux - impossible to do timeouts Message-ID: <1199467279.21.0.543590795526.issue1089358@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks okay, but needs docs. ---------- nosy: +gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 18:32:05 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 04 Jan 2008 17:32:05 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1199467925.45.0.505018064463.issue1243@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: FWIW, the change to _check_dest to always set 'dest' breaks quite a few tests. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 18:35:17 2008 From: report at bugs.python.org (L. Peter Deutsch) Date: Fri, 04 Jan 2008 17:35:17 -0000 Subject: [issue1734] documentation on metaclasses is incomplete and misleading Message-ID: <1199468117.03.0.638975631805.issue1734@psf.upfronthosting.co.za> L. Peter Deutsch added the comment: Please reopen this issue as a documentation bug. The documentation for __new__ in section 3.4.1 says: __new__() is intended mainly to allow subclasses of immutable types (like int, str, or tuple) to customize instance creation. The documentation for metaclasses in 3.4.3 says nothing about __new__ vs. __init__. It says the metaclass will be "called" for class creation, and it says the metaclass can be any "callable". This would imply the use of __call__ rather than __new__ or __init__. I think 3.4.1 should say: __new__() is intended mainly to allow subclasses of immutable types (like int, str, or tuple) to customize instance creation. It is also used for custom metaclasses (q.v.). I think 3.4.3 should be reviewed in its entirety to replace the misleading language about "called" and "callable" with language that explicitly mentions __new__. ---------- title: no effect if metaclass modifies dict -> documentation on metaclasses is incomplete and misleading __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 19:06:30 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 04 Jan 2008 18:06:30 -0000 Subject: [issue846388] Check for signals during regular expression matches Message-ID: <1199469990.88.0.228553002192.issue846388@psf.upfronthosting.co.za> Facundo Batista added the comment: Couldn't apply cleanly the patch, as it appears to be a diff in other format. Anyway, applied it by hand, and now I attach the correct svn diff. The test cases run ok with this change, and the problem is solved. Regarding the delay introduced, I tested it with: $ ./python timeit.py -s "import re;r=re.compile('a?a?a?a?a?aaaaa')" "r.match('aaaaa')" Trunk: 100000 loops, best of 3: 5.4 usec per loop 100000 loops, best of 3: 5.32 usec per loop 100000 loops, best of 3: 5.41 usec per loop Patch applied: 100000 loops, best of 3: 7.28 usec per loop 100000 loops, best of 3: 6.79 usec per loop 100000 loops, best of 3: 7.00 usec per loop I don't like that. Anyway, I do NOT trust for timing the system where I'm making the timing, so you may get different results. Suggestions? ---------- nosy: +facundobatista type: rfe -> versions: +Python 2.4 -Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9064/sre_exception.diff ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 19:48:22 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 04 Jan 2008 18:48:22 -0000 Subject: [issue846388] Check for signals during regular expression matches Message-ID: <1199472502.25.0.997529625316.issue846388@psf.upfronthosting.co.za> Ralf Schmitt added the comment: ./python Lib/timeit.py -n 1000000 -s "import re;r=re.compile('a?a?a?a?a?aaaaa')" "r.match('aaaaa')" gives me for Trunk: 1000000 loops, best of 3: 3.02 usec per loop 1000000 loops, best of 3: 2.99 usec per loop 1000000 loops, best of 3: 3.01 usec per loop Patched: 1000000 loops, best of 3: 3.04 usec per loop 1000000 loops, best of 3: 3.04 usec per loop 1000000 loops, best of 3: 3.14 usec per loop which would be ok, I guess. (This is on a 64bit debian testing with gcc 4.2.3). Can you test with the following: if ((0 == (sigcount & 0xffffffff)) && PyErr_CheckSignals()) (i.e. the code will (nearly) not even call PyErr_CheckSignals). I guess this is some c compiler optimization issue (seems like mine does a better job at optimizing :) ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 20:10:53 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 19:10:53 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1199473853.93.0.0816080575165.issue1243@psf.upfronthosting.co.za> Guido van Rossum added the comment: Then let's leave well enough alone. I believe Greg Ward doesn't usually respond to queries about optparse, but I'm assigning it to him anyway in case his interest is piqued. But for now, let's close this. ---------- assignee: -> gward nosy: +gward resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 20:14:03 2008 From: report at bugs.python.org (Paul Felix) Date: Fri, 04 Jan 2008 19:14:03 -0000 Subject: [issue770280] PyMarshal_ReadLastObjectFromFile Message-ID: <1199474043.87.0.643296096614.issue770280@psf.upfronthosting.co.za> Paul Felix added the comment: Maybe not. With the addition of thread.stack_size([size]), it's fairly easy to get around the problem by bumping up the stack size. It would be nice if PyMarshal_ReadLastObjectFromFile didn't allocate a small file buffer on the stack (think of the impact when *recursively* importing many .pyc files). ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 20:40:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 19:40:56 -0000 Subject: [issue482531] python directory not added to PATH Message-ID: <1199475656.34.0.977752354624.issue482531@psf.upfronthosting.co.za> Christian Heimes added the comment: This bug is about 6 years old. Please discuss the matter on the python dev mailing list if you are still interested in the problem. ---------- nosy: +tiran resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 20:41:55 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 19:41:55 -0000 Subject: [issue490264] Portable compiler option specification Message-ID: <1199475715.22.0.964149705998.issue490264@psf.upfronthosting.co.za> Christian Heimes added the comment: This bug is about 6 years old. Please discuss the matter on the python dev mailing list if you are still interested in the problem and come up with a patch. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 20:47:06 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 19:47:06 -0000 Subject: [issue734115] Packaging without disturbing an existing installation Message-ID: <1199476026.19.0.244728166315.issue734115@psf.upfronthosting.co.za> Christian Heimes added the comment: This patch should be considered for Python 2.6 and newer. ---------- keywords: +patch nosy: +tiran priority: normal -> low versions: +Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 20:48:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 19:48:39 -0000 Subject: [issue699594] refcount problem involving debugger Message-ID: <1199476119.9.0.117628832051.issue699594@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug report is about 5 years old and probably outdated. Please open a new one if you see the bug again. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 20:51:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 19:51:19 -0000 Subject: [issue706392] faster _socket.connect variant desired Message-ID: <1199476279.17.0.429558465758.issue706392@psf.upfronthosting.co.za> Christian Heimes added the comment: Consider and discuss the patch for Python 2.6 or close it. ---------- keywords: +patch nosy: +tiran priority: normal -> low versions: +Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 20:54:42 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 19:54:42 -0000 Subject: [issue1009929] PyErr_Clear() vs. AsynchronousException Message-ID: <1199476482.82.0.787400707499.issue1009929@psf.upfronthosting.co.za> Christian Heimes added the comment: The problem was solved with the new BaseException class ---------- nosy: +tiran resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 4 20:56:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 19:56:29 -0000 Subject: [issue990749] os constants missing Message-ID: <1199476589.28.0.741817464986.issue990749@psf.upfronthosting.co.za> Christian Heimes added the comment: The docs claim are wrong. ---------- nosy: +tiran resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 20:57:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 19:57:21 -0000 Subject: [issue812369] module shutdown procedure based on GC Message-ID: <1199476640.94.0.579665849025.issue812369@psf.upfronthosting.co.za> Christian Heimes added the comment: Consider this patch for 2.6 and discuss it at the bug day. ---------- nosy: +tiran versions: +Python 2.6, Python 3.0 -Python 2.4 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 21:00:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 20:00:29 -0000 Subject: [issue842171] Digital Unix build fails to create ccpython.o Message-ID: <1199476829.87.0.324837141922.issue842171@psf.upfronthosting.co.za> Christian Heimes added the comment: Digital Unix is no longer officially supported. If somebody needs Python on the system please open a new bug and provide some patches. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 21:02:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 20:02:31 -0000 Subject: [issue813922] Zero Configuration Networking? Message-ID: <1199476951.13.0.826378948467.issue813922@psf.upfronthosting.co.za> Christian Heimes added the comment: I agree with Jack! Please work on an extension package and provide patches if you need extra socket code in the core. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 21:04:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 20:04:05 -0000 Subject: [issue759525] inspect.getmembers broken (?) Message-ID: <1199477045.59.0.141734009368.issue759525@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Documentation versions: +Python 2.5, Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 21:06:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 20:06:39 -0000 Subject: [issue618593] Windows binary missing IPv6 support Message-ID: <1199477199.48.0.15070576104.issue618593@psf.upfronthosting.co.za> Christian Heimes added the comment: Python 2.5 and newer support IPv6 on Windows. ---------- nosy: +tiran resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 21:07:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2008 20:07:58 -0000 Subject: [issue452144] How to install some stuff to /usr/sbin Message-ID: <1199477278.67.0.14202022177.issue452144@psf.upfronthosting.co.za> Christian Heimes added the comment: The feature request is several years old. Please create a new request with a working patch if you still want to get the feature into Python 2.6+ ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 4 22:30:31 2008 From: report at bugs.python.org (Oliver Nelson) Date: Fri, 04 Jan 2008 21:30:31 -0000 Subject: [issue1738] filecmp.dircmp does exact match only Message-ID: <1199482231.61.0.263318145026.issue1738@psf.upfronthosting.co.za> Changes by Oliver Nelson: ---------- components: None nosy: flxkid severity: normal status: open title: filecmp.dircmp does exact match only type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 22:34:05 2008 From: report at bugs.python.org (Oliver Nelson) Date: Fri, 04 Jan 2008 21:34:05 -0000 Subject: [issue1738] filecmp.dircmp does exact match only Message-ID: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za> New submission from Oliver Nelson: dircmp's ignore and hide list only take exact files to ignore, not unix filename pattern's. This means you can't hide/ignore *.bak or something similar. Changing the _filter function adds this: def newfilter(flist, skip): for pattern in skip: flist = list(ifilterfalse(fnmatch.filter(flist, pattern).__contains__, flist)) return flist __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 23:28:52 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 04 Jan 2008 22:28:52 -0000 Subject: [issue1737] Windows installer issue (ObjectBrowser.py) Message-ID: <1199485732.74.0.675025382892.issue1737@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please run msiexec /i /l*v python.log then compress python.log, and attach it to the report? Thanks. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 4 23:31:04 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Fri, 04 Jan 2008 22:31:04 -0000 Subject: [issue1472] Small bat files to build docs on Windows Message-ID: <1199485864.49.0.490428962344.issue1472@psf.upfronthosting.co.za> Joseph Armbruster added the comment: I tested this out out in the trunk (59706). Placed builddoc.bat in /Doc and ran the following commands: builddoc checkout builddoc html builddoc htmlhelp builddoc web All appeared to work fine on my system. ---------- nosy: +JosephArmbruster __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 00:06:00 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 23:06:00 -0000 Subject: [issue1738] filecmp.dircmp does exact match only Message-ID: <1199487960.76.0.699135281958.issue1738@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm sorry, but can you rephrase that in the form of a patch? I can't quite figure out what you're trying to say, except that it sounds like it's scratching an itch of yours. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 00:10:38 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 23:10:38 -0000 Subject: [issue1656] Make math.{floor,ceil}(float) return ints per PEP 3141 Message-ID: <1199488238.57.0.255881377665.issue1656@psf.upfronthosting.co.za> Guido van Rossum added the comment: looks good. ---------- assignee: gvanrossum -> jyasskin resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 00:11:28 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2008 23:11:28 -0000 Subject: [issue846388] Check for signals during regular expression matches Message-ID: <1199488288.54.0.67921320941.issue846388@psf.upfronthosting.co.za> Guido van Rossum added the comment: Mind if I assign this to Facundo? Facundo, if you wish to pass this on, just unassign it. ---------- assignee: effbot -> facundobatista nosy: +gvanrossum ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 01:25:28 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 05 Jan 2008 00:25:28 -0000 Subject: [issue1381] cmath is numerically unsound Message-ID: <1199492728.84.0.0929366090463.issue1381@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's an updated patch for cmath, complete with tests and documentation changes. There's an extra file, Lib/test/cmath.ctest, containing test values for the various functions; these test values were obtained using MPFR and interval arithmetic, and (modulo bugs) should all be correctly rounded. Any feedback would be much appreciated. Added file: http://bugs.python.org/file9065/cmath3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 01:30:54 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sat, 05 Jan 2008 00:30:54 -0000 Subject: [issue467924] Improve the ZipFile Interface Message-ID: <1199493054.17.0.244195713534.issue467924@psf.upfronthosting.co.za> Alan McIntyre added the comment: I attached a patch with the following changes (as zipfile_extract.diff): (1) Add a note to the docs (under writestr) about how the compression is selected if a ZipInfo is passed as the zinfo_or_arcname parameter. If anybody thinks it's a good idea to add a compression argument to the ZipInfo constructor, I can modify the patch/docs accordingly. (2) Add an extract method to ZipFile and associated test/documentation changes. Added file: http://bugs.python.org/file9066/zipfile_extract.diff ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 01:33:43 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 00:33:43 -0000 Subject: [issue1722225] Build on QNX 6 Message-ID: <1199493223.94.0.321625809263.issue1722225@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think it's fine to accept this (once the remaining issues are resolved) -- it's a remarkably small patch. Regarding TCGETA, perhaps the issue is that it isn't defined unless is included? While Python doesn't USE it, it exports it fro the termios module, if it exists. Though the suggestion that this should be resolved by configure is still a good one. Matt, can you provide an updated patch or clarifications? ---------- nosy: +gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 01:36:57 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sat, 05 Jan 2008 00:36:57 -0000 Subject: [issue683910] zipfile should have a tarfile-like API Message-ID: <1199493417.33.0.899691591111.issue683910@psf.upfronthosting.co.za> Alan McIntyre added the comment: I just posted a patch on issue 467924 (http://bugs.python.org/issue467924) that adds extract and extractall methods. Recommend closing this issue unless the patch over there is insufficient for some reason. ---------- nosy: +alanmcintyre ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 01:39:26 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sat, 05 Jan 2008 00:39:26 -0000 Subject: [issue467924] Improve the ZipFile Interface Message-ID: <1199493566.54.0.984703048333.issue467924@psf.upfronthosting.co.za> Alan McIntyre added the comment: Are the method renames/additions suggested in the original issue worth doing? When I first started using this module, I found the documentation easy and thorough enough to understand how to use it, so I would vote for just leaving the ZipFile interface the way it is. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 02:02:03 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 01:02:03 -0000 Subject: [issue1725] -1e-1000 converted incorrectly Message-ID: <1199494923.13.0.960296855618.issue1725@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 59725. Thanks for the fix, Mark! This issue is a great example of how our development process works well. I propose not to backport this to 2.5.2, it's a rather minor issue and who knows what user code might depend on the existing buggy behavior... ---------- keywords: +patch priority: -> normal resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 02:02:38 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 01:02:38 -0000 Subject: [issue1725] -1e-1000 converted incorrectly Message-ID: <1199494958.53.0.187436584666.issue1725@psf.upfronthosting.co.za> Guido van Rossum added the comment: PS. I reformatted some long lines in the patch. In general, I like to keep all lines < 80 chars, in both C and Python code. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 02:23:01 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 01:23:01 -0000 Subject: [issue1698] urlparse and usernames containing @ Message-ID: <1199496181.9.0.19700443362.issue1698@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 59726. This is in the trunk (2.6). Do you need this backported to 2.5.2 as well? ---------- keywords: +patch status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 03:22:00 2008 From: report at bugs.python.org (Oliver Nelson) Date: Sat, 05 Jan 2008 02:22:00 -0000 Subject: [issue1738] filecmp.dircmp does exact match only Message-ID: <1199499720.42.0.537566504299.issue1738@psf.upfronthosting.co.za> Oliver Nelson added the comment: Patch attached (sorry, this is my first bug report on an os project). dircmp has a list of files to ignore and hide. These lists right now are compared to the left and right lists using __contains__ to filter out the ignore/hide lists. This patch adds the ability to pass file patterns in addition to filenames so that you can filter classes of files such as *.bak or temp*.* Added file: http://bugs.python.org/file9067/filecmp.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 03:28:58 2008 From: report at bugs.python.org (Oliver Nelson) Date: Sat, 05 Jan 2008 02:28:58 -0000 Subject: [issue1738] filecmp.dircmp does exact match only Message-ID: <1199500138.86.0.773608406692.issue1738@psf.upfronthosting.co.za> Oliver Nelson added the comment: sorry...jacked up the patch file...new one attached Added file: http://bugs.python.org/file9068/filecmp.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 04:37:38 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sat, 05 Jan 2008 03:37:38 -0000 Subject: [issue1692] Syntax Error exception dosen't print string; not informative Message-ID: <1199504258.28.0.583286956116.issue1692@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: This short patch appears to fix the problem, please review. ---------- keywords: +patch Added file: http://bugs.python.org/file9069/pythonrun.c.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 05:05:36 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 04:05:36 -0000 Subject: [issue1692] Syntax Error exception dosen't print string; not informative Message-ID: <1199505936.73.0.425185528496.issue1692@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yup, thanks! Can you submit it and close this? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 05:33:22 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sat, 05 Jan 2008 04:33:22 -0000 Subject: [issue1692] Syntax Error exception dosen't print string; not informative Message-ID: <1199507601.99.0.226581566566.issue1692@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r59729 ---------- assignee: gvanrossum -> kbk resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 07:51:55 2008 From: report at bugs.python.org (Mike Klaas) Date: Sat, 05 Jan 2008 06:51:55 -0000 Subject: [issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi Message-ID: <1199515915.2.0.270940883222.issue1663329@psf.upfronthosting.co.za> Mike Klaas added the comment: Updated patch, now with documentation and test. Patch is against 2.6trunk, but probably will apply against 3.0 as well ---------- components: +Library (Lib) -Interpreter Core versions: +Python 2.6 -Python 2.5 Added file: http://bugs.python.org/file9070/posix_closerange.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 11:41:41 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sat, 05 Jan 2008 10:41:41 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files Message-ID: <1199529701.73.0.921935432784.issue1526@psf.upfronthosting.co.za> Alan McIntyre added the comment: The reported warning was being produced when writing the "end of central directory record", in ZipFile.close(). Based on a little experiment with 70k test text files, the default archiver in OS X appears to just use the number of files mod 64k in the end of central directory record. I tweaked the ZipFile close() method to do this, and the resulting ZIP file appears to work just fine, both with the OS X archiver and with ZipFile (without ZIP64 enabled). There's a blurb in the ZIP format description about this sort of thing: "If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field." I don't know if that means "the right thing" is to switch the archive to ZIP64 format if more than 64k files are added, though. If I have time I'll go look at some other open source ZIP implementations, but I won't swear I'll ever get around to it. :) ---------- nosy: +alanmcintyre __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:20:54 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 05 Jan 2008 11:20:54 -0000 Subject: [issue1739] Testing CIA.vc Message-ID: <1199532054.55.0.0263033629621.issue1739@psf.upfronthosting.co.za> New submission from Martin v. L?wis: Will this text show up in CIA? ---------- messages: 59284 nosy: loewis severity: normal status: open title: Testing CIA.vc __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:23:16 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 05 Jan 2008 11:23:16 -0000 Subject: [issue1739] Testing CIA.vc Message-ID: <1199532196.53.0.36273563449.issue1739@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is a followup, it should get truncated in CIA provided I manage to type enough text so that it exceeds the 150 character limit. As the first sentence had only 130 characters, I needed to add a second one. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:26:13 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 05 Jan 2008 11:26:13 -0000 Subject: [issue1739] Testing CIA.vc Message-ID: <1199532373.01.0.692302361559.issue1739@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Second try: This is a followup, it should get truncated in CIA provided I manage to type enough text so that it exceeds the 150 character limit. As the first sentence had only 130 characters, I needed to add a second one. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:26:41 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 05 Jan 2008 11:26:41 -0000 Subject: [issue1739] Testing CIA.vc Message-ID: <1199532401.06.0.680913623427.issue1739@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- resolution: -> invalid __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:27:06 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 05 Jan 2008 11:27:06 -0000 Subject: [issue1739] Testing CIA.vc Message-ID: <1199532426.42.0.71691681118.issue1739@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Test complete. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:32:43 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 11:32:43 -0000 Subject: [issue1489] test_socket_ssl hanhs on Windows (deadlock) Message-ID: <1199532763.01.0.270964443677.issue1489@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:32:54 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 11:32:54 -0000 Subject: [issue1223] httplib does not handle ssl end of file properly Message-ID: <1199532774.57.0.090375523124.issue1223@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:33:04 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 11:33:04 -0000 Subject: [issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate Message-ID: <1199532784.7.0.750406252997.issue1589@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:46:56 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 11:46:56 -0000 Subject: [issue1637] urlparse.urlparse misparses URLs with query but no path Message-ID: <1199533616.49.0.831031566213.issue1637@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:49:29 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 11:49:29 -0000 Subject: [issue1482] IMAP4 SSL isn't working Message-ID: <1199533769.49.0.539444992574.issue1482@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 12:56:20 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 11:56:20 -0000 Subject: [issue1462525] URI parsing library Message-ID: <1199534180.86.0.899441779591.issue1462525@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 14:05:37 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 13:05:37 -0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1199538337.21.0.234074926251.issue1424152@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 14:07:03 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 13:07:03 -0000 Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir Message-ID: <1199538423.04.0.656905556798.issue1755841@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 14:07:33 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 13:07:33 -0000 Subject: [issue735515] urllib / urllib2 should cache 301 redirections Message-ID: <1199538453.57.0.709710483243.issue735515@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 14:16:20 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 13:16:20 -0000 Subject: [issue1441530] socket read() can cause MemoryError in Windows Message-ID: <1199538980.47.0.714295380032.issue1441530@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 14:20:04 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 13:20:04 -0000 Subject: [issue920573] http libraries throw errors internally Message-ID: <1199539204.21.0.530775884212.issue920573@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 14:58:51 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 13:58:51 -0000 Subject: [issue900744] catch invalid chunk length in httplib read routine Message-ID: <1199541531.27.0.416070282588.issue900744@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 15:00:39 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 14:00:39 -0000 Subject: [issue1486335] httplib: read/_read_chunked failes with ValueError sometime Message-ID: <1199541639.78.0.833732533557.issue1486335@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 15:03:10 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 14:03:10 -0000 Subject: [issue1411097] httplib patch to make _read_chunked() more robust Message-ID: <1199541790.56.0.190110617742.issue1411097@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 15:08:49 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 14:08:49 -0000 Subject: [issue1019808] wrong socket error returned Message-ID: <1199542129.95.0.203216566649.issue1019808@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 15:09:27 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 14:09:27 -0000 Subject: [issue1229646] httplib error checking. Message-ID: <1199542167.68.0.0591292345979.issue1229646@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 15:09:50 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 14:09:50 -0000 Subject: [issue1448934] urllib2+https+proxy not working Message-ID: <1199542190.31.0.796972617729.issue1448934@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 15:10:45 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 14:10:45 -0000 Subject: [issue1178141] urllib.py overwrite HTTPError code with 200 Message-ID: <1199542245.52.0.661044599078.issue1178141@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 15:11:19 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 14:11:19 -0000 Subject: [issue970288] Fix for #876637 - Random stack corruption from socketmodule Message-ID: <1199542279.07.0.849378896379.issue970288@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 15:15:43 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 14:15:43 -0000 Subject: [issue976613] socket timeout problems on Solaris Message-ID: <1199542543.0.0.0512049880922.issue976613@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 16:03:50 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 15:03:50 -0000 Subject: [issue706392] faster _socket.connect variant desired Message-ID: <1199545430.73.0.783428753241.issue706392@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 16:06:27 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 15:06:27 -0000 Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100 Message-ID: <1199545587.55.0.00631461990006.issue1491@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 16:07:12 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 15:07:12 -0000 Subject: [issue1492] BaseHTTPServer hard-codes Content-Type for error messages Message-ID: <1199545632.44.0.984281302447.issue1492@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 16:07:56 2008 From: report at bugs.python.org (vila) Date: Sat, 05 Jan 2008 15:07:56 -0000 Subject: [issue1062] nice to have a way to tell if a socket is bound Message-ID: <1199545676.21.0.147578164074.issue1062@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 17:18:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 16:18:44 -0000 Subject: [issue616247] More documentation for the imp module Message-ID: <1199549924.01.0.444094876564.issue616247@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low versions: +Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 17:30:46 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sat, 05 Jan 2008 16:30:46 -0000 Subject: [issue1393] function comparing lacks NotImplemented error Message-ID: <1199550646.45.0.611826808732.issue1393@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: I'd like to ping this issue as I think it is important enough (core is affected). __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 17:51:10 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 16:51:10 -0000 Subject: [issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi Message-ID: <1199551870.65.0.257570825431.issue1663329@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll review this when I have time. Thanks! If you want speedier response, please find someone else among the core developers; or perhaps the bug day on Jan 19 will help. ---------- assignee: -> gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 18:45:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 17:45:13 -0000 Subject: [issue452973] Tcl event loop callback woes Message-ID: <1199555113.24.0.856625654666.issue452973@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug report is several years old and probably outdated. Please create a new issue if you are still interested in the problem. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 18:56:40 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 17:56:40 -0000 Subject: [issue577295] Print line number of string if at EOF Message-ID: <1199555800.56.0.172568390545.issue577295@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug report is several years old and nobody was interested in adding this minor feature in about 5 years. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 18:59:06 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 17:59:06 -0000 Subject: [issue750423] event handling support Message-ID: <1199555946.23.0.618722897331.issue750423@psf.upfronthosting.co.za> Christian Heimes added the comment: The topic must be discussed on python-de and planed with PEP as already explained by Jeff. ---------- nosy: +tiran resolution: -> invalid status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:00:25 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:00:25 -0000 Subject: [issue691291] codecs.open(filename, 'U', 'UTF-16') corrupts text Message-ID: <1199556025.59.0.0397777480977.issue691291@psf.upfronthosting.co.za> Christian Heimes added the comment: Checks this for 2.6 ---------- components: +Library (Lib) -None nosy: +tiran versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:01:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:01:05 -0000 Subject: [issue648658] xmlrpc can't do proxied HTTP Message-ID: <1199556065.74.0.70371292959.issue648658@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:02:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:02:19 -0000 Subject: [issue828450] sdist generates bad MANIFEST on Windows Message-ID: <1199556139.12.0.19177548452.issue828450@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Windows versions: +Python 2.5, Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:03:12 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:03:12 -0000 Subject: [issue793069] Add --remove-source option Message-ID: <1199556192.92.0.999309518407.issue793069@psf.upfronthosting.co.za> Christian Heimes added the comment: Should the feature be added in 2.6? I'm -0 on it. ---------- keywords: +patch nosy: +tiran versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:05:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:05:19 -0000 Subject: [issue787113] zipimport on meta_path fails with mutual importers Message-ID: <1199556319.05.0.619759619046.issue787113@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Documentation, Library (Lib) -None versions: +Python 2.5, Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:06:33 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:06:33 -0000 Subject: [issue883969] distutils doesn't see user-directories set via VisStudio 7.1 Message-ID: <1199556393.38.0.537997729113.issue883969@psf.upfronthosting.co.za> Christian Heimes added the comment: Python uses VS 2008 now ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:08:24 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:08:24 -0000 Subject: [issue626452] Support RFC 2111 in email package Message-ID: <1199556504.4.0.46404545339.issue626452@psf.upfronthosting.co.za> Christian Heimes added the comment: Does the email sig group still work on the topic? ---------- nosy: +tiran versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:09:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:09:32 -0000 Subject: [issue694339] Dedenting with Shift+Tab Message-ID: <1199556572.04.0.822154984821.issue694339@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:10:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:10:10 -0000 Subject: [issue900949] plat-mac/videoreader.py not working on OS X Message-ID: <1199556610.21.0.140008722744.issue900949@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:11:43 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:11:43 -0000 Subject: [issue617979] need easy way of decoding a literal Message-ID: <1199556703.67.0.752725406432.issue617979@psf.upfronthosting.co.za> Christian Heimes added the comment: Closed as requested by the OP four years ago. ---------- nosy: +tiran resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:12:50 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:12:50 -0000 Subject: [issue602245] os.popen() negative error code IOError Message-ID: <1199556770.79.0.429394045646.issue602245@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:16:37 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:16:37 -0000 Subject: [issue481171] Hang using files named prn.txt, etc Message-ID: <1199556996.99.0.376984549711.issue481171@psf.upfronthosting.co.za> Christian Heimes added the comment: Let's discuss it for 2.6 ---------- components: +Interpreter Core, Windows -None nosy: +tiran versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:18:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:18:59 -0000 Subject: [issue963845] There ought to be a way to uninstall Message-ID: <1199557139.75.0.107076417522.issue963845@psf.upfronthosting.co.za> Christian Heimes added the comment: Maintainers of RPM, deb or ports have already a way to detect files. distutils doesn't aim to be a full package manager. It's a tool to make the installation of Python software easier. Please work the the distutils team and create an uninstaller if you *really* want an uninstall feature. ---------- nosy: +tiran resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:20:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:20:31 -0000 Subject: [issue960325] "require " configure option Message-ID: <1199557231.73.0.303807586256.issue960325@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Build -None priority: normal -> low versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:21:23 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:21:23 -0000 Subject: [issue979658] Improve HTML documentation of a directory Message-ID: <1199557283.51.0.901751198492.issue979658@psf.upfronthosting.co.za> Christian Heimes added the comment: What do you think about the feature, Georg? ---------- assignee: ping -> georg.brandl nosy: +georg.brandl, tiran type: -> rfe versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:25:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:25:02 -0000 Subject: [issue1052098] Seting defaultencoding through an environment variable Message-ID: <1199557502.14.0.608467217724.issue1052098@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 19:27:22 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:27:22 -0000 Subject: [issue1018492] Solaris: reentrancy issues Message-ID: <1199557642.14.0.31231765535.issue1018492@psf.upfronthosting.co.za> Christian Heimes added the comment: Check this for 2.6 or close it. ---------- nosy: +tiran versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 19:27:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:27:39 -0000 Subject: [issue1053369] ftplib: add support for MDTM command Message-ID: <1199557659.49.0.641040597867.issue1053369@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 19:31:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:31:08 -0000 Subject: [issue985094] getattr(object,name) accepts only strings Message-ID: <1199557868.32.0.78578379277.issue985094@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 19:31:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 18:31:51 -0000 Subject: [issue964949] Ctrl-C causes odd behaviour Message-ID: <1199557911.9.0.725561490964.issue964949@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> duplicate status: open -> closed superseder: -> Ctrl-C will exit out of Python interpreter in Windows ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 20:05:25 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 05 Jan 2008 19:05:25 -0000 Subject: [issue1734] documentation on metaclasses is incomplete and misleading Message-ID: <1199559925.03.0.692846574934.issue1734@psf.upfronthosting.co.za> Georg Brandl added the comment: I'll look into it. ---------- nosy: +georg.brandl resolution: invalid -> status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 20:05:32 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 05 Jan 2008 19:05:32 -0000 Subject: [issue1734] documentation on metaclasses is incomplete and misleading Message-ID: <1199559932.76.0.492911100942.issue1734@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 20:12:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:12:58 -0000 Subject: [issue1092962] Make Generators Pickle-able Message-ID: <1199560378.06.0.861868788024.issue1092962@psf.upfronthosting.co.za> Christian Heimes added the comment: Discuss this for 2.6 I thin it's neither possible to find a generic solution nor a good idea to make generators picklable. ---------- nosy: +tiran versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:13:30 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:13:30 -0000 Subject: [issue1104021] wishlist: os.feed_urandom(input) Message-ID: <1199560410.81.0.381694796033.issue1104021@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:13:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:13:51 -0000 Subject: [issue1109658] distutils dry-run breaks when attempting to bytecompile Message-ID: <1199560431.73.0.704270829439.issue1109658@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:17:00 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:17:00 -0000 Subject: [issue1166378] No os.spawn*p* on Windows Message-ID: <1199560620.72.0.565126389262.issue1166378@psf.upfronthosting.co.za> Christian Heimes added the comment: The subprocess is the successor of the various exec, popen and spawn functions. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:17:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:17:39 -0000 Subject: [issue1173134] improvement of the script adaptation for the win32 platform Message-ID: <1199560659.24.0.333264872844.issue1173134@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:17:47 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 Jan 2008 19:17:47 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199560667.4.0.257352581626.issue932563@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This could probably be solved with an optional argument to getLogger() and a weakref. Do you want me to write a patch? ---------- nosy: +pitrou ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 20:21:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:21:13 -0000 Subject: [issue1203650] Allow larger programs to be frozen under Win32 Message-ID: <1199560873.63.0.640125961105.issue1203650@psf.upfronthosting.co.za> Christian Heimes added the comment: The command line argument size is limited on Windows. One has to use a file instead of an argument list if the list exceeds a limit. IIRC the limit is rather low (< 1024 or even < 512). ---------- components: +Windows nosy: +tiran priority: normal -> low type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:22:14 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:22:14 -0000 Subject: [issue1222585] C++ compilation support for distutils Message-ID: <1199560934.9.0.268385938581.issue1222585@psf.upfronthosting.co.za> Christian Heimes added the comment: Isn't it already fixed? Need to check it at the upcoming bug day. ---------- nosy: +tiran versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:24:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:24:19 -0000 Subject: [issue1145231] No os.statvfs on FreeBSD Message-ID: <1199561059.59.0.684074436315.issue1145231@psf.upfronthosting.co.za> Christian Heimes added the comment: My FreeBSD 6.2 machine has os.statvfs. ---------- nosy: +tiran resolution: -> works for me status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:29:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:29:05 -0000 Subject: [issue487738] weaklist Message-ID: <1199561345.6.0.985277564312.issue487738@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 20:29:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 05 Jan 2008 19:29:53 -0000 Subject: [issue1712] Small errors in new-style classes doc Message-ID: <1199561393.51.0.0984976085412.issue1712@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r59743. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 20:31:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:31:26 -0000 Subject: [issue1276768] dirutils.mkpath (verbose option does not work) Message-ID: <1199561486.07.0.937867440584.issue1276768@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:31:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:31:51 -0000 Subject: [issue1251748] compiler package: "global a; a=5" Message-ID: <1199561511.85.0.157234842012.issue1251748@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:32:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:32:15 -0000 Subject: [issue1288056] pygettext - provide comments to help translators Message-ID: <1199561535.93.0.266301581407.issue1288056@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:32:38 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:32:38 -0000 Subject: [issue1260171] subprocess: more general (non-buffering) communication Message-ID: <1199561558.95.0.964487589208.issue1260171@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:33:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:33:56 -0000 Subject: [issue1294959] Problems with /usr/lib64 builds. Message-ID: <1199561636.01.0.252845523377.issue1294959@psf.upfronthosting.co.za> Christian Heimes added the comment: The problem with 64 bit builds should be discussed before we release 2.6. Another bug day topic. ---------- components: +Build -None keywords: +patch nosy: +tiran versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:33:58 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 05 Jan 2008 19:33:58 -0000 Subject: [issue1572210] help(x) for keywords too Message-ID: <1199561638.44.0.738803575897.issue1572210@psf.upfronthosting.co.za> Georg Brandl added the comment: 1600491 was applied, so I'm closing this. ---------- resolution: -> works for me status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:35:31 2008 From: report at bugs.python.org (L. Peter Deutsch) Date: Sat, 05 Jan 2008 19:35:31 -0000 Subject: [issue1734] documentation on metaclasses is incomplete and misleading Message-ID: <1199561731.42.0.735388236358.issue1734@psf.upfronthosting.co.za> L. Peter Deutsch added the comment: Actually, "called" and "callable" are OK, if the documentation says somewhere that the normal effect of "calling" a type object is to invoke __new__. The places I looked first (sections 3.1, 3.3, and 3.4.1) do not say this. 5.3.4 does say that the result of calling a class object is a new instance of that class, but it doesn't mention __new__. So perhaps it would OK to just add something like the following to 3.4.3: Note that if a metaclass is a subclass of type, it should override __new__, not __call__. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 20:36:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:36:32 -0000 Subject: [issue1471243] Visual Studio 2005 CRT error handler Message-ID: <1199561792.87.0.613893433689.issue1471243@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> tiran components: +Windows nosy: +tiran versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:39:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:39:05 -0000 Subject: [issue1092502] Memory leak in socket.py on Mac OS X 10.3 Message-ID: <1199561945.02.0.803921545294.issue1092502@psf.upfronthosting.co.za> Christian Heimes added the comment: Probably outdated I haven't heard or seen any such problems in the past two years. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:39:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:39:44 -0000 Subject: [issue1351036] PythonD new file: python2.4/plat-ms-dos5/djstat.py Message-ID: <1199561984.18.0.545443172106.issue1351036@psf.upfronthosting.co.za> Christian Heimes added the comment: We don't support MS-DOS any more. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:40:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:40:32 -0000 Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib Message-ID: <1199562032.33.0.338048429672.issue1326113@psf.upfronthosting.co.za> Christian Heimes added the comment: Another bug day task ---------- nosy: +tiran versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:42:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:42:13 -0000 Subject: [issue628842] Deprecate PyNumber_Check Message-ID: <1199562133.58.0.335627399993.issue628842@psf.upfronthosting.co.za> Christian Heimes added the comment: Discuss the bug at the bug day. ---------- nosy: +tiran type: -> rfe versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 20:43:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:43:18 -0000 Subject: [issue919614] Python configured with --disable-unicode fails tests, more Message-ID: <1199562198.71.0.0740647524902.issue919614@psf.upfronthosting.co.za> Christian Heimes added the comment: The --disable-unicode option and related code should be removed from 3.0 and probably from 2.6, too. ---------- nosy: +tiran versions: +Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 20:44:35 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 05 Jan 2008 19:44:35 -0000 Subject: [issue1730] Documentation corrections for os module Message-ID: <1199562275.68.0.753288924285.issue1730@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, committed as r59744! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 20:46:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:46:03 -0000 Subject: [issue1533105] NetBSD build with --with-pydebug causes SIGSEGV Message-ID: <1199562363.48.0.942489109684.issue1533105@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:47:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:47:02 -0000 Subject: [issue1524938] PEP MemoryError with a lot of available memory gc not called Message-ID: <1199562422.85.0.892062043417.issue1524938@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> high versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:49:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:49:19 -0000 Subject: [issue1516068] Under OS X, compiling against local readline fails Message-ID: <1199562559.92.0.505787054464.issue1516068@psf.upfronthosting.co.za> Christian Heimes added the comment: probably outdated and already fixed. Please open a new bug if you still can't link against the system's libreadline ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:50:20 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:50:20 -0000 Subject: [issue1518617] Website updating part of PEP101/102 out of date Message-ID: <1199562620.2.0.516710256658.issue1518617@psf.upfronthosting.co.za> Christian Heimes added the comment: Could either of you update the PEP, please? ---------- assignee: anthonybaxter -> nosy: +georg.brandl, tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:52:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:52:18 -0000 Subject: [issue595601] file (& socket) I/O are not thread safe Message-ID: <1199562738.73.0.13407556174.issue595601@psf.upfronthosting.co.za> Christian Heimes added the comment: The race condition issue should get more attention. ---------- nosy: +tiran priority: normal -> high versions: +Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 20:53:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:53:04 -0000 Subject: [issue1428655] Use PyOS_snprintf for static buffers Message-ID: <1199562784.62.0.767878251603.issue1428655@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:53:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:53:41 -0000 Subject: [issue1353344] python.desktop Message-ID: <1199562821.01.0.993133932238.issue1353344@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:53:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:53:53 -0000 Subject: [issue1396825] subprocess: wait for a period of time Message-ID: <1199562833.19.0.651981484088.issue1396825@psf.upfronthosting.co.za> Changes by Christian Heimes: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:56:12 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:56:12 -0000 Subject: [issue1504947] There should be a Python build using Visual Studio 2005 Message-ID: <1199562972.77.0.843074214638.issue1504947@psf.upfronthosting.co.za> Christian Heimes added the comment: We are using VS 2008 now. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:57:01 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:57:01 -0000 Subject: [issue1087418] long int bitwise ops speedup (patch included) Message-ID: <1199563021.35.0.995561567827.issue1087418@psf.upfronthosting.co.za> Christian Heimes added the comment: It's probably useful for Python 3.0 since the old int type is gone. ---------- nosy: +tiran priority: low -> normal versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 20:58:38 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:58:38 -0000 Subject: [issue920573] http libraries throw errors internally Message-ID: <1199563118.48.0.659583723571.issue920573@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 20:59:04 2008 From: report at bugs.python.org (L. Peter Deutsch) Date: Sat, 05 Jan 2008 19:59:04 -0000 Subject: [issue1518] Fast globals/builtins access (patch) Message-ID: <1199563144.42.0.327205473901.issue1518@psf.upfronthosting.co.za> L. Peter Deutsch added the comment: The proposed approach to speeding up lookup of inherited methods is not quite sound, given that class attributes can be added and removed dynamically. Consider: class A: def f(x): ... class B(A): pass class C(B): pass If C caches a pointer to A.f, the wrong thing will happen if B.f is defined dynamically, even though C's pointer will still point to a valid and up-to-date entry for f in A's dict, and C's MRO will not have changed. I thought a sufficient fix would be for classes to increment not only their own 64-bit dict "version" but that of all classes in their MRO if an entry is ever added or removed in their dict. But even this is not sufficient. Consider: class A: def f(x): ... class B(A): pass class C(B): pass class D: pass class E(D,C): pass If D.f is defined dynamically, E's cached pointer to C.f will retrieve the wrong value. But C is not in D's MRO. I haven't encountered this issue before in a system with multiple base classes (my extensive experience is with classic Smalltalk, and PostScript), so I don't have an off-the-cuff solution. ---------- nosy: +lpd __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 20:59:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 19:59:41 -0000 Subject: [issue1339673] cross compile and mingw support Message-ID: <1199563181.03.0.18069745622.issue1339673@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> out of date status: open -> closed superseder: -> Cross compiling patches for MINGW _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:00:04 2008 From: report at bugs.python.org (L. Peter Deutsch) Date: Sat, 05 Jan 2008 20:00:04 -0000 Subject: [issue1518] Fast globals/builtins access (patch) Message-ID: <1199563204.39.0.975156790948.issue1518@psf.upfronthosting.co.za> L. Peter Deutsch added the comment: Sorry, I wrote "E's cached pointer to C.f", which of course should be "E's cached pointer to A.f". __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 21:02:48 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 05 Jan 2008 20:02:48 -0000 Subject: [issue1518617] PEP101/102 out of date Message-ID: <1199563368.07.0.856267519593.issue1518617@psf.upfronthosting.co.za> Georg Brandl added the comment: The PEPs don't know about SVN either. ---------- title: Website updating part of PEP101/102 out of date -> PEP101/102 out of date _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:05:30 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sat, 05 Jan 2008 20:05:30 -0000 Subject: [issue1656] Make math.{floor,ceil}(float) return ints per PEP 3141 Message-ID: <1199563530.46.0.141509795338.issue1656@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Submitted as r59747. ---------- keywords: +py3k status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 21:05:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:05:39 -0000 Subject: [issue1615158] POSIX capabilities support Message-ID: <1199563539.97.0.88373455374.issue1615158@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:06:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:06:57 -0000 Subject: [issue1020188] Use Py_CLEAR where necessary to avoid crashes Message-ID: <1199563617.41.0.262484086541.issue1020188@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:07:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:07:47 -0000 Subject: [issue436259] [Windows] exec*/spawn* problem with spaces in args Message-ID: <1199563667.97.0.525660337959.issue436259@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Windows versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 21:10:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:10:39 -0000 Subject: [issue1615275] tempile.TemporaryFile differences between linux and windows Message-ID: <1199563839.77.0.805254400955.issue1615275@psf.upfronthosting.co.za> Christian Heimes added the comment: The behavior should be documented ---------- components: +Documentation nosy: +tiran versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:11:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:11:47 -0000 Subject: [issue1506296] Add some dicts to datetime module Message-ID: <1199563907.94.0.717852070837.issue1506296@psf.upfronthosting.co.za> Christian Heimes added the comment: Yeah, use the calendar module. ---------- nosy: +tiran resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:12:05 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 05 Jan 2008 20:12:05 -0000 Subject: [issue920573] http libraries throw errors internally Message-ID: <1199563925.29.0.66155399749.issue920573@psf.upfronthosting.co.za> Facundo Batista added the comment: A lot of water passed through httplib.py. A lot of people made corrections from Python versions 2.2 and 2.3. Even me. I added timeout to it. And fixed recently (r58530) a problem that could generate the second exception. But how can check if this is solved? ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 21:12:42 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:12:42 -0000 Subject: [issue1676820] Add a PeriodicTimer to threading Message-ID: <1199563962.56.0.104679935599.issue1676820@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> rfe versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:13:24 2008 From: report at bugs.python.org (Zooko O'Whielacronx) Date: Sat, 05 Jan 2008 20:13:24 -0000 Subject: [issue1104021] wishlist: os.feed_urandom(input) Message-ID: <1199564004.68.0.340117445755.issue1104021@psf.upfronthosting.co.za> Zooko O'Whielacronx added the comment: No, I don't want to work on a patch for this at this time. In fact, my current strategy with regard to random bits doesn't require this functionality, in general. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:17:24 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:17:24 -0000 Subject: [issue1180193] broken pyc files Message-ID: <1199564244.66.0.186393848343.issue1180193@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:18:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:18:21 -0000 Subject: [issue1692592] Stripping debugging symbols from compiled C extensions Message-ID: <1199564301.21.0.907664831681.issue1692592@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:20:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:20:34 -0000 Subject: [issue1732212] repr of 'nan' floats not parseable Message-ID: <1199564434.28.0.930116355161.issue1732212@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:41:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:41:45 -0000 Subject: [issue1225584] crash in gcmodule.c on python reinitialization Message-ID: <1199565705.67.0.394375631925.issue1225584@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 21:46:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 05 Jan 2008 20:46:40 -0000 Subject: [issue1719] Cosmetic patch for doc/code mismatch (msilib.UuidCreate) Message-ID: <1199566000.44.0.435437470668.issue1719@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r59752, thanks! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 21:56:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 20:56:26 -0000 Subject: [issue751260] Thread in threading.py can only be started once Message-ID: <1199566586.12.0.130061185504.issue751260@psf.upfronthosting.co.za> Christian Heimes added the comment: Close it for real ---------- nosy: +tiran status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 22:13:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 21:13:57 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199567637.49.0.491309038893.issue602345@psf.upfronthosting.co.za> Christian Heimes added the comment: Should the read only option be considered for 2.6? ---------- nosy: +tiran versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 22:36:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 21:36:08 -0000 Subject: [issue1601] IDLE not working correctly on Windows (Py30a2/IDLE30a1) Message-ID: <1199568968.79.0.423376648648.issue1601@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 23:06:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 22:06:29 -0000 Subject: [issue1471243] Visual Studio 2005 CRT error handler Message-ID: <1199570789.41.0.199962388651.issue1471243@psf.upfronthosting.co.za> Changes by Christian Heimes: Added file: http://bugs.python.org/file9071/invparamhandler.c _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 23:06:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 22:06:39 -0000 Subject: [issue1471243] Visual Studio 2005 CRT error handler Message-ID: <1199570799.3.0.48340575643.issue1471243@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file1972/invparamfix.c _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 5 23:06:53 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 22:06:53 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199570813.41.0.108987853278.issue602345@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm okay with this feature, and the patch looks fine, except I don't like the names used. It's not really about "read-only-ness" of bytecode, it's about whether we write certain files. I'd suggest naming the envvar PYTHONDONTWRITEBYTECODE, the C flag variable Py_DontWriteByteCodeFlag, and the sys variable sys.dont_write_byte_code. With those changes I'm find with Georg checkin it in. ---------- assignee: skip.montanaro -> georg.brandl keywords: +patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 5 23:08:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 22:08:15 -0000 Subject: [issue1646] Make socket support TIPC. Message-ID: <1199570895.64.0.896649235785.issue1646@psf.upfronthosting.co.za> Christian Heimes added the comment: *PING* I'm still waiting for a new patch. Your feature patch has been accepted but I won't commit it without doc updates. ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 23:12:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Jan 2008 22:12:41 -0000 Subject: [issue1595] Probable extra semicolon in Py_LeaveRecursiveCall macro Message-ID: <1199571161.68.0.984223177567.issue1595@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 5 23:19:23 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 22:19:23 -0000 Subject: [issue1637] urlparse.urlparse misparses URLs with query but no path Message-ID: <1199571563.43.0.129869185672.issue1637@psf.upfronthosting.co.za> Guido van Rossum added the comment: I checked in your change and made up a test. Committed revision 59758. Thanks! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 00:20:21 2008 From: report at bugs.python.org (Noam Raphael) Date: Sat, 05 Jan 2008 23:20:21 -0000 Subject: [issue979658] Improve HTML documentation of a directory Message-ID: <1199575221.41.0.299297516891.issue979658@psf.upfronthosting.co.za> Noam Raphael added the comment: I just wanted to say that I'm not going to bother too much with this right now - Personally I will just use epydoc when I want to create an HTML documentation. Of course, you can still do whatever you like with the patch. Good luck, Noam ---------- nosy: +noam ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 00:35:14 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 23:35:14 -0000 Subject: [issue1637] urlparse.urlparse misparses URLs with query but no path Message-ID: <1199576114.07.0.388614749253.issue1637@psf.upfronthosting.co.za> Guido van Rossum added the comment: Backport to 2.5.2: Committed revision 59760. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 00:50:16 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 23:50:16 -0000 Subject: [issue595601] file (& socket) I/O are not thread safe Message-ID: <1199577015.99.0.510767077868.issue595601@psf.upfronthosting.co.za> Guido van Rossum added the comment: Given how long this has been sitting without action, it's ludicrous to keep it at "high" priority. I'm also taking it away from Jermy since his interest must be minimal by now. And I'm removing 3.0 since it has a completely different I/O implementation (with much more severe multi-threading issues, but nothing in common with the 2.x series). ---------- assignee: jhylton -> priority: high -> low versions: -Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 00:50:25 2008 From: report at bugs.python.org (Brett Cannon) Date: Sat, 05 Jan 2008 23:50:25 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199577025.62.0.821301504223.issue602345@psf.upfronthosting.co.za> Brett Cannon added the comment: For some reason I don't love the use of "dont", with the missing apostrophe. Just looks ugly to me. But I don't know if "donot" is that much better. And I don't think "PYTHONSKIPWRITINGBYTECODE" is much better. In other words, I wish there was a better option, but I don't think any of my suggestions are really better. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 00:53:30 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2008 23:53:30 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199577210.09.0.379746707256.issue602345@psf.upfronthosting.co.za> Guido van Rossum added the comment: "dont" is a pretty common contraction (see e.g. telnet.py). ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 01:05:09 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 06 Jan 2008 00:05:09 -0000 Subject: [issue1492] BaseHTTPServer hard-codes Content-Type for error messages Message-ID: <1199577909.39.0.0561410387842.issue1492@psf.upfronthosting.co.za> Guido van Rossum added the comment: Something for the bug day on Jan 19? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 01:05:34 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 06 Jan 2008 00:05:34 -0000 Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100 Message-ID: <1199577934.48.0.582085017506.issue1491@psf.upfronthosting.co.za> Guido van Rossum added the comment: Something for the bug day on Jan 19. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 01:07:06 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 06 Jan 2008 00:07:06 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files Message-ID: <1199578026.79.0.647563436458.issue1526@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sounds like a plan. Can you cook up a patch? Otherwise perhaps the Jan 19 bug day can look into this? ---------- priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 01:10:13 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 06 Jan 2008 00:10:13 -0000 Subject: [issue1393] function comparing lacks NotImplemented error Message-ID: <1199578213.42.0.310754511848.issue1393@psf.upfronthosting.co.za> Guido van Rossum added the comment: That solution (return NotImplemented instead of False) appears to work. Committed revision 59761. Thanks for bringing up this regression w.r.t. 2.5! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 02:16:01 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Sun, 06 Jan 2008 01:16:01 -0000 Subject: [issue1089358] need siginterrupt() on Linux - impossible to do timeouts Message-ID: <1199582161.86.0.970065773234.issue1089358@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I'm attaching an updated patch against trunk. It also contains some documentation now. Added file: http://bugs.python.org/file9072/siginterrupt _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 02:40:07 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2008 01:40:07 -0000 Subject: [issue1740] use unittest for test_logging Message-ID: <1199583606.98.0.490636410107.issue1740@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Lib/test.test_logging.py doesn't use unittest. Here is a patch (against SVN trunk) to fix the problem. ---------- components: Tests files: logtest.patch messages: 59348 nosy: pitrou severity: normal status: open title: use unittest for test_logging versions: Python 2.6 Added file: http://bugs.python.org/file9073/logtest.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 05:33:40 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 04:33:40 -0000 Subject: [issue1740] use unittest for test_logging Message-ID: <1199594020.46.0.599923806251.issue1740@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks! :) I quick review hasn't shown any larger issues but it need a proper review before it can be submitted. You probably should save _levelNames, _loggerClass, root, Logger.root and Logger.manager in setUp and reset the objects in tearDown. ---------- keywords: +patch nosy: +tiran priority: -> normal resolution: -> accepted type: -> resource usage __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 05:48:20 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2008 04:48:20 -0000 Subject: [issue1740] use unittest for test_logging Message-ID: <1199594900.23.0.571303138789.issue1740@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok here is an updated patch with slightly more complete setUp/tearDown semantics. I don't backup all the objects though since some of them (e.g. _loggerClass) aren't touched by the tests. Added file: http://bugs.python.org/file9074/logtest.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 11:03:29 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sun, 06 Jan 2008 10:03:29 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files Message-ID: <1199613809.39.0.318657469622.issue1526@psf.upfronthosting.co.za> Alan McIntyre added the comment: Here's a patch that just uses the "mod 64k" approach. If I get time to look at some other implementations, and find a better way to handle it, I'll submit an update. Otherwise, maybe on bug day people can try it out with a variety of archiving utilities to see if there's any compatibility issues. Added file: http://bugs.python.org/file9075/zipfile_lotsafiles.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 11:13:33 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 10:13:33 -0000 Subject: [issue1591] popen2.Popen3 class (Unix) documentation misleading / confusing Message-ID: <1199614413.57.0.988039487412.issue1591@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 11:39:18 2008 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 06 Jan 2008 10:39:18 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199615958.35.0.433089911873.issue932563@psf.upfronthosting.co.za> Vinay Sajip added the comment: There's probably no need. Fred's initial reason for wanting this (usage of connection-specific loggers, which would be an anti-pattern in my book) was later solved by him using an application-specific wrapper. Also, changes made to logging after this issue was created make it easier to include context information (e.g. connection IDs) in logging calls. So: I don't think it is good behaviour for any application to create a large (=> potentially unbounded) set of loggers. The number of loggers created should be dependent on the granularity of logging which the application developer wants to use. If this approach is followed, the number of loggers is unlikely to lead to memory hogging by the logging package. So, I propose to close this ticket now, but anyone can of course reopen it if they think there is still an issue here which needs addressing. I will review the docs to see if I need to clarify that loggers should not be created on a per-connection (or analogous) basis. ---------- resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 11:42:25 2008 From: report at bugs.python.org (Gerdus van Zyl) Date: Sun, 06 Jan 2008 10:42:25 -0000 Subject: [issue1741] .pypirc not found on windows Message-ID: <1199616145.41.0.131606702507.issue1741@psf.upfronthosting.co.za> Changes by Gerdus van Zyl: ---------- components: Distutils nosy: gerdus severity: normal status: open title: .pypirc not found on windows versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 11:45:21 2008 From: report at bugs.python.org (Gerdus van Zyl) Date: Sun, 06 Jan 2008 10:45:21 -0000 Subject: [issue1741] .pypirc not found on windows Message-ID: <1199616321.65.0.452980154178.issue1741@psf.upfronthosting.co.za> New submission from Gerdus van Zyl: register.py and upload.py both can't find the .pypirc on my system since there is no HOME environment variable. currently: if os.environ.has_key('HOME'): rc = os.path.join(os.environ['HOME'], '.pypirc') if os.path.exists(rc): works for me if changed to: rc = os.path.expanduser('~/.pypirc') if os.path.exists(rc): __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 12:57:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 11:57:36 -0000 Subject: [issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve error msg Message-ID: <1199620656.31.0.603930842428.issue1691070@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you review the patch and commit it for 2.6? A patch which cleans up the code *and* make it faster is always a good idea. :) ---------- assignee: -> nnorwitz nosy: +tiran versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 12:57:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 11:57:52 -0000 Subject: [issue1656675] Drop-Handler for Python files Message-ID: <1199620672.57.0.295935275728.issue1656675@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Windows versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 12:58:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 11:58:13 -0000 Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h Message-ID: <1199620693.42.0.685094904968.issue1699259@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> tiran nosy: +tiran type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 12:58:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 11:58:29 -0000 Subject: [issue1696393] Remove redundant code in ntpath.walk() Message-ID: <1199620709.75.0.256507598558.issue1696393@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 12:59:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 11:59:03 -0000 Subject: [issue588825] unittest.py, better error message Message-ID: <1199620743.83.0.569024470412.issue588825@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Tests -None keywords: +patch versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 13:00:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:00:18 -0000 Subject: [issue1682403] docutils clarification request for "rest" Message-ID: <1199620818.37.0.574352082162.issue1682403@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Distutils, Windows -Library (Lib) versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:00:40 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:00:40 -0000 Subject: [issue1245224] Time module is missing inverse of gmtime() Message-ID: <1199620840.48.0.939855816027.issue1245224@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> tiran keywords: +patch nosy: +tiran type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:05:37 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:05:37 -0000 Subject: [issue1625576] add ability to specify name to os.fdopen Message-ID: <1199621137.65.0.139875829183.issue1625576@psf.upfronthosting.co.za> Christian Heimes added the comment: Where is the patch, Mark? Collin, does fdopen(fd[, mode[, bufsize[, msg=None]]]) and '> sound good to you? ---------- assignee: -> collinwinter nosy: +tiran versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:06:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:06:44 -0000 Subject: [issue1439312] Patch for bug 1438185: os.renames deletes junction points Message-ID: <1199621204.4.0.215865888982.issue1439312@psf.upfronthosting.co.za> Christian Heimes added the comment: Martin, you are the Windows expert. Does it sound right to you? ---------- assignee: -> loewis nosy: +loewis, tiran versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:07:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:07:41 -0000 Subject: [issue762963] timemodule.c: Python loses current timezone Message-ID: <1199621261.65.0.760077980351.issue762963@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 13:08:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:08:08 -0000 Subject: [issue1529353] Squeezer - squeeze large output in the interpreter Message-ID: <1199621288.25.0.213589614976.issue1529353@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> kbk versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:10:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:10:58 -0000 Subject: [issue502236] Asynchronous exceptions between threads Message-ID: <1199621458.08.0.193487378484.issue502236@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 13:11:06 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:11:06 -0000 Subject: [issue1559549] ImportError needs attributes for module and file name Message-ID: <1199621466.66.0.905612890492.issue1559549@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:11:17 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:11:17 -0000 Subject: [issue1527597] New module: miniconf Message-ID: <1199621477.89.0.16667609458.issue1527597@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Library (Lib) -None versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:14:00 2008 From: report at bugs.python.org (Jesse Towner) Date: Sun, 06 Jan 2008 12:14:00 -0000 Subject: [issue1742] os.path.relpath fails when path == start Message-ID: <1199621640.67.0.296185501304.issue1742@psf.upfronthosting.co.za> Changes by Jesse Towner: ---------- components: Library (Lib) nosy: townerj severity: major status: open title: os.path.relpath fails when path == start type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 13:18:26 2008 From: report at bugs.python.org (Jesse Towner) Date: Sun, 06 Jan 2008 12:18:26 -0000 Subject: [issue1742] os.path.relpath fails when path == start Message-ID: <1199621906.39.0.0862491717843.issue1742@psf.upfronthosting.co.za> New submission from Jesse Towner: os.path.relpath fails with an exception on both Windows and Unix systems (ntpath and posixpath modules) when the given path and the start path are equal. Better behavior here might be to return an empty string or perhaps os.path.curdir. >>> os.path.relpath("test", "test") Traceback (most recent call last): File "", line 1, in os.path.relpath("test", "test") File "C:\Program Files\Python3K\Lib\ntpath.py", line 495, in relpath return join(*rel_list) TypeError: join() takes at least 1 positional argument (0 given) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 13:21:09 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:21:09 -0000 Subject: [issue1772673] Replacing char* with const char* Message-ID: <1199622069.92.0.739028940243.issue1772673@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:29:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:29:08 -0000 Subject: [issue416670] MatchObjects not deepcopy()able Message-ID: <1199622548.35.0.492222596426.issue416670@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 13:30:17 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:30:17 -0000 Subject: [issue1745722] please add wsgi to SimpleXMLRPCServer Message-ID: <1199622617.93.0.27588305892.issue1745722@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:32:06 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:32:06 -0000 Subject: [issue1772794] Telnetlib dosn't accept u'only ascii' Message-ID: <1199622726.64.0.523368364248.issue1772794@psf.upfronthosting.co.za> Christian Heimes added the comment: The code should raise a proper unicode error. In general network code accepts only bytes, not unicode. ---------- components: +Library (Lib) -None nosy: +tiran priority: normal -> low type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:32:20 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:32:20 -0000 Subject: [issue1757831] Allow opening just an editor window Message-ID: <1199622740.95.0.621199620486.issue1757831@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> kbk versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:32:48 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:32:48 -0000 Subject: [issue1753718] base64 "legacy" functions violate RFC 3548 Message-ID: <1199622768.04.0.15293604282.issue1753718@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:33:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:33:29 -0000 Subject: [issue1736792] dict reentrant/threading bug Message-ID: <1199622809.3.0.176776703732.issue1736792@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Interpreter Core -None type: -> rfe versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:33:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:33:56 -0000 Subject: [issue1732367] Document the constants in the socket module Message-ID: <1199622836.83.0.147128509416.issue1732367@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:34:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:34:28 -0000 Subject: [issue1731706] tkinter memory leak problem Message-ID: <1199622868.95.0.762010788545.issue1731706@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:35:14 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:35:14 -0000 Subject: [issue1100942] datetime.strptime constructor added Message-ID: <1199622914.33.0.904521317147.issue1100942@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> rfe versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:42:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:42:03 -0000 Subject: [issue1730372] Mesa with NPTL makes Python extensions crash with std::cerr Message-ID: <1199623323.52.0.414247363995.issue1730372@psf.upfronthosting.co.za> Christian Heimes added the comment: Please provide a failing test program or we have to close the bug. I can't reproduce it on my x86 machine with Python 2.5 and GCC 4.2 either. ---------- nosy: +tiran status: open -> pending versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:42:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:42:39 -0000 Subject: [issue634412] RFC 2112 in email package Message-ID: <1199623359.72.0.269339618127.issue634412@psf.upfronthosting.co.za> Christian Heimes added the comment: What about Python 2.6 support? :) ---------- assignee: -> barry components: +Interpreter Core -None nosy: +tiran versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 13:43:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:43:02 -0000 Subject: [issue1713877] Expose callback API in readline module Message-ID: <1199623382.42.0.146381876343.issue1713877@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:43:12 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:43:12 -0000 Subject: [issue1713877] Expose callback API in readline module Message-ID: <1199623392.85.0.367123437386.issue1713877@psf.upfronthosting.co.za> Christian Heimes added the comment: A patch is always welcome ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:44:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:44:36 -0000 Subject: [issue1707753] get status output fix for Win32 Message-ID: <1199623476.04.0.231567208465.issue1707753@psf.upfronthosting.co.za> Christian Heimes added the comment: Do you call 8 months "a few days"? *g* ---------- components: +Windows nosy: +tiran versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:45:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:45:18 -0000 Subject: [issue1708316] doctest work with Windows PyReadline Message-ID: <1199623518.57.0.904671703056.issue1708316@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:47:42 2008 From: report at bugs.python.org (Rich) Date: Sun, 06 Jan 2008 12:47:42 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za> New submission from Rich: Launching IDLE from the start menu has no effect, no windows open. Command line Python still works. Reinstalling Python does not fix the problem. I haven't changed my system configuration since everything was working. Any ideas for things to check to fix this on my system would be much appreciated! ---------- components: IDLE messages: 59364 nosy: richjtd severity: normal status: open title: IDLE fails to launch versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 13:48:38 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2008 12:48:38 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199623718.06.0.680767903953.issue932563@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, I have met this problem too some time ago, so could you please reopen the bug? Saying creating a lot of connection-bound logger objects is an "antipattern" doesn't help. It's the only simple way of doing something useful: have a logging target with different messages based on IP address (or whatever else, e.g. user name). Also, when you say "changes made to logging after this issue was created make it easier to include context information (e.g. connection IDs) in logging calls", that doesn't address the problem, because you have to include that "context information" in every logging class while what you really want to do is to include it once in the call to getLogger()... ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 13:49:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 12:49:21 -0000 Subject: [issue1673203] add identity function Message-ID: <1199623760.99.0.613221179551.issue1673203@psf.upfronthosting.co.za> Christian Heimes added the comment: What's the conclusion of your discussion? Do you consent to close the feature request? ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 13:51:25 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2008 12:51:25 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199623885.42.0.24326274448.issue932563@psf.upfronthosting.co.za> Antoine Pitrou added the comment: s/in every logging class/in every logging call/, sorry. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 14:40:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 13:40:18 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199626818.55.0.320719135102.issue1743@psf.upfronthosting.co.za> Christian Heimes added the comment: What's your OS and how did you install Python on your machine? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 14:41:07 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 13:41:07 -0000 Subject: [issue1741] .pypirc not found on windows Message-ID: <1199626867.12.0.690518282505.issue1741@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal type: -> behavior versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 14:50:39 2008 From: report at bugs.python.org (Gazi Alankus) Date: Sun, 06 Jan 2008 13:50:39 -0000 Subject: [issue1730372] Mesa with NPTL makes Python extensions crash with std::cerr Message-ID: <1199627439.05.0.518506100591.issue1730372@psf.upfronthosting.co.za> Gazi Alankus added the comment: If by not being able to reproduce, you mean that you campiled Mesa with NPTL support and tried a Python extension that's using std::cerr (like the attached source in the other thread I linked to) and is linked to -lGL, then fine. Mesa with NPTL support is compiled with # Add '-DGLX_USE_TLS' to ARCH_FLAGS to enable TLS support. as quoted from configuration files in config/ directory of Mesa source tree. I use Gentoo, if you believe it matters. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 15:12:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 14:12:47 -0000 Subject: [issue1256] subprocess Popen wait() function hangs when stdout is > 20480 Message-ID: <1199628767.45.0.0374537579596.issue1256@psf.upfronthosting.co.za> Christian Heimes added the comment: The docs should be updated, see #1606 ---------- nosy: +tiran resolution: -> wont fix status: open -> closed superseder: -> Doc: subprocess wait() may lead to dead lock __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 15:14:11 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 14:14:11 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199628851.85.0.172695277729.issue932563@psf.upfronthosting.co.za> Georg Brandl added the comment: Reopening. ---------- assignee: fdrake -> vsajip nosy: +georg.brandl resolution: out of date -> status: closed -> open ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 15:17:55 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 14:17:55 -0000 Subject: [issue1696393] Remove redundant code in ntpath.walk() Message-ID: <1199629075.78.0.480029543733.issue1696393@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r59769. Thanks! ---------- assignee: rhettinger -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 15:27:27 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 14:27:27 -0000 Subject: [issue1742] os.path.relpath fails when path == start Message-ID: <1199629647.3.0.5789369743.issue1742@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r59770. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 15:28:49 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 14:28:49 -0000 Subject: [issue1732367] Document the constants in the socket module Message-ID: <1199629729.77.0.556873515221.issue1732367@psf.upfronthosting.co.za> Georg Brandl added the comment: Be sure to use reST format now that we've switched to that. Much easier to type :) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 15:34:54 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 14:34:54 -0000 Subject: [issue1591] popen2.Popen3 class (Unix) documentation misleading / confusing Message-ID: <1199630094.9.0.182345632466.issue1591@psf.upfronthosting.co.za> Georg Brandl added the comment: I clarified the docstring in r59771. I won't extend it, however, since most types don't announce their attributes in the docstring. For that you should always consult the code or the official docs. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 15:35:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 14:35:53 -0000 Subject: [issue979658] Improve HTML documentation of a directory Message-ID: <1199630153.82.0.303038806268.issue979658@psf.upfronthosting.co.za> Georg Brandl added the comment: Unassigning myself - I have no opinion on pydoc. ---------- assignee: georg.brandl -> ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 15:21:48 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 14:21:48 -0000 Subject: [issue1245224] Time module is missing inverse of gmtime() Message-ID: <1199629308.98.0.392885746203.issue1245224@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> duplicate status: open -> closed superseder: -> Time zone-capable variant of time.localtime _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 15:45:34 2008 From: report at bugs.python.org (Alberto Bertogli) Date: Sun, 06 Jan 2008 14:45:34 -0000 Subject: [issue1646] Make socket support TIPC. In-Reply-To: <1199570895.64.0.896649235785.issue1646@psf.upfronthosting.co.za> Message-ID: <20080106144433.GF18632@gmail.com> Alberto Bertogli added the comment: On Sat, Jan 05, 2008 at 10:08:15PM -0000, Christian Heimes wrote: > I'm still waiting for a new patch. Your feature patch has been accepted > but I won't commit it without doc updates. I know, but holidays were not the best time to write documentation. I'll probably send you the updated patch sometime this week; thanks for the ping =) Thanks, Alberto __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 16:04:03 2008 From: report at bugs.python.org (roudkerk) Date: Sun, 06 Jan 2008 15:04:03 -0000 Subject: [issue1683] Thread local storage and PyGILState_* mucked up by os.fork() Message-ID: <1199631843.53.0.996600409507.issue1683@psf.upfronthosting.co.za> roudkerk added the comment: The included patch against python2.51 fixes the problem for me. ---------- versions: +Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9076/fork-thread-patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 16:14:07 2008 From: report at bugs.python.org (loic jeannin) Date: Sun, 06 Jan 2008 15:14:07 -0000 Subject: [issue1744] readline module - set/get quote delimiters Message-ID: <1199632447.57.0.76416797802.issue1744@psf.upfronthosting.co.za> New submission from loic jeannin: here is a patch against Modules/readline.c to add getter/setter for rl_completer_quote_characters. This is needed for advanced use of cmd.Cmd with completion. ---------- components: Extension Modules files: p2.5.1-readline.diff messages: 59380 nosy: loic severity: normal status: open title: readline module - set/get quote delimiters type: rfe versions: Python 2.4, Python 2.5 Added file: http://bugs.python.org/file9077/p2.5.1-readline.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 16:14:27 2008 From: report at bugs.python.org (Rich) Date: Sun, 06 Jan 2008 15:14:27 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199632467.1.0.15631690073.issue1743@psf.upfronthosting.co.za> Rich added the comment: I'm on 32-bit Windows Vista, and I installed with the Python 2.5 msi. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 16:20:59 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 15:20:59 -0000 Subject: [issue714469] Easy tutorial printing should be possible Message-ID: <1199632859.45.0.845959207389.issue714469@psf.upfronthosting.co.za> Georg Brandl added the comment: Which is now done. ---------- resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 16:29:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 15:29:08 -0000 Subject: [issue1681] parameter name for optparse parse_args incorrect Message-ID: <1199633348.0.0.776522682765.issue1681@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the report, this is already fixed in the SVN trunk. ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 16:30:49 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 15:30:49 -0000 Subject: [issue1680] what is decimal.Context.get_manager()? Message-ID: <1199633449.87.0.458402794824.issue1680@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r59772. Thanks for the report! ---------- assignee: facundobatista -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 16:31:34 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 15:31:34 -0000 Subject: [issue1218] Restrict Google search to docs when in the docs subtree? Message-ID: <1199633494.7.0.163382113023.issue1218@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 16:35:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 15:35:07 -0000 Subject: [issue1755097] document default values for sort parameters Message-ID: <1199633707.72.0.639703146944.issue1755097@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r59773. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 16:42:04 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 15:42:04 -0000 Subject: [issue1501] 0 ** 0 documentation Message-ID: <1199634124.81.0.857986822137.issue1501@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r59774. ---------- assignee: facundobatista -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 16:43:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 15:43:53 -0000 Subject: [issue1702] Word "alias" used in confusing way to compare open() and file() Message-ID: <1199634233.24.0.473236431217.issue1702@psf.upfronthosting.co.za> Georg Brandl added the comment: I had already cleaned this up in the trunk. ---------- resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 16:48:37 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 15:48:37 -0000 Subject: [issue759525] inspect.getmembers broken (?) Message-ID: <1199634516.95.0.340098075721.issue759525@psf.upfronthosting.co.za> Georg Brandl added the comment: Added a doc clarification in r59775. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 16:55:44 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 15:55:44 -0000 Subject: [issue1615275] tempfile.TemporaryFile differences between linux and windows Message-ID: <1199634944.09.0.514407688692.issue1615275@psf.upfronthosting.co.za> Georg Brandl added the comment: Documented in r59776. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed title: tempile.TemporaryFile differences between linux and windows -> tempfile.TemporaryFile differences between linux and windows _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 17:01:44 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 16:01:44 -0000 Subject: [issue1727024] subprocess: unreliability of returncode not clear from docs Message-ID: <1199635304.95.0.139303243159.issue1727024@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the report, fixed the documentation in r59777. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 17:04:02 2008 From: report at bugs.python.org (Robin Stocker) Date: Sun, 06 Jan 2008 16:04:02 -0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 Message-ID: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za> New submission from Robin Stocker: The attached patch ports the implementation of keyword-only arguments from revision 52491 back to trunk. This is the first time I've worked on the C internals, so here are some notes: - test_collections is the only test which fails, because it tries to call a function with more than 255 arguments, which results in a SyntaxError because of the following added code in Python/ast.c. What should be done about it? if (nposargs + nkwonlyargs > 255) { ast_error(n, "more than 255 arguments"); return NULL; } - The patch only adds what's in revision 52491. There is at least one more change involving keyword-only arguments, for example issue1573. Are there others? Should they be included in this patch or in a separate one? - There are some changes which were generated, like Python/Python-ast.c (which needs to be checked in separately). - Is there documentation which needs to be updated? ---------- components: Interpreter Core files: backport-keyword-only-arguments.patch messages: 59391 nosy: robin.stocker severity: normal status: open title: Backport of PEP 3102 "keyword-only arguments" to 2.6 type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9078/backport-keyword-only-arguments.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 17:05:15 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 16:05:15 -0000 Subject: [issue1686390] csv sniff example Message-ID: <1199635514.98.0.0329601836412.issue1686390@psf.upfronthosting.co.za> Georg Brandl added the comment: I edited the example a bit and added it to the docs in r59778. ---------- assignee: skip.montanaro -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 17:12:50 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 16:12:50 -0000 Subject: [issue1559684] shutil.copyfile incomplete on NTFS Message-ID: <1199635970.9.0.807813574677.issue1559684@psf.upfronthosting.co.za> Georg Brandl added the comment: Clarified docs in r59779. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 17:18:11 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 16:18:11 -0000 Subject: [issue1582] Documentation patch for reversed() and __reversed__() Message-ID: <1199636291.79.0.0381098909082.issue1582@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, reformatted a bit and committed as r59780. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 17:20:26 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 16:20:26 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199636426.41.0.875647936406.issue602345@psf.upfronthosting.co.za> Georg Brandl added the comment: Does the flag name -R still make sense with the new env var name? ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 17:23:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 16:23:07 -0000 Subject: [issue1499] failure behaviour of compile() is missing Message-ID: <1199636587.46.0.376359594974.issue1499@psf.upfronthosting.co.za> Georg Brandl added the comment: Should be done in r59781. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 17:31:22 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 16:31:22 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199637082.47.0.257551346506.issue602345@psf.upfronthosting.co.za> Christian Heimes added the comment: What do you think about PYTHONOMITPYC, --omit-pyc and sys.omit_pyc_creation? ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 17:39:22 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 06 Jan 2008 16:39:22 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199637562.17.0.131573692396.issue602345@psf.upfronthosting.co.za> Changes by Skip Montanaro: ---------- nosy: -skip.montanaro ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 17:50:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 16:50:01 -0000 Subject: [issue1325] zipimport.zipimporter.archive undocumented and untested Message-ID: <1199638201.24.0.123947625719.issue1325@psf.upfronthosting.co.za> Georg Brandl added the comment: Added docs and tests in r59782. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 18:46:33 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 17:46:33 -0000 Subject: [issue1715] Make pydoc list submodules Message-ID: <1199641593.8.0.0387198662423.issue1715@psf.upfronthosting.co.za> Georg Brandl added the comment: This patch duplicates entries for "package contents" and "submodules"; this is not good. (E.g. for help(email): NAME email - A package for parsing, handling, and generating email messages. FILE /home/gbr/devel/python/Lib/email/__init__.py PACKAGE CONTENTS _parseaddr base64mime charset encoders errors feedparser generator header iterators message mime (package) parser quoprimime test (package) utils SUBMODULES _parseaddr base64mime charset email encoders errors feedparser generator header iterators message mime parser quoprimime sys utils ) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 19:00:48 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 18:00:48 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199642448.17.0.206875682371.issue602345@psf.upfronthosting.co.za> Georg Brandl added the comment: Attaching new diff, with -B flag name, PYTHONDONTWRITEBYTECODE, and sys.dont_write_bytecode. Added file: http://bugs.python.org/file9079/no-pyc-flag.diff ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 19:09:26 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 18:09:26 -0000 Subject: [issue683658] PyErr_Warn may cause import deadlock Message-ID: <1199642966.36.0.506058984106.issue683658@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: open -> pending ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 19:41:47 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 06 Jan 2008 18:41:47 -0000 Subject: [issue1439312] Patch for bug 1438185: os.renames deletes junction points Message-ID: <1199644907.6.0.00969785001559.issue1439312@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm skeptical. If you consider junction points similar to symlinks on POSIX, then it would be semantically correct to leave the junction point in place, independent of whether their target directory is empty or not - on Unix, rmdir fails if the target is a symlink. Given the documentation, I think the removedirs function does exactly do what the documentation specifies as the algorithm (i.e. recursively rmdir until an error occurs). The promise ("remove all empty intermediate directories") is not held: on POSIX, it would stop at a symlink even if that symlink was the only entry in the directory, and on Windows, the junction point is removed even if the target directory is not empty. I would rather fix this in the documentation than change something in the implementation. If the behavior is to be changed, the documentation needs to be updated. The patch does introduce a significant behavior change: if the last directory is not empty, it now silently returns; previously, it would raise OSError. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 19:43:57 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 06 Jan 2008 18:43:57 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199645037.58.0.0756879685314.issue1743@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please open IDLE from the command line: 1. start cmd.exe 2. run "" "/Lib/idle/idle.py" That should give you an error, please report it. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 19:45:57 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 06 Jan 2008 18:45:57 -0000 Subject: [issue1744] readline module - set/get quote delimiters Message-ID: <1199645157.67.0.805151667092.issue1744@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As a new feature, it can't go into 2.5. Targetting for 2.6. ---------- nosy: +loewis versions: +Python 2.6 -Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 19:55:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2008 18:55:18 -0000 Subject: [issue1744] readline module - set/get quote delimiters Message-ID: <1199645718.98.0.116396857605.issue1744@psf.upfronthosting.co.za> Christian Heimes added the comment: Please provide a patch against the trunk. Don't forget to update the documentation and to add an unit test. ---------- keywords: +patch nosy: +tiran priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 21:55:41 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sun, 06 Jan 2008 20:55:41 -0000 Subject: [issue1622] zipfile hangs on certain zip files Message-ID: <1199652941.5.0.655082587351.issue1622@psf.upfronthosting.co.za> Alan McIntyre added the comment: Based on the ZIP spec (I'm using the one here: http://www.pkware.com/documents/casestudies/APPNOTE.TXT), I'm inclined to agree. There's a general note that says "All fields unless otherwise noted are unsigned and stored in Intel low-byte:high-byte, low-word:high-word order." I can't find any explicit mention of any fields that should be signed. Since I find myself poking around in the ZIP file format today, I may try changing all the format strings to unsigned, and writing up some tests to check cases that can be run in a reasonable amount of time. If I get anything usable I'll post a patch. ---------- nosy: +alanmcintyre __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 22:24:54 2008 From: report at bugs.python.org (Robin Stocker) Date: Sun, 06 Jan 2008 21:24:54 -0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 Message-ID: <1199654694.18.0.410814014955.issue1745@psf.upfronthosting.co.za> Robin Stocker added the comment: Another note: Because the marshalling of code objects is changed, is there a version number of the format which has to be incremented? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 22:44:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 21:44:40 -0000 Subject: [issue1772833] -q (quiet) option for python interpreter Message-ID: <1199655880.12.0.70651999888.issue1772833@psf.upfronthosting.co.za> Georg Brandl added the comment: Guido, ping? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 22:54:47 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sun, 06 Jan 2008 21:54:47 -0000 Subject: [issue1011893] Problems importing packages in ZIP file Message-ID: <1199656487.06.0.539637813607.issue1011893@psf.upfronthosting.co.za> Alan McIntyre added the comment: I just tried out this test with the trunk and 2.5.2 from svn (on OS X, not sure if that might make a difference), and didn't get the reported error. Since the issue has apparently been fixed at some point, is there any reason not to close this issue? ---------- nosy: +alanmcintyre _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 6 23:28:45 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sun, 06 Jan 2008 22:28:45 -0000 Subject: [issue774221] 2.3c1: zipfile.py confused by garbage at the very end of zip Message-ID: <1199658525.62.0.477672760361.issue774221@psf.upfronthosting.co.za> Alan McIntyre added the comment: Since there's no reply about where ZIP files with appended 'garbage' might come from, should this be closed? I agree with amk; it doesn't seem wise to ignore incorrectly formatted files without a good reason. On a related note, it seems that correctly formatted ZIP files with comments longer than 4k will not be recognized as a ZIP file by the zipfile module. There's some comment about not looking at more than the last 4k of the file for "efficiency" reasons, but failing to interpret a correct file seems to override the efficiency concern of reading/searching another 60k of data. I'll open a separate tracker item for this, since it's not strictly related to the original issue. ---------- nosy: +alanmcintyre ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 6 23:38:22 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 22:38:22 -0000 Subject: [issue1668] -E command line parameter intent Message-ID: <1199659102.07.0.110779053027.issue1668@psf.upfronthosting.co.za> Georg Brandl added the comment: This is a documentation issue, it seems. The new command-line document already says only PYTHON* vars are ignored. ---------- components: +Documentation -Interpreter Core nosy: +georg.brandl versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 23:40:17 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sun, 06 Jan 2008 22:40:17 -0000 Subject: [issue1746] ZIP files with archive comments longer than 4k not recognized as valid by zipfile module Message-ID: <1199659217.24.0.18704559865.issue1746@psf.upfronthosting.co.za> New submission from Alan McIntyre: The current behavior of zipfile._EndRecData is to look in the last 4k of data in a file if it appears it might have an archive comment; this results in flagging proper ZIP files with comments longer than ~4074 bytes as "not a ZIP file." I plan on posting a patch for this later, but figured this should be documented in case I don't get around to it. ---------- components: Library (Lib) messages: 59411 nosy: alanmcintyre severity: normal status: open title: ZIP files with archive comments longer than 4k not recognized as valid by zipfile module type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 23:46:35 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 06 Jan 2008 22:46:35 -0000 Subject: [issue1747] isinstance(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False Message-ID: <1199659595.05.0.292041718212.issue1747@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin: Python 2.6a0 (trunk:59791M, Jan 6 2008, 12:22:37) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import abc [30620 refs] >>> class A: ... __metaclass__ = abc.ABCMeta ... [30650 refs] >>> class B: ... pass ... [30659 refs] >>> issubclass(B, A) Traceback (most recent call last): File "", line 1, in File "/Users/jyasskin/src/python/trunk-abc/Lib/abc.py", line 191, in __subclasscheck__ if cls in subclass.__mro__: AttributeError: class B has no attribute '__mro__' [30701 refs] >>> This causes Decimal to break in interesting ways when I make it subclass numbers.Real. test_abc doesn't catch it because it declares __metaclass__=type at the top level. :-( This looks relatively easy to fix, so I'll work on a patch. ---------- assignee: jyasskin components: Library (Lib) messages: 59412 nosy: gvanrossum, jyasskin severity: normal status: open title: isinstance(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 6 23:59:06 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2008 22:59:06 -0000 Subject: [issue1748] contextlib.contextmanager does not use functools.wraps Message-ID: <1199660346.11.0.927717674711.issue1748@psf.upfronthosting.co.za> New submission from Antoine Pitrou: The contextmanager function should call functools.wraps instead of having its own attribute copying code. Just something I noticed while reading the source. ---------- components: Library (Lib) messages: 59413 nosy: pitrou severity: minor status: open title: contextlib.contextmanager does not use functools.wraps versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 00:06:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 06 Jan 2008 23:06:49 -0000 Subject: [issue1750] Test: This is title Message-ID: <1199660809.31.0.345671159416.issue1750@psf.upfronthosting.co.za> New submission from Martin v. L?wis: This is the change message ---------- messages: 59415 nosy: loewis severity: normal status: open title: Test: This is title __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 00:07:39 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 06 Jan 2008 23:07:39 -0000 Subject: [issue1750] Test: This is title Message-ID: <1199660859.35.0.807808327519.issue1750@psf.upfronthosting.co.za> Martin v. L?wis added the comment: And another change message __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 00:18:31 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 06 Jan 2008 23:18:31 -0000 Subject: [issue1623] Implement PEP-3141 for Decimal Message-ID: <1199661511.43.0.345691691491.issue1623@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I think this reflects the consensus of http://mail.python.org/pipermail/python-dev/2008-January/075798.html. I haven't yet implemented Context.round() as I suggested at http://mail.python.org/pipermail/python-dev/2008-January/075920.html because there are more details to discuss, and I don't want to sidetrack the discussion about basic PEP 3141 support. The test currently fails due to issue 1747. I'll double-check that it passes once that's fixed. ---------- dependencies: +isinstance(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False Added file: http://bugs.python.org/file9080/decimal-3141.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 00:20:22 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 06 Jan 2008 23:20:22 -0000 Subject: [issue1750] Test: This is title Message-ID: <1199661622.1.0.954423203887.issue1750@psf.upfronthosting.co.za> Martin v. L?wis added the comment: End of testing. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 00:34:18 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2008 23:34:18 -0000 Subject: [issue1748] contextlib.contextmanager does not use functools.wraps Message-ID: <1199662458.01.0.194202848211.issue1748@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> ncoghlan nosy: +ncoghlan __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 00:38:53 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 06 Jan 2008 23:38:53 -0000 Subject: [issue1668] -E command line parameter intent Message-ID: <1199662733.38.0.045688877029.issue1668@psf.upfronthosting.co.za> Guido van Rossum added the comment: To resolve this, how about this patch (getenv.2.diff)? - change getenv("PYTHONCASEOK") -> Py_GETENV() (inside #ifdef PYOS_OS2) - rename THREADDEBUG -> PYTHONTHREADDEBUG and use Py_GETENV() Added file: http://bugs.python.org/file9081/getenv.2.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 00:44:10 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 06 Jan 2008 23:44:10 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199663050.45.0.773673667711.issue602345@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks good, please commit! (Christian: the problem with using PYC in the envar name is that it is ambiguous about what happens to PYO files...) ---------- resolution: -> accepted ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 00:55:01 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 06 Jan 2008 23:55:01 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199663701.8.0.103423189126.issue602345@psf.upfronthosting.co.za> Guido van Rossum added the comment: PS the patch still has a problem: Python/pythonrun.c:177: error: ?Py_ReadOnlyBytecodeFlag? undeclared (first use in this function) ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 01:09:23 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 07 Jan 2008 00:09:23 -0000 Subject: [issue1747] issubclass(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False Message-ID: <1199664563.87.0.130631491146.issue1747@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: This is certainly not the only way to fix this. Is it the best? ---------- keywords: +patch title: isinstance(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False -> issubclass(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False Added file: http://bugs.python.org/file9082/subclass_oldstyle.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 01:49:27 2008 From: report at bugs.python.org (Eric Huss) Date: Mon, 07 Jan 2008 00:49:27 -0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1199652941.5.0.655082587351.issue1622@psf.upfronthosting.co.za> Message-ID: Eric Huss added the comment: Some of this work has already been done, see issue 1189216. You'll obviously need to keep the CRC unpack as signed because the binascii module uses signed values. Some header values are stored as 0xffffffff to denote the value is stored in the 64-bit extended fields. There are a few places in the zipfile module that use -1 to achieve this. This will cause a deprecation warning when passed into the struct module: DeprecationWarning: struct integer overflow masking is deprecated The places that check for this appear to always check for both -1 and 0xfffffff, so that should be safe. Could potentially even remove the -1 check, not sure why it's checking for both. In general, you should probably review the 64-bit support with a fine-toothed comb. There are some other signed fields in the spec, but I don't think any of them apply to the zipfile module. Some of them are timestamps in the extra fields (Extended Timestamp and Info-ZIP Mac Extra fields). I'd also keep an eye on other zipfile bugs that appear to be sign-related (which you appear to have already looked at), such as issues 1189216, 1060, 1760357, 1526. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 02:31:50 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Jan 2008 01:31:50 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. Message-ID: <1199669510.7.0.840825269343.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: Some random comments: take with a large pinch of salt (1) In __init__ I think you want something like: self._numerator = int(numerator)//g instead of self._numerator = int(numerator / g) and similarly for the denominator. At the moment I get, for example: >>> Rational(10**23) rational.Rational(99999999999999991611392,1) (2) What's the reason for repr of a Rational being "rational.Rational(...)", while repr of a Decimal is just "Decimal(...)"? I'm not suggesting that either is wrong; just wondering whether there's some sort of guiding principle that would suggest one or the other. (3) My first thought on looking at the _gcd function was: "Shouldn't there be an abs() somewhere in there"; since the gcd of two (possibly negative) integers is often (usually?) defined as the largest *nonnegative* common divisor. But on closer examination it's clear that the result of _gcd(a, b) has the same sign as that of b (unless b == 0). So _gcd very cleverly chooses exactly the right sign so that the denominator after rescaling is positive. I'm not sure whether this is a happy accident or clever design, but either way it probably deserves a comment. (4) the __ceil__ operation could be spelt more neatly as return -(-a.numerator // a.denominator) ...but perhaps that just amounts to obfuscation :) (5) It looks as though two-argument round just truncates when the second argument is negative. Presmably this isn't what's wanted here? >>> round(Rational(26), -1) # expecting Rational(30, 1) rational.Rational(20,1) (6) The behaviour of the equality test is questionable when floats are involved. For example: >>> 10**23 == float(10**23) # expect False False >>> Rational(10**23) == float(10**23) # I'd also expect False here True Ideally, if x is a Rational and y is a float then I'd suggest that x == y should return True only when the numeric values really are equal. Coding this could be quite tricky, though. One option would be to convert the float to an (exactly equal) Rational first-- -there's code to do this in the version of Rational.py in the sandbox. (7) For purely selfish reasons, I for one will be very happy if/when this makes it into 2.6/3.0: I use Python a lot for teaching (geometry, number theory, linear algebra, ...); it's natural to work with rational numbers in this context; and it'll be much easier to tell an interested student to just download Python than to tell them they also need gmp and gmpy, or some other third party package, just to try out the code examples I've given them. ---------- nosy: +marketdickinson __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 03:21:47 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Jan 2008 02:21:47 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. Message-ID: <1199672507.46.0.338887375023.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: Two more questions: (1) should a Rational instance be hashable? (2) Should "Rational(5,2) == Decimal('2.5')" evaluate to True or False? If Rationals are hashable and 2.5 == Rational(5, 2) == Decimal('2.5') then the rule that objects that compare equal should have equal hash is going to make life *very* interesting... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 03:43:08 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 02:43:08 -0000 Subject: [issue1747] issubclass(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False Message-ID: <1199673788.02.0.50456223687.issue1747@psf.upfronthosting.co.za> Guido van Rossum added the comment: lgtm ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 04:39:32 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 03:39:32 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files Message-ID: <1199677171.95.0.107674158512.issue1526@psf.upfronthosting.co.za> Guido van Rossum added the comment: I was about to check this in, when I noticed that the test runs for ~16 seconds on my state-of-the-arg hardware. I think that's too long. Perhaps it should only be run when -ulargefile is enabled? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 05:03:17 2008 From: report at bugs.python.org (Alan McIntyre) Date: Mon, 07 Jan 2008 04:03:17 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files Message-ID: <1199678597.03.0.11460403958.issue1526@psf.upfronthosting.co.za> Alan McIntyre added the comment: Oh thanks, I meant to ask whether or not the run time was too long, but forgot. Only running when -ulargefile is enabled seems fine to me. I can tweak the patch for that if you'd like; moving it to test_zipfile64 should do that, right? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 05:14:08 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 04:14:08 -0000 Subject: [issue1741] .pypirc not found on windows Message-ID: <1199679248.25.0.94535673429.issue1741@psf.upfronthosting.co.za> Guido van Rossum added the comment: Bug day candidate? 2.5.2 backport candidate. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 05:22:53 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 04:22:53 -0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 Message-ID: <1199679773.82.0.0668986550764.issue1745@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks for tackling this! What line in test_collections.py is calling a function with >255 args? I'm a bit surprised since this has always been disallowed AFAICT. I'd like to see everything related to keyword-only args included in one patch. Hopefully the unittests and/or svn history will give you an idea of what to do. There should be docs in the reference manual. Maybe Georg knows where. Don't worry about the generated Python-ast.c patch. The version number you're looking for is MAGIC in Python/import.c. ---------- nosy: +georg.brandl, gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 05:22:59 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 04:22:59 -0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 Message-ID: <1199679779.5.0.551484556176.issue1745@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 05:25:21 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 04:25:21 -0000 Subject: [issue1622] zipfile hangs on certain zip files Message-ID: <1199679921.15.0.722900623374.issue1622@psf.upfronthosting.co.za> Guido van Rossum added the comment: Alan and Eric, can I depend on you two to review each other's code and let me know when you think the patch is ready to be submitted? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 05:32:27 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 04:32:27 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files Message-ID: <1199680347.18.0.579521926241.issue1526@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sounds like a plan. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 07:11:39 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 07 Jan 2008 06:11:39 -0000 Subject: [issue1747] issubclass(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False Message-ID: <1199686299.24.0.792092312826.issue1747@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Committed as r59809. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 07:56:17 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 07 Jan 2008 06:56:17 -0000 Subject: [issue1623] Implement PEP-3141 for Decimal Message-ID: <1199688977.89.0.207114956743.issue1623@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Much smaller now. 3.0 will need an additional patch beyond the "automatic" forward port. ---------- versions: +Python 2.6 Added file: http://bugs.python.org/file9083/decimal-3141-just-trunc.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 08:13:05 2008 From: report at bugs.python.org (strank) Date: Mon, 07 Jan 2008 07:13:05 -0000 Subject: [issue1713877] Expose callback API in readline module Message-ID: <1199689985.5.0.911595090371.issue1713877@psf.upfronthosting.co.za> strank added the comment: I am pretty sure I posted a patch in the sf patch tracker... oh yes, here it is: http://bugs.python.org/issue1744456 I think it still needs some work if you want to make it impossible for users of the API to wreck the interactive prompt. If this possibility is considered ok (it does not make sense to use the callback api from the interactive prompt anyway), I think it's ok. But someone with more readline experience should probably look at it... :-) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 08:20:32 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 07:20:32 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: Finally, here is my C implementation of BytesIO. The code is well tested and include the proper unit tests. The only remaining issues are: - The behavior of the close() method. - The failure of test_profile and test_cProfile. Currently, I have no idea how to fix the tests for the profilers. The weird thing is both pass when run with: % ./python Lib/test/regrtest.py -R: test_profile ---------- components: Interpreter Core, Library (Lib), Tests files: _bytesio.c keywords: patch messages: 59436 nosy: alexandre.vassalotti, gvanrossum priority: normal severity: normal status: open title: Fast BytesIO implementation + misc changes versions: Python 3.0 Added file: http://bugs.python.org/file9084/_bytesio.c __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 08:21:11 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 07:21:11 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199690471.36.0.299297052399.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: Added file: http://bugs.python.org/file9085/add-bytesio-setup.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 08:22:38 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 07:22:38 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199690558.8.0.455068572097.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: Added file: http://bugs.python.org/file9086/swap-initstdio-initsite.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 08:23:03 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 07:23:03 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199690583.83.0.849929452344.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: Added file: http://bugs.python.org/file9087/test_memoryio.py __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 08:23:30 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 07:23:30 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199690610.54.0.991576347941.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: Added file: http://bugs.python.org/file9088/remove-old-stringio-test.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 08:24:08 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 07:24:08 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199690648.42.0.994082236656.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: Added file: http://bugs.python.org/file9089/truncate-semantic-change.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 08:25:09 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 07:25:09 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199690709.04.0.00326080985973.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: Added file: http://bugs.python.org/file9090/io-misc-fixes.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 08:28:09 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 07:28:09 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199690889.04.0.789023609475.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 08:46:49 2008 From: report at bugs.python.org (Max Ischenko) Date: Mon, 07 Jan 2008 07:46:49 -0000 Subject: [issue1752] logging.basicConfig misleading behaviour Message-ID: <1199692009.12.0.936075891913.issue1752@psf.upfronthosting.co.za> New submission from Max Ischenko: Function logging.basicConfig has a confusing and undocumented behaviour: it does nothing if there are any handlers already present in root logger. It could be more explicit, say, by giving a ValueError in such cases. ---------- components: Library (Lib) messages: 59437 nosy: imax severity: normal status: open title: logging.basicConfig misleading behaviour type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 09:50:34 2008 From: report at bugs.python.org (Erick Tryzelaar) Date: Mon, 07 Jan 2008 08:50:34 -0000 Subject: [issue1753] TextIOWrapper.write writes utf BOM for every string Message-ID: <1199695834.32.0.627180179119.issue1753@psf.upfronthosting.co.za> New submission from Erick Tryzelaar: I was playing around with python 3's io functions, and I found that when trying to write to an encoded utf-16 file that TextIOWrapper.write re-writes the utf-16 bom for every string: >>> f=open('foo', 'w', encoding='utf-16') >>> print('1234', file=f) >>> print('5678', file=f) >>> open('foo', 'rb').read() b'\xff\xfe1\x002\x003\x004\x00\xff\xfe\n\x00\xff\xfe5\x006\x007\x008\x00\xff\xfe\n\x00' >>> open('foo', 'r', encoding='utf-16').read() '1234\ufeff\n\ufeff5678\ufeff\n' >>> With the attached patch, it appears to generate the correct file: >>> f=open('foo', 'w', encoding='utf-16') >>> print('1234', file=f) >>> print('5678', file=f) >>> open('foo', 'rb').read() b'\xff\xfe1\x002\x003\x004\x00\n\x005\x006\x007\x008\x00\n\x00' >>> open('foo', 'r', encoding='utf-16').read() '1234\n5678\n' >>> ---------- components: Library (Lib) files: io.py.patch messages: 59438 nosy: erickt severity: normal status: open title: TextIOWrapper.write writes utf BOM for every string type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9091/io.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 10:21:11 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 09:21:11 -0000 Subject: [issue1753] TextIOWrapper.write writes utf BOM for every string Message-ID: <1199697671.81.0.997693855284.issue1753@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> alexandre.vassalotti nosy: +alexandre.vassalotti __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 10:32:49 2008 From: report at bugs.python.org (Alberto Bertogli) Date: Mon, 07 Jan 2008 09:32:49 -0000 Subject: [issue1646] Make socket support TIPC. In-Reply-To: <20080106144433.GF18632@gmail.com> Message-ID: <20080107093159.GK18632@gmail.com> Alberto Bertogli added the comment: On Sun, Jan 06, 2008 at 02:45:35PM -0000, Alberto Bertogli wrote: > I'll probably send you the updated patch sometime this week; thanks for > the ping =) Here are the three patches, rebased to the SVN commit 59815. The first one is the same I've already submitted, the second adds the documentation and the third two testcases. The testcases are simple, but I think cover a reasonable amount of TIPC specific code. If you want more, let me know. The documentation is simple, as you told me, just a paragraph explaining about the address format and another explaining the constants. Again, if you want me to change anything, just let me know. Finally, if you want me to rebase this on top of any other branch, you guessed it, just let me know ;) Thanks a lot, Alberto Added file: http://bugs.python.org/file9092/0001-Make-socket-support-TIPC.patch Added file: http://bugs.python.org/file9093/0002-Add-documentation-and-Misc-NEWS-entry-for-TIPC-suppo.patch Added file: http://bugs.python.org/file9094/0003-Add-unit-tests-for-TIPC-socket-support.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Make-socket-support-TIPC.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080107/f9aa1791/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Add-documentation-and-Misc-NEWS-entry-for-TIPC-suppo.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080107/f9aa1791/attachment-0001.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0003-Add-unit-tests-for-TIPC-socket-support.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080107/f9aa1791/attachment-0002.txt From report at bugs.python.org Mon Jan 7 11:23:26 2008 From: report at bugs.python.org (Dennis Chuah) Date: Mon, 07 Jan 2008 10:23:26 -0000 Subject: [issue1011893] Problems importing packages in ZIP file Message-ID: <1199701406.0.0.833365466869.issue1011893@psf.upfronthosting.co.za> Dennis Chuah added the comment: I had forgotten about this bug. I haven't been able to test this on 2.5 as I have not worked with Python for a while. I think if you are satisfied that the problem doesn't exist, then close it. If I find it again, I can certainly log the problem again. BTW, did you manage to test whether the problem existed in the version that I reported it in? ---------- versions: +Python 2.3 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 12:24:32 2008 From: report at bugs.python.org (Romulo A. Ceccon) Date: Mon, 07 Jan 2008 11:24:32 -0000 Subject: [issue1754] WindowsError messages are not properly encoded Message-ID: <1199705072.7.0.841408898872.issue1754@psf.upfronthosting.co.za> New submission from Romulo A. Ceccon: The message for WindowsError is taken from the Windows API's FormatMessage() function, following the OS language. Currently Python does no conversion for those messages, so non-ASCII characters end up improperly encoded in the console. For example: >>> import os >>> os.rmdir('E:\\temp') Traceback (most recent call last): File "", line 1, in WindowsError: [Error 41] A pasta n?o est? vazia: 'E:\\temp' Should be: "A pasta n?o est? vazia" [Folder is not empty]. Python could check what is the code page of the current output interface and change the message accordingly. ---------- components: Windows messages: 59441 nosy: Romulo A. Ceccon severity: minor status: open title: WindowsError messages are not properly encoded type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 13:21:23 2008 From: report at bugs.python.org (Facundo Batista) Date: Mon, 07 Jan 2008 12:21:23 -0000 Subject: [issue1562] Decimal can't be subclassed useful Message-ID: <1199708483.82.0.536661701567.issue1562@psf.upfronthosting.co.za> Facundo Batista added the comment: Mark is right, the current behaviour is correct. See Tim post for a longer explanation. As general help, for the money class take a look of this: http://sourceforge.net/projects/pymoney There you'll see that the approach was to store the value, not subclass Decimal, as the other currency info makes math ugly. For example: Money("15.30", currency="USD") + Money("2.33", currency="ARS") There's a lot of discussion for a Money data type, also, in python-list and python-dev (I even proposed a pre-PEP), but then Decimal was implemented; check those lists at the fourth quarter of 2003 for these posts. Regards, ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 13:41:37 2008 From: report at bugs.python.org (Dariusz Suchojad) Date: Mon, 07 Jan 2008 12:41:37 -0000 Subject: [issue1737] Windows installer issue (ObjectBrowser.py) Message-ID: <1199709696.98.0.396943731205.issue1737@psf.upfronthosting.co.za> Dariusz Suchojad added the comment: Done. Attached in python.zip. I've also noticed something strange here. http://python.org/download/releases/2.5.1/ says the MD5 sum should be a1d1a9c07bc4c78bd8fa05dd3efec87f but the MD5 client I'm using (http://www.pc-tools.net/win32/md5sums/) tells me the http://python.org/ftp/python/2.5.1/python-2.5.1.msi file's checksum is D:\tmp\python_install>md5 python-2.5.1.msi MD5sums 1.2 freeware for Win9x/ME/NT/2000/XP+ Copyright (C) 2001-2005 Jem Berkes - http://www.pc-tools.net/ Type md5 -h for help [Path] / filename MD5 sum ------------------------------------------------------------------------------- [D:\tmp\python_install\] python-2.5.1.msi bd4780277a4bdfcd693593379e1b383c What does it mean? Is it my client fault? Added file: http://bugs.python.org/file9095/python.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 15:06:31 2008 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 07 Jan 2008 14:06:31 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199714791.28.0.340750118846.issue932563@psf.upfronthosting.co.za> Vinay Sajip added the comment: Antoine, I take your point, but there are a number of ways of doing what you want, apart from the "extra" context argument: 1. Use your own logger classes which do what you want. It's probably best to make this a wrapper class so you can define different ones for different needs. 2. Use a non-string as your message. The "message" object passed to logging can be any object - str() is called on this to get the actual message. 3. You can use custom Formatter and/or Filter objects to manipulate the logged message and/or LogRecord instances. You could pass context information in a number of different ways, but using a threadlocal might be convenient where the platform supports it. Any of these approaches should work, and there should be no need to have a pattern where lots of logging.Logger instances need to be created just to output context information. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 15:08:12 2008 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 07 Jan 2008 14:08:12 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199714892.29.0.450727240647.issue932563@psf.upfronthosting.co.za> Changes by Vinay Sajip: ---------- priority: high -> normal ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 15:08:31 2008 From: report at bugs.python.org (Brad Tilley) Date: Mon, 07 Jan 2008 14:08:31 -0000 Subject: [issue1755] Misspelling in future.c in 2.5.1 source (handl should be handle) Message-ID: <1199714911.67.0.807778924575.issue1755@psf.upfronthosting.co.za> New submission from Brad Tilley: /* A subsequent pass will detect future imports that don't appear at the beginning of the file. There's one case, however, that is easier to handl here: A series of imports joined by semi-colons, where the first import is a future statement but some subsequent import has the future form but is preceded by a regular import. */ ---------- components: None messages: 59445 nosy: brad severity: minor status: open title: Misspelling in future.c in 2.5.1 source (handl should be handle) versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 15:31:30 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Mon, 07 Jan 2008 14:31:30 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199716290.88.0.934508914336.issue932563@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Ideally, it would be best if loggers didn't live forever behind the scenes if they have no non-default configuration, but documenting their long-lived nature and the recommended alternate ways to deal with getting additional context information into the results. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 15:41:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2008 14:41:58 -0000 Subject: [issue1755] Misspelling in future.c in 2.5.1 source (handl should be handle) Message-ID: <1199716918.2.0.60040036631.issue1755@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Interpreter Core -None priority: -> low resolution: -> accepted versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 16:07:08 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 15:07:08 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199718428.95.0.675512197801.issue1751@psf.upfronthosting.co.za> Guido van Rossum added the comment: Any chance of uploading a single patch that contains all these changes? The profile tests often fail when io.py changes because they happen to depend on "golden output" which includes line numbers of code in io.py that happens to be traced during the test. I don't know why -R: makes it pass but it could be that it doesn't compare the golden output. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 16:24:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2008 15:24:04 -0000 Subject: [issue1646] Make socket support TIPC. Message-ID: <1199719444.64.0.922662021961.issue1646@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8981/0002-Make-socket-support-TIPC.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 16:24:04 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 15:24:04 -0000 Subject: [issue1754] WindowsError messages are not properly encoded Message-ID: <1199719444.23.0.800770205049.issue1754@psf.upfronthosting.co.za> Guido van Rossum added the comment: Crys, can you confirm this? It would seem we'll need to fix this twice -- once for 2.x, once for 3.0. ---------- nosy: +gvanrossum, tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 16:27:44 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 15:27:44 -0000 Subject: [issue1752] logging.basicConfig misleading behaviour Message-ID: <1199719664.6.0.389169211734.issue1752@psf.upfronthosting.co.za> Guido van Rossum added the comment: I recall being bitten by this too when first trying to use the logging module. I think the behavior is intentional, but I suppose it could be documented better. ---------- assignee: -> vsajip nosy: +gvanrossum, vsajip priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 16:31:20 2008 From: report at bugs.python.org (Alan McIntyre) Date: Mon, 07 Jan 2008 15:31:20 -0000 Subject: [issue1011893] Problems importing packages in ZIP file Message-ID: <1199719880.4.0.778816603555.issue1011893@psf.upfronthosting.co.za> Alan McIntyre added the comment: I just tried it on 2.5 and 2.6, since I didn't have the earlier versions available. If I find some time I'll see if I can try it on 2.3 & 2.4; maybe that will shed some light on whether it's been fixed or if is something specific to Windows that could still be broken. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 16:32:30 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2008 15:32:30 -0000 Subject: [issue1754] WindowsError messages are not properly encoded Message-ID: <1199719950.97.0.312782589343.issue1754@psf.upfronthosting.co.za> Christian Heimes added the comment: Oh nice ... Amaury knows probably more about the wide char Windows API than me. The function Python/error.c:PyErr_SetExcFromWindows*() needs to be modified. ---------- assignee: -> amaury.forgeotdarc nosy: +amaury.forgeotdarc priority: -> normal versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 16:35:44 2008 From: report at bugs.python.org (Dariusz Suchojad) Date: Mon, 07 Jan 2008 15:35:44 -0000 Subject: [issue1737] Windows installer issue (ObjectBrowser.py) Message-ID: <1199720144.64.0.411451580592.issue1737@psf.upfronthosting.co.za> Dariusz Suchojad added the comment: Hmm, on a home PC the checksum's correct, it's a1d1a9c07bc4c78bd8fa05dd3efec87f. Assuming something is wrong with my download at work, is it possible for an MSI package to start the installation even when package is corrupted? Anyway, tomorrow I'll try to install the MSI I downloaded at home. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 16:36:40 2008 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 07 Jan 2008 15:36:40 -0000 Subject: [issue1752] logging.basicConfig misleading behaviour Message-ID: <1199720200.25.0.805586282463.issue1752@psf.upfronthosting.co.za> Vinay Sajip added the comment: Added clarifying sentence to documentation (trunk only): "The function does nothing if any handlers have been defined for the root logger." ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 16:37:16 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 07 Jan 2008 15:37:16 -0000 Subject: [issue1754] WindowsError messages are not properly encoded Message-ID: <1199720236.96.0.297103817098.issue1754@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I confirm the problem (with French accents) on python 2.5. Python 3.0 already fixed the problem by using the FormatMessageW() unicode version of the API. We could do the same for python 2.5, but the error message must be converted to str early (i.e when building the Exception). What is the correct encoding to use? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 16:37:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2008 15:37:54 -0000 Subject: [issue1646] Make socket support TIPC. Message-ID: <1199720274.37.0.70587010849.issue1646@psf.upfronthosting.co.za> Christian Heimes added the comment: The unit tests don't work for me (Ubuntu 7.10, Linux 2.6.22, i386) >>> srv = socket.socket(socket.AF_TIPC, socket.SOCK_RDM) Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/trunk/Lib/socket.py", line 177, in __init__ _sock = _realsocket(family, type, proto) socket.error: [Errno 97] Address family not supported by protocol Do I have to set up my network device for TIPC? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 16:49:22 2008 From: report at bugs.python.org (Facundo Batista) Date: Mon, 07 Jan 2008 15:49:22 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1199720962.02.0.864893404377.issue1182@psf.upfronthosting.co.za> Facundo Batista added the comment: Mmm... I thought this would be a clean backport... but no. If we just copy the files to 2.5, we get two failures running the tests. - test_hash_method (DecimalUsabilityTest): This is because of the changes we made to the hash builtin in the trunk, and we should avoid this test if version < 2.6. - test_normalize: Exception "Clamped" raised on line nrmx218. I don't have a clue why this one fails. Mark, could you please take a look at it? Thank you! __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 17:04:49 2008 From: report at bugs.python.org (Alberto Bertogli) Date: Mon, 07 Jan 2008 16:04:49 -0000 Subject: [issue1646] Make socket support TIPC. In-Reply-To: <1199720274.37.0.70587010849.issue1646@psf.upfronthosting.co.za> Message-ID: <20080107160404.GN18632@gmail.com> Alberto Bertogli added the comment: On Mon, Jan 07, 2008 at 03:37:54PM -0000, Christian Heimes wrote: > The unit tests don't work for me (Ubuntu 7.10, Linux 2.6.22, i386) > > >>> srv = socket.socket(socket.AF_TIPC, socket.SOCK_RDM) > Traceback (most recent call last): > File "", line 1, in > File "/home/heimes/dev/python/trunk/Lib/socket.py", line 177, in __init__ > _sock = _realsocket(family, type, proto) > socket.error: [Errno 97] Address family not supported by protocol > > Do I have to set up my network device for TIPC? No, by default you have a single-node cluster fully capable of TIPC networking. But you do need the TIPC module loaded; have you tried modprobe tipc? If that works, the test cases should pass. I understand that this might be a problem because there is no time to check at runtime if you have TIPC enabled in your kernel (besides the obvious way of trying to create the socket and see if it fails); but you have the same problem with any network protocol (although obviously is much more common to have TIPC disabled than the rest of the supported ones). Do you want me to check for this in the conditional for inclusion? Thanks, Alberto __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 17:19:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2008 16:19:10 -0000 Subject: [issue1646] Make socket support TIPC. Message-ID: <1199722750.38.0.713890954068.issue1646@psf.upfronthosting.co.za> Christian Heimes added the comment: Committed in r59819 ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 17:19:14 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 16:19:14 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199722754.76.0.399229487757.issue1751@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: So, here's one big patch. I have updated the behavior of close(), so that > The profile tests often fail when io.py changes because they happen to > depend on "golden output" which includes line numbers of code in io.py > that happens to be traced during the test. Yes, I knew that. But, how can I fix the test so that it passes even if _bytesio is not available? Oh, one more thing. In the misc fixes for io.py, I added a checkClosed in IOBase.readline(). As a side-effect, this make __next__ raises a ValueError, instead of StopIteration. Is that correct? >>> f = open("load.py") [45681 refs] >>> next(f) 'import sys\n' [45700 refs] >>> f.close() [45703 refs] >>> next(f) Traceback (most recent call last): File "", line 1, in File "/home/alex/src/python.org/py3k/Lib/io.py", line 1440, in __next__ line = self.readline() File "/home/alex/src/python.org/py3k/Lib/io.py", line 1449, in readline raise ValueError("read from closed file") ValueError: read from closed file [45703 refs] Added file: http://bugs.python.org/file9096/bytesio+misc-fixes.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 17:21:44 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 16:21:44 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199722904.18.0.989966041447.issue1751@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: [grrr, I eat my words] > So, here's one big patch. I have updated the behavior of close(), so that ... it matches the behavior of 2.x. > As a side-effect, this make __next__ raises a ValueError, instead of StopIteration. ... when the file is closed. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 17:21:45 2008 From: report at bugs.python.org (Romulo A. Ceccon) Date: Mon, 07 Jan 2008 16:21:45 -0000 Subject: [issue1754] WindowsError messages are not properly encoded Message-ID: <1199722905.59.0.255010615534.issue1754@psf.upfronthosting.co.za> Romulo A. Ceccon added the comment: "... but the error message must be converted to str early (i.e when building the Exception)." Wouldn't that create more problems? What if somebody wants to intercept the exception and do something with it, like, say, redirect it to a log file? The programmer must, then, be aware of the different encoding. I thought about keeping the exception message in Unicode and converting it just before printing. Is that possible for Python 2.x? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 17:42:13 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 16:42:13 -0000 Subject: [issue1755] Misspelling in future.c in 2.5.1 source (handl should be handle) Message-ID: <1199724133.36.0.166010031998.issue1755@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r59820. ---------- nosy: +georg.brandl resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 17:42:51 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 16:42:51 -0000 Subject: [issue1748] contextlib.contextmanager does not use functools.wraps Message-ID: <1199724171.3.0.953874276929.issue1748@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- priority: -> low type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 17:43:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 16:43:07 -0000 Subject: [issue1753] TextIOWrapper.write writes utf BOM for every string Message-ID: <1199724187.42.0.463537353008.issue1753@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- priority: normal -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 17:49:48 2008 From: report at bugs.python.org (Facundo Batista) Date: Mon, 07 Jan 2008 16:49:48 -0000 Subject: [issue1755179] Deadlocks with fork() and multithreading Message-ID: <1199724588.88.0.0538912586766.issue1755179@psf.upfronthosting.co.za> Facundo Batista added the comment: Backported, commited in r59823. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 17:57:06 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2008 16:57:06 -0000 Subject: [issue1762972] 'exec' does not accept what 'open' returns Message-ID: <1199725026.5.0.287062347738.issue1762972@psf.upfronthosting.co.za> Christian Heimes added the comment: both sounds like a good idea. ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 18:09:48 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 17:09:48 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1199725788.06.0.124527396293.issue602345@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed r59824. ---------- status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 18:14:40 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2008 17:14:40 -0000 Subject: [issue1762972] 'exec' does not accept what 'open' returns Message-ID: <1199726080.59.0.0310804368703.issue1762972@psf.upfronthosting.co.za> Christian Heimes added the comment: I've readded reload() as imp.reload() in r59825. I've also copied two unit tests from trunk to py3k. ---------- resolution: -> accepted _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 18:26:36 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 17:26:36 -0000 Subject: [issue1668] -E command line parameter intent Message-ID: <1199726796.29.0.886230969888.issue1668@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed getenv.2.diff and extended envvar docs in r59827. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 18:28:05 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 17:28:05 -0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 Message-ID: <1199726885.17.0.278273233812.issue1745@psf.upfronthosting.co.za> Georg Brandl added the comment: Keyword-only-args are not yet documented. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 18:45:42 2008 From: report at bugs.python.org (Alan McIntyre) Date: Mon, 07 Jan 2008 17:45:42 -0000 Subject: [issue1622] zipfile hangs on certain zip files Message-ID: <1199727942.7.0.842794405063.issue1622@psf.upfronthosting.co.za> Alan McIntyre added the comment: Well I can't promise it will be swift, since my winter vacation ended today, but I'll keep on top of it as best I can. :) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 19:17:20 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 18:17:20 -0000 Subject: [issue919614] Python configured with --disable-unicode fails tests, more Message-ID: <1199729840.8.0.905960766254.issue919614@psf.upfronthosting.co.za> Georg Brandl added the comment: I renamed --enable-unicode to --with-wide-unicode in r59829; this should handle the Py3k case. I added suitable Py_USING_UNICODE directives in r59830 so that the trunk compiles again without unicode. ---------- assignee: -> gvanrossum nosy: +georg.brandl, gvanrossum resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 19:18:54 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 07 Jan 2008 18:18:54 -0000 Subject: [issue1754] WindowsError messages are not properly encoded Message-ID: <1199729934.87.0.0247510023221.issue1754@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I think this is not possible if we want to preserve compatibility; at least, str(e.strerror) must not fail. I can see different solutions: 1) Don't fix, and upgrade to python 3.0 2) Store an additional e.unicodeerror member, use it in a new EnvironmentError.__unicode__ method, and call this from PyErr_Display. 3) Force FormatMessage to return US-English messages. My preferred being 1): python2.5 is mostly encoding-naive, python3 is unicode aware, and I am not sure we want python2.6 contain both code. Other opinions? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 19:32:25 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 18:32:25 -0000 Subject: [issue1753] TextIOWrapper.write writes utf BOM for every string Message-ID: <1199730745.64.0.344884599615.issue1753@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Committed fix in r59832. Thanks! P.S. Guido, what this comment, in write(), is about? # XXX What if we were just reading? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 19:32:34 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 18:32:34 -0000 Subject: [issue1753] TextIOWrapper.write writes utf BOM for every string Message-ID: <1199730754.27.0.330156334679.issue1753@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: ---------- resolution: -> fixed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 19:32:38 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 18:32:38 -0000 Subject: [issue1753] TextIOWrapper.write writes utf BOM for every string Message-ID: <1199730758.57.0.657317664622.issue1753@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 19:38:33 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 18:38:33 -0000 Subject: [issue1754] WindowsError messages are not properly encoded Message-ID: <1199731113.03.0.756403367046.issue1754@psf.upfronthosting.co.za> Guido van Rossum added the comment: 3.0 will be a long way away for many users. Perhaps forcing English isn't so bad, as Python's own error messages aren't translated anyway? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 19:49:13 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 07 Jan 2008 18:49:13 -0000 Subject: [issue1540385] tarfile __slots__ addition Message-ID: <1199731753.89.0.177297771294.issue1540385@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I close this issue as there has been no progress over the last 1.5 year. ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 19:49:58 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 18:49:58 -0000 Subject: [issue467924] Improve the ZipFile Interface Message-ID: <1199731798.13.0.478769600234.issue467924@psf.upfronthosting.co.za> Georg Brandl added the comment: I committed your patch (after reviewing the docs) as r59834. I think there is no more to do here. ---------- resolution: -> accepted status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 19:55:06 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 07 Jan 2008 18:55:06 -0000 Subject: [issue1527974] tarfile chokes on ipython archive on Windows Message-ID: <1199732106.58.0.818827956954.issue1527974@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I close this issue because it is out of date. The new TarFile.extractall() method in Python 2.5 provides a way to solve the original problem IMO. ---------- resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 19:58:02 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 18:58:02 -0000 Subject: [issue1756] -m broken in trunk Message-ID: <1199732282.41.0.0565875093143.issue1756@psf.upfronthosting.co.za> New submission from Guido van Rossum: As of today, the -m option doesn't appear to work any more in the trunk. I get this error: $ ./python -m string Could not import runpy module $ However it seems to be confused: $ ./python -c 'import runpy' $ IOW the module imports just fine. Crys, I wonder if this has to do with your import-nolock changes? ---------- assignee: tiran messages: 59478 nosy: gvanrossum, tiran priority: urgent severity: normal status: open title: -m broken in trunk versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 19:59:03 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 18:59:03 -0000 Subject: [issue1756] -m broken in trunk Message-ID: <1199732343.73.0.21112337097.issue1756@psf.upfronthosting.co.za> Georg Brandl added the comment: Seems to work here... ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 20:09:37 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 19:09:37 -0000 Subject: [issue1756] -m broken in trunk Message-ID: <1199732977.6.0.887108562689.issue1756@psf.upfronthosting.co.za> Guido van Rossum added the comment: Bah. Environment error. Sorry! ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 20:12:04 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 Jan 2008 19:12:04 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199733124.39.0.804226894515.issue932563@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi Vinay, Thanks for your reply. I think it's important to rephrase the problem in a simple way. The basic pattern is that there is a class C (say, a TCP connection class) where a specific part of each log line should from an instance-specific "contextual string" (say, an IP address). Given the current logging API, this means each instance of C will want either a separate Logger object, or a separate Formatter object, or a separate LogRecord subclass, etc. Now the problem is: 1. creating a separate Logger object per instance of C leads to memory leaks 2. creating a separate Formatter, Filter etc. does not work because the shared logger (whatever it is) has no means to decide which Formatter or Filter instance it should use depending on the caller (perhaps I'm wrong about this one? explanations welcome :-)) 3. creating thread-local objects (e.g. Formatters), not only is a quite ugly solution IMO, but it doesn't suit every situation. For example, if you use an event loop (asyncore, Twisted), all objects will live in the same thread yet require distinct Formatters. So the only mildly satisfying solution right now is: 4. create a specific Logger class wrapper which will require the caller to pass its "contextual string" to them so that the wrapper has the appropriate context information. This does almost the right thing (except for one supplementary parameter for each logging call), but is still a bit of code to type and get right. Now to make it easier for the developer I see two solutions: A. enhance the logging module with an API to create non-persistent loggers. That's what I was originally proposing to work on. B. provide a generic implementation of the afore-mentioned wrapper (see solution 4), ready to use for the most common purposes. Basically, the generic wrapper would be instantiated with a pattern (say : "1.2.3.4: %(msg)s") which would be used to modify the msg for each logger call I'd be willing to implement either of those two solutions, depending on which we decide is better :-) What do you think? ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 20:17:36 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 19:17:36 -0000 Subject: [issue1734] documentation on metaclasses is incomplete and misleading Message-ID: <1199733456.19.0.386776427046.issue1734@psf.upfronthosting.co.za> Georg Brandl added the comment: This should now be appropriately explained in the trunk, r59837. I also added an example of using __new__ in a metaclass. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 20:22:10 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2008 19:22:10 -0000 Subject: [issue1722] Undocumented urllib functions Message-ID: <1199733730.78.0.524451191239.issue1722@psf.upfronthosting.co.za> Georg Brandl added the comment: There are quite a lot more functions in __all__, more than 10 split* functions... should they all be documented? Also, isn't urlparse meant to do such tasks? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 21:19:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2008 20:19:31 -0000 Subject: [issue1762972] 'exec' does not accept what 'open' returns Message-ID: <1199737171.82.0.425890829324.issue1762972@psf.upfronthosting.co.za> Christian Heimes added the comment: I've added the __file__ patch in r59841. Is there another location that needs to be fixed? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 21:37:52 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 20:37:52 -0000 Subject: [issue1762972] 'exec' does not accept what 'open' returns Message-ID: <1199738272.63.0.380007056529.issue1762972@psf.upfronthosting.co.za> Guido van Rossum added the comment: Maybe just a doc update? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 21:39:17 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2008 20:39:17 -0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module Message-ID: <1199738357.31.0.969908162026.issue1657@psf.upfronthosting.co.za> Christian Heimes added the comment: Guido, have you reviewed the patch and are you fine with it? ---------- components: +Extension Modules nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 21:43:01 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2008 20:43:01 -0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module Message-ID: <1199738581.57.0.936226165617.issue1657@psf.upfronthosting.co.za> Guido van Rossum added the comment: Not yet, I ran out of time. Can you hold on for another week? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 21:52:46 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Jan 2008 20:52:46 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1199739166.07.0.962145902167.issue1182@psf.upfronthosting.co.za> Mark Dickinson added the comment: You need to remove the old files in decimaltestdata before copying the new ones across: nrmx218 is an old, and buggy, testcase; at some point Mike Cowlishaw renamed normalize.decTest to reduce.decTest. He also renamed the operation from normalize to reduce, but since this name change hasn't made it into the most recent version of the specification it's stayed as normalize in the Python source for now. So it looks like you ended up with an old version of normalize.decTest in addition to all the new decTest files. Note that redx218 in reduce.decTest is identical to nrmx218, except that it specifies that Clamped *should* be raised. For the hash method, I think it's safe to leave the old Python 2.5 __hash__ exactly as it is, but backport everything else. This means that hash will still be slow for large Decimals in Python 2.5 (i.e., we won't be able to backport the fix for issue 1770416 in Python 2.5), but at least it'll be correct. If we backport the new __hash__ without also backporting the corresponding core change to the long __hash__ then we'll be left with a buggy __hash__. The new tests for __hash__ are still valid, and I think they shouldn't be skipped in the backported version. And I definitely don't want to suggest backporting the long.__hash__ change---that just seems to be asking for trouble. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 21:58:34 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Jan 2008 20:58:34 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1199739514.01.0.802299398293.issue1182@psf.upfronthosting.co.za> Mark Dickinson added the comment: P.S. I've just noticed that both versions of __hash__ are buggy: the hash value of a Decimal depends on the current context. I'll open a new bug report. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:00:22 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 07 Jan 2008 21:00:22 -0000 Subject: [issue1754] WindowsError messages are not properly encoded Message-ID: <1199739622.34.0.813507345446.issue1754@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I would claim that this is not a bug. Sure, the message doesn't come out correctly, but only because you run it in a cmd.exe window, not in (say) IDLE. IIUC, the problem is that Python computes the message in CP_ACP (i.e. the ANSI code page), whereas the terminal interprets it in CP_OEMCP (i.e. the OEM code page). If we declare that all strings are considered as CP_ACP in the exception, then the only way to fix it would be to convert it from CP_ACP to CP_OEMCP (or, more generally, sys.stderr.encoding) on printing. Such conversion should be implemented in an unfailing way, either using replacement characters or falling back to no conversion. Forcing English messages would certainly reduce the problems, but it still might be that the file name in the error message does not come out correctly. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:03:33 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 07 Jan 2008 21:03:33 -0000 Subject: [issue1737] Windows installer issue (ObjectBrowser.py) Message-ID: <1199739812.98.0.341618122616.issue1737@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I can confirm that the correct checksum of the file is what the web page says. So it seems that your web browser corrected it during the download. That, typically, is caused by the web browser perform a conversion of line endings in a binary file, so it would indeed be best if you try with a different copy, or a different web browser. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:03:58 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Jan 2008 21:03:58 -0000 Subject: [issue1757] Decimal hash depends on current context Message-ID: <1199739838.21.0.114210159125.issue1757@psf.upfronthosting.co.za> New submission from Mark Dickinson: The value of the Decimal hash() depends on the current context: >>> from decimal import * >>> x = Decimal("123456789.1") >>> hash(x) 1989332493 >>> getcontext().prec = 6 >>> hash(x) -2034270682 This has nasty consequences; e.g.: >>> s = set([x]) >>> x in s True >>> getcontext().prec = 28 >>> x in s False hashing a Decimal can also set flags in the context; again, I think this is undesirable. The cause of this bug is clear: __hash__ calls normalize, which rounds its argument to the current context. I'll post a fix when I get around to it. ---------- components: Library (Lib) messages: 59492 nosy: marketdickinson severity: normal status: open title: Decimal hash depends on current context versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:06:42 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2008 21:06:42 -0000 Subject: [issue1737] Windows installer issue (ObjectBrowser.py) Message-ID: <1199740002.92.0.235919314484.issue1737@psf.upfronthosting.co.za> Christian Heimes added the comment: "your web browser corrected it"? Do you mean "corrupted"? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:09:36 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 07 Jan 2008 21:09:36 -0000 Subject: [issue1137] pyexpat patch for changing buffer_size Message-ID: <1199740176.13.0.471034346069.issue1137@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Here's a simpler, but still untested version of the patch that cuts out the various cases for reallocating when there's already buffered data and just does a flush every time. Added file: http://bugs.python.org/file9097/simpler_patch.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:27:41 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 07 Jan 2008 21:27:41 -0000 Subject: [issue1754] WindowsError messages are not properly encoded Message-ID: <1199741261.88.0.615181544603.issue1754@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > Forcing English messages would certainly reduce the problems And it does not even work: my French Windows XP does not contain the English error messages :-( > If we declare that all strings are considered as CP_ACP in the > exception, then the only way to fix it would be to convert it from > CP_ACP to CP_OEMCP (or, more generally, sys.stderr.encoding) on > printing. Such conversion should be implemented in an unfailing way, > either using replacement characters or falling back to no conversion. If this is chosen, I propose to use CharToOem as the "unfailing" conversion function. I will try to come with a patch following this idea. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:31:20 2008 From: report at bugs.python.org (Facundo Batista) Date: Mon, 07 Jan 2008 21:31:20 -0000 Subject: [issue1757] Decimal hash depends on current context Message-ID: <1199741480.84.0.658923825359.issue1757@psf.upfronthosting.co.za> Changes by Facundo Batista: ---------- assignee: -> facundobatista nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:33:52 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Jan 2008 21:33:52 -0000 Subject: [issue1623] Implement PEP-3141 for Decimal Message-ID: <1199741632.71.0.350216146366.issue1623@psf.upfronthosting.co.za> Mark Dickinson added the comment: One minor point: Decimals are also created by the _dec_from_triple function: presumably that call to __new__ should also be changed to use super? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:36:28 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 07 Jan 2008 21:36:28 -0000 Subject: [issue1137] pyexpat patch for changing buffer_size Message-ID: <1199741788.07.0.759956838825.issue1137@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Here's another update of the simplified version, that also updated the documentation patch for reST and updates the test for the current code. Added file: http://bugs.python.org/file9098/pyexpat-patch2.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:36:57 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 07 Jan 2008 21:36:57 -0000 Subject: [issue1754] WindowsError messages are not properly encoded In-Reply-To: <1199741261.88.0.615181544603.issue1754@psf.upfronthosting.co.za> Message-ID: <47829B76.5010105@v.loewis.de> Martin v. L?wis added the comment: > If this is chosen, I propose to use CharToOem as the "unfailing" > conversion function. I will try to come with a patch following this idea. Sounds fine to me. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 22:46:26 2008 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 07 Jan 2008 21:46:26 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199742386.92.0.727727059711.issue932563@psf.upfronthosting.co.za> Vinay Sajip added the comment: Ok, but let's continue the discussion on comp.lang.python, as this is probably not the best place for an extended discussion. I'll post there soon with a proposal. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 22:52:27 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Mon, 07 Jan 2008 21:52:27 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199742747.56.0.566024262305.issue932563@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Please be sure to post a link to the thread here, as not everyone here reads comp.lang.python. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 7 23:14:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 Jan 2008 22:14:35 -0000 Subject: [issue1766304] improve xrange.__contains__ Message-ID: <1199744075.51.0.778637882879.issue1766304@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The 2.6 patch should probably use long instead of int. ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 7 23:20:47 2008 From: report at bugs.python.org (Martin Marcher) Date: Mon, 07 Jan 2008 22:20:47 -0000 Subject: [issue1758] Wrong link in documentation Message-ID: <1199744447.77.0.771714007118.issue1758@psf.upfronthosting.co.za> New submission from Martin Marcher: In this site: http://www.python.org/doc/current/inst/about.html under "Comments and Questions" the link to the python bugtracker is still pointing to the sourceforge bugtracker. ---------- components: Documentation messages: 59502 nosy: martin.marcher severity: normal status: open title: Wrong link in documentation type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 23:22:31 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 22:22:31 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199744551.94.0.604389882842.issue1751@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I got a patch that also fixes the profiler tests. That was easy after all. :-) Added file: http://bugs.python.org/file9099/bytesio+misc-fixes-2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 23:22:53 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 07 Jan 2008 22:22:53 -0000 Subject: [issue1751] Fast BytesIO implementation + misc changes Message-ID: <1199744573.04.0.37182563436.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: Removed file: http://bugs.python.org/file9096/bytesio+misc-fixes.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 23:44:07 2008 From: report at bugs.python.org (Robert Lehmann) Date: Mon, 07 Jan 2008 22:44:07 -0000 Subject: [issue1758] Wrong link in documentation Message-ID: <1199745847.2.0.0559209052254.issue1758@psf.upfronthosting.co.za> Robert Lehmann added the comment: This problem has been removed in the current version of the documentation (http://docs.python.org/dev/install/index.html) -- old docs aren't updated. It has an own section now (http://docs.python.org/dev/bugs.html). Issue can be closed. ---------- nosy: +lehmannro __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 7 23:48:22 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 07 Jan 2008 22:48:22 -0000 Subject: [issue1758] Wrong link in documentation Message-ID: <1199746102.18.0.79383399261.issue1758@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the report. I just fixed it in r59848; this will be released with Python 2.5.2. "old" docs *will* be updated for 2.5.x. ---------- nosy: +loewis resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 00:18:56 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 Jan 2008 23:18:56 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199747936.37.0.764093860548.issue932563@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't follow comp.lang.python either, so I'd be grateful if you give a link to the gmane thread ;) I hope we can find an useful solution to this limitation, logging is a very important task and the stdlib should satisfy all common wishes IMO. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Jan 8 00:59:27 2008 From: report at bugs.python.org (Joakim) Date: Mon, 07 Jan 2008 23:59:27 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199750367.88.0.387844286277.issue1743@psf.upfronthosting.co.za> Joakim added the comment: I have the exact same problem also running 32-bit vista. Idle worked the first time I started it but after that it doesn't start. I did run the command and got this error. C:\Users\Joakim>"C:\Python25\python.exe" "C:\Python25\Lib\idle.py" C:\Python25\python.exe: can't open file 'C:\Python25\Lib\idle.py': [Errno 2] No such file or directory I also not able to start the interpreter from cmd using the python command. I've looked around a bit and read something about adding to PATH. Haven't tried that because the guide wasn't written for Vista. ---------- nosy: +Piffen __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 01:11:39 2008 From: report at bugs.python.org (Michael Van Biesbrouck) Date: Tue, 08 Jan 2008 00:11:39 -0000 Subject: [issue1515] deepcopy doesn't copy instance methods Message-ID: <1199751099.04.0.234369996262.issue1515@psf.upfronthosting.co.za> Michael Van Biesbrouck added the comment: Guido pointed out a common use case where people use bound methods in a way that would be poorly served by my change. An alternate implementation with a deeper copy will cause less surprise: def _deepcopy_method(x, memo): return type(x)(x.im_func, deepcopy(x.im_self, memo), x.im_class) d[types.MethodType] = _deepcopy_method The function and class are still shallow-copied but the bound object is deep-copied. I use type(x)() instead of types.MethodType() because types will be unbound when the function runs. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 01:16:35 2008 From: report at bugs.python.org (Joakim) Date: Tue, 08 Jan 2008 00:16:35 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199751395.42.0.136567381562.issue1743@psf.upfronthosting.co.za> Joakim added the comment: Noticed I missed a bit of the path but it didn't matter. Changed the path to C:\Python25\Lib\idlelib\idle.py and got another error. C:\Users\Joakim>"C:\Python25\python.exe" "C:\Python25 \Lib\idlelib\idle.py" Traceback (most recent call last): File "C:\Python25\Lib\idlelib\idle.py", line 21, in idlelib.PyShell.main() File "C:\Python25\lib\idlelib\PyShell.py", line 1404, in main shell = flist.open_shell() File "C:\Python25\lib\idlelib\PyShell.py", line 275, in open_shell self.pyshell = PyShell(self) File "C:\Python25\lib\idlelib\PyShell.py", line 813, in __init__ OutputWindow.__init__(self, flist, None, None) File "C:\Python25\lib\idlelib\OutputWindow.py", line 16, in __init__ EditorWindow.__init__(self, *args) File "C:\Python25\lib\idlelib\EditorWindow.py", line 248, in __init__ self.update_recent_files_list() File "C:\Python25\lib\idlelib\EditorWindow.py", line 715, in update_recent_fil es_list rf_file = open(self.recent_files_path, 'w') IOError: [Errno 13] Permission denied: 'C:\\Users\\Joakim\\.idlerc\\recent-files .lst' There should be a edit button somewhere but I couldn't find it, so I had to post a new entry. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 01:21:23 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 00:21:23 -0000 Subject: [issue1757] Decimal hash depends on current context Message-ID: <1199751683.54.0.844415170784.issue1757@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 01:23:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 00:23:03 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199751783.63.0.408779879097.issue1743@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you access the file C:\\Users\\Joakim\\.idlerc\\recent-files.lst with the explorer? Do the directory and the file exist? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 01:26:38 2008 From: report at bugs.python.org (Joakim) Date: Tue, 08 Jan 2008 00:26:38 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199751998.34.0.938966748694.issue1743@psf.upfronthosting.co.za> Joakim added the comment: I can access the file. I renamed the file and tried the command again. Then I started IDLE and got a window. A new recent-files.lst was created. So I guess I solved the problem temporarily. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 01:42:30 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 08 Jan 2008 00:42:30 -0000 Subject: [issue1754] WindowsError messages are not properly encoded Message-ID: <1199752950.78.0.133033481657.issue1754@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Here is a patch. Now I feel it is a hack, but it is the only place I found where I can access both the exception object and the encoding... Added file: http://bugs.python.org/file9100/windowserror.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 01:50:11 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 00:50:11 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199753411.09.0.651457141005.issue1743@psf.upfronthosting.co.za> Christian Heimes added the comment: It smells like a Vista issue. But IDLE shouldn't crash w/o a notice if the recent list can't be opened. ---------- assignee: -> kbk nosy: +kbk priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 02:12:50 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 08 Jan 2008 01:12:50 -0000 Subject: [issue1757] Decimal hash depends on current context Message-ID: <1199754770.25.0.293904344385.issue1757@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a patch for the trunk. Added file: http://bugs.python.org/file9101/issue1757.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 02:31:11 2008 From: report at bugs.python.org (Robin Stocker) Date: Tue, 08 Jan 2008 01:31:11 -0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 Message-ID: <1199755871.02.0.596024702192.issue1745@psf.upfronthosting.co.za> Robin Stocker added the comment: Thanks for the feedback! It's on line 111 in test_collections.py:: n = 10000 import string, random names = [''.join([random.choice(string.letters) for j in range(10)]) for i in range(n)] Big = namedtuple('Big', names) b = Big(*range(n)) I think the condition is triggered because Big's __new__ (which seems to be dynamically generated by namedtuple using exec) has an argument list with 10000 arguments. Ok, I'm now looking through SVN logs and have already added some more changes to my patchset. Thanks, I had changed MAGIC but didn't know that marshal.c uses it. So I won't handle documentation in this issue then. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 03:30:53 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 08 Jan 2008 02:30:53 -0000 Subject: [issue1623] Implement PEP-3141 for Decimal Message-ID: <1199759453.71.0.975990532657.issue1623@psf.upfronthosting.co.za> Mark Dickinson added the comment: Some more comments: (1) I don't think I understand the mechanism by which __lt__ and __le__ are supposed to be called. For example, by adding a few print statements it seems that the comparison Decimal(2) > 3 doesn't call __lt__ at any stage. Is this what's expected, or is this unintended? (2) Also on the subject of __le__ and __lt__: if Decimal is going to have rich comparisons (and I guess it is, one way or another :) ) then we might as well get them right for NaNs: IEEE-754(r) says that any comparison involving NaN should return False, with the exception of != which should always return True. With 3-way comparison it wasn't possible to get this right. This would fix Issue 1514428. (Further discussion of this should probably go there---I don't think it should hold up applying this patch...) (3) I'm getting a serious performance hit from this patch: a complete run of test_decimal.py costs me 22.439 seconds (best of 3) with the patch, and 11.604 seconds without. I'm not sure where this is coming from---perhaps it's unavoidable. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 03:35:45 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 08 Jan 2008 02:35:45 -0000 Subject: [issue1514428] NaN comparison in Decimal broken Message-ID: <1199759745.5.0.151328923023.issue1514428@psf.upfronthosting.co.za> Mark Dickinson added the comment: It seems likely that Decimal is going to grow rich comparisons anyway, either as a result of PEP 3141 or as a result of removal of __cmp__. Given this, would there be any objections to making comparisons do the right thing (in the sense of IEEE-754) for NaNs? ---------- nosy: +marketdickinson _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 8 03:42:32 2008 From: report at bugs.python.org (Senthil) Date: Tue, 08 Jan 2008 02:42:32 -0000 Subject: [issue1698] urlparse and usernames containing @ Message-ID: <1199760152.11.0.988037457188.issue1698@psf.upfronthosting.co.za> Senthil added the comment: Thank you, Yes having it in the 2.5.2 would be a good idea. The bug report is also on 2.5 only. I have attached the patch for the release25-maint branch. Thanks, Senthil Added file: http://bugs.python.org/file9102/issue6898-r25-maint.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 03:45:03 2008 From: report at bugs.python.org (Senthil) Date: Tue, 08 Jan 2008 02:45:03 -0000 Subject: [issue1698] urlparse and usernames containing @ Message-ID: <1199760303.64.0.355202510435.issue1698@psf.upfronthosting.co.za> Senthil added the comment: The patch against the trunk could also have been applied to 2.5. There is NO change in the trunk and 2.4-maint patch. Thanks, Senthil __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 04:44:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 03:44:29 -0000 Subject: [issue1759] Backport of PEP 3129 "class decorators" Message-ID: <1199763869.09.0.792337356327.issue1759@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch backports the class decorator syntax to 2.6. All tests except two are passing. I'm not sure why the inspect test fails and I don't know how to fix the ast test. ---------- components: Interpreter Core files: trunk_pep3129_classdec.patch messages: 59520 nosy: tiran priority: normal severity: normal status: open title: Backport of PEP 3129 "class decorators" type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9103/trunk_pep3129_classdec.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 04:45:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 03:45:26 -0000 Subject: [issue1759] Backport of PEP 3129 "class decorators" Message-ID: <1199763926.41.0.356867294291.issue1759@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 04:55:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 03:55:18 -0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 Message-ID: <1199764518.14.0.0870299333527.issue1745@psf.upfronthosting.co.za> Christian Heimes added the comment: I vaguely remember that I had to modify the tests to use 254 args in Python 3.0. ---------- nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 05:53:56 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 08 Jan 2008 04:53:56 -0000 Subject: [issue1623] Implement PEP-3141 for Decimal Message-ID: <1199768036.43.0.443765097586.issue1623@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: _dec_from_triple: Probably, yes. It doesn't seem to have any practical effect, but it's good to be consistent. __lt__, __le__: It doesn't matter whether they're called because they have the same effect as __cmp__. They're only there to implement numbers.Real. Perhaps, though, this is a sign that numbers.Real should require __cmp__ instead in 2.6? Or all of the rich comparisons instead of just the two minimal ones? NaNs: I think the guideline is to keep the current behavior for 2.6, and it's not needed for the 3141 implementation, but if that issue comes to a conclusion before I get the 3.0 implementation submitted, I'm happy to follow it. Performance: cProfile points at abc.__instancecheck__ taking 20% of the total time (1132436 calls). This could be a problem... I'll check how that's changed (on my machine) from head and if I can fix it. Thanks for your detailed reviews, Mark! __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 06:01:34 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2008 05:01:34 -0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 Message-ID: <1199768494.24.0.443348638851.issue1745@psf.upfronthosting.co.za> Guido van Rossum added the comment: There's something I misunderstand then. I thought 2.x also didn't accept >255 args, but that test would seem to prove I'm wrong. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 09:12:04 2008 From: report at bugs.python.org (Dariusz Suchojad) Date: Tue, 08 Jan 2008 08:12:04 -0000 Subject: [issue1737] Windows installer issue (ObjectBrowser.py) Message-ID: <1199779924.33.0.115967223916.issue1737@psf.upfronthosting.co.za> Dariusz Suchojad added the comment: I think we can close the issue (although I seem not be able to do that). The installer works just fine now I've downloaded it using another browser. For future reference - the former one was Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071030 SeaMonkey/1.1.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 09:51:51 2008 From: report at bugs.python.org (Yinon Ehrlich) Date: Tue, 08 Jan 2008 08:51:51 -0000 Subject: [issue1760] PEP 341 is not reflected in the documentation Message-ID: <1199782311.05.0.0687645566121.issue1760@psf.upfronthosting.co.za> New submission from Yinon Ehrlich: Compare: http://docs.python.org/whatsnew/pep-341.html With: http://docs.python.org/ref/exceptions.html http://docs.python.org/tut/node10.html#SECTION0010300000000000000000 ---------- components: Documentation messages: 59525 nosy: Yinon severity: minor status: open title: PEP 341 is not reflected in the documentation type: rfe versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 10:22:02 2008 From: report at bugs.python.org (Ravon Jean-Michel) Date: Tue, 08 Jan 2008 09:22:02 -0000 Subject: [issue1761] Bug in re.sub() Message-ID: <1199784122.17.0.476084084614.issue1761@psf.upfronthosting.co.za> New submission from Ravon Jean-Michel: Here is my source: def truc (): line = ' hi \n' line1 = re.sub('$', 'hello', line) line2 = re.sub('$', 'you', line1) print line2 Here is what I get: >>> trace.truc() hi hello helloyou >>> ---------- components: Regular Expressions messages: 59526 nosy: jmravon severity: normal status: open title: Bug in re.sub() type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 10:24:14 2008 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 Jan 2008 09:24:14 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1199784254.88.0.938513958717.issue932563@psf.upfronthosting.co.za> Vinay Sajip added the comment: I've posted a proposal to python-list: you can view via http://groups.google.co.uk/group/comp.lang.python/browse_frm/thread/336eb031c85758fa or http://article.gmane.org/gmane.comp.python.general/553877 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Jan 8 10:54:56 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 08 Jan 2008 09:54:56 -0000 Subject: [issue1761] Bug in re.sub() Message-ID: <1199786096.66.0.487860408613.issue1761@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: In other words, if I understand correctly: >>> re.sub('$', '#', 'a\nb\nc') 'a\nb\nc#' >>> re.sub('$', '#', 'a\nb\n') 'a\nb#\n#' The first sample is correct, but the second one find two matches, even without the re.MULTILINE option. Is this normal? The docs say: > '$' Matches the end of the string or just before the newline at > the end of the string [...] It seems that it matches BOTH the end of the string AND just before the newline at the end of the string. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 11:47:09 2008 From: report at bugs.python.org (Titus Brown) Date: Tue, 08 Jan 2008 10:47:09 -0000 Subject: [issue1257] atexit errors should result in nonzero exit code Message-ID: <1199789229.6.0.152739423726.issue1257@psf.upfronthosting.co.za> Titus Brown added the comment: Please see GHOP patches by anders_v... at yahoo.se, http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=215 I've attached the Python 2.6 patch here. ---------- nosy: +titus Added file: http://bugs.python.org/file9104/ghop-215-py2.6-ctb.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 12:52:40 2008 From: report at bugs.python.org (Rich) Date: Tue, 08 Jan 2008 11:52:40 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199793160.16.0.915334727269.issue1743@psf.upfronthosting.co.za> Rich added the comment: I've been away for a couple of days, but can replicate everything Joakim has reported in my abscence. Deleting/renaming recent-files.lst allows me to launch IDLE (from cmd or Start Menu). Oddly though, if I close IDLE, copy/paste the contents of the old recent-files into the new one, and then restart IDLE, it still works. Another thing I noticed, after launching IDLE from the Command Prompt, is that I get this error (while IDLE is still running and I haven't done anything with it yet): Traceback (most recent call last): File "[...]\idlelib\run.py", line 82, in main exit() File "[...]\idlelib\run.py", line 208, in exit del sys.exitfunc AttributeError: exitfunc Is that normal? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 13:25:46 2008 From: report at bugs.python.org (Facundo Batista) Date: Tue, 08 Jan 2008 12:25:46 -0000 Subject: [issue1757] Decimal hash depends on current context Message-ID: <1199795146.78.0.147731859316.issue1757@psf.upfronthosting.co.za> Facundo Batista added the comment: Fixed in r59852. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 13:28:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 08 Jan 2008 12:28:01 -0000 Subject: [issue1761] Bug in re.sub() Message-ID: <1199795281.09.0.196664907459.issue1761@psf.upfronthosting.co.za> Georg Brandl added the comment: Fredrik? ---------- assignee: -> effbot nosy: +effbot, georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 13:34:59 2008 From: report at bugs.python.org (Fredrik Lundh) Date: Tue, 08 Jan 2008 12:34:59 -0000 Subject: [issue1761] Bug in re.sub() Message-ID: <1199795699.67.0.475851862578.issue1761@psf.upfronthosting.co.za> Fredrik Lundh added the comment: re.findall has the same behaviour. Without looking at the code, I'm not sure if this is a bug in the code or in the documentation, really. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 14:13:50 2008 From: report at bugs.python.org (Facundo Batista) Date: Tue, 08 Jan 2008 13:13:50 -0000 Subject: [issue1761] Bug in re.sub() Message-ID: <1199798030.09.0.711266200763.issue1761@psf.upfronthosting.co.za> Facundo Batista added the comment: As re provides regular expression matching operations similar to those found in Perl, I tried there to see what happens: """ use Data::Dumper; $a = 'a\nb\nc'; $a =~ s/$/#/; print Dumper($a); $a = 'a\nb\n'; $a =~ s/$/#/; print Dumper($a); """ $ perl pru_sub.pl $VAR1 = 'a\\nb\\nc#'; $VAR1 = 'a\\nb\\n#'; ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 14:34:28 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 08 Jan 2008 13:34:28 -0000 Subject: [issue1761] Bug in re.sub() Message-ID: <1199799268.86.0.989177609095.issue1761@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Careful, Perl strings must be double-quoted for \n to be understood as the newline character: """ use Data::Dumper; $a = "a\nb\nc"; $a =~ s/$/#/; print Dumper($a); $a = "a\nb\n"; $a =~ s/$/#/; print Dumper($a); """ And the output is: $VAR1 = 'a b c#'; $VAR1 = 'a b# '; Which is definitely different from python output. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 14:46:28 2008 From: report at bugs.python.org (Daniel Serodio) Date: Tue, 08 Jan 2008 13:46:28 -0000 Subject: [issue1124861] subprocess fails on GetStdHandle in interactive GUI Message-ID: <1199799988.04.0.120877689693.issue1124861@psf.upfronthosting.co.za> Daniel Serodio added the comment: I found this bug via this post: http://mail.python.org/pipermail/python-list/2007-April/436275.html And I think 2.5.1 still has this bug. I'm not familiar with Python bugtracker's "ettiquete", should I reopen this bug? ---------- nosy: +dserodio _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 8 15:06:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 08 Jan 2008 14:06:08 -0000 Subject: [issue1761] Bug in re.sub() Message-ID: <1199801168.3.0.827308702342.issue1761@psf.upfronthosting.co.za> Georg Brandl added the comment: At least, the docs for re.M are consistent with the current behavior. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 15:34:17 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 08 Jan 2008 14:34:17 -0000 Subject: [issue1137] pyexpat patch for changing buffer_size Message-ID: <1199802857.15.0.280759961472.issue1137@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Committed to the trunk in rev. 59853. AchimGaedke: thanks for your contribution! Also, please submit a signed copy of the contributor agreement when you can: see http://www.python.org/psf/contrib/ for details. ---------- resolution: -> accepted status: open -> closed versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 16:00:17 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 08 Jan 2008 15:00:17 -0000 Subject: [issue1114] _curses issues on 64-bit big-endian (e.g, AIX) Message-ID: <1199804417.85.0.855450068591.issue1114@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Applied to trunk in rev. 59854, and to 25-maint in rev. 59855. Thanks for your bugfix! ---------- resolution: -> accepted status: open -> closed versions: +Python 2.5, Python 2.6 -Python 2.3 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 17:18:20 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2008 16:18:20 -0000 Subject: [issue1761] Bug in re.sub() Message-ID: <1199809100.74.0.431110775892.issue1761@psf.upfronthosting.co.za> Guido van Rossum added the comment: So if the input ends in '\n', '$' matches both before and after that character, and two substitutions are made (even though multiline is not set). Seems a bug to me. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 17:21:37 2008 From: report at bugs.python.org (Facundo Batista) Date: Tue, 08 Jan 2008 16:21:37 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1199809297.55.0.872330343017.issue1182@psf.upfronthosting.co.za> Facundo Batista added the comment: Decimal was backported to Py2.5, commited in r59859. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 17:22:33 2008 From: report at bugs.python.org (Facundo Batista) Date: Tue, 08 Jan 2008 16:22:33 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1199809353.11.0.236182146256.issue1182@psf.upfronthosting.co.za> Changes by Facundo Batista: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 17:25:56 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 08 Jan 2008 16:25:56 -0000 Subject: [issue1623] Implement PEP-3141 for Decimal Message-ID: <1199809556.17.0.382046729374.issue1623@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Yes, making Decimal subclass object instead of Real and Inexact makes it as fast as it used to be. ABCMeta.__instancecheck__ is easy to speed up, but after fixing it, we're still about 25% behind. So here'a version that just registers Decimal as a subclass instead of having it inherit. I removed __le__ and __lt__ too, since, without subclassing numbers.Real, nothing requires them to exist, and the behavior's the same. Added file: http://bugs.python.org/file9105/decimal-3141-just-trunc-registered.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 17:39:10 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 08 Jan 2008 16:39:10 -0000 Subject: [issue1762] Inheriting from ABC slows Decimal down. Message-ID: <1199810349.91.0.976772037257.issue1762@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin: Adding numbers.Real to Decimal's base classes almost doubles the time its its test suite takes to run. A profile revealed that a large fraction of that slowdown was in __instancecheck__, but even after optimizing that, it's still about 25% slower. It looks like the rest of the slowdown is still in other parts of the isinstance() check. It would be nice if inheriting from ABCs didn't slow your class down. ---------- components: Library (Lib) messages: 59543 nosy: jyasskin, nnorwitz severity: normal status: open title: Inheriting from ABC slows Decimal down. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 17:41:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 16:41:34 -0000 Subject: [issue1762] Inheriting from ABC slows Decimal down. Message-ID: <1199810494.81.0.75102331263.issue1762@psf.upfronthosting.co.za> Christian Heimes added the comment: Is this for 2.6 or 3.0? ---------- nosy: +tiran priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 17:43:28 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 08 Jan 2008 16:43:28 -0000 Subject: [issue1762] Inheriting from ABC slows Decimal down. Message-ID: <1199810608.37.0.364699316929.issue1762@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I've only verified the behavior on 2.6, but I suspect it's true for both. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 18:02:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 17:02:05 -0000 Subject: [issue1762] Inheriting from ABC slows Decimal down. Message-ID: <1199811725.33.0.688326867199.issue1762@psf.upfronthosting.co.za> Christian Heimes added the comment: __instancecheck__ contains unnecessary code. If we restrict ABCs to new style classes we could make the function faster: Old: def __instancecheck__(cls, instance): """Override for isinstance(instance, cls).""" return any(cls.__subclasscheck__(c) for c in {instance.__class__, type(instance)}) New: def __instancecheck__(cls, instance): """Override for isinstance(instance, cls).""" # safe a function call for common case if instance.__class__ in cls._abc_cache: return True return cls.__subclasscheck__(instance.__class__) ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 18:12:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 17:12:58 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents Message-ID: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za> New submission from Christian Heimes: The new module "winpath" gives easy access to Windows shell folders like my documents, my files, application data etc. ---------- components: Library (Lib), Windows files: trunk_winpath.patch keywords: patch messages: 59547 nosy: tiran priority: normal severity: normal status: open title: Winpath module - easy access to Windows directories like My Documents type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9106/trunk_winpath.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 18:36:55 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2008 17:36:55 -0000 Subject: [issue1762] Inheriting from ABC slows Decimal down. Message-ID: <1199813815.23.0.958617813081.issue1762@psf.upfronthosting.co.za> Guido van Rossum added the comment: What change is responsible for the speedup? The cache check or removing type(instance) from the set? Since type(instance) is usually the same object as instance.__class__, the set will still have only one element (in particular for Decimal this is the case) so I don't see why that change is necessary. It's also important to find out where __instancecheck__ is called; I don't see where this is happening, so I suspect it's probably somewhere internal. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 18:56:05 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 08 Jan 2008 17:56:05 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents Message-ID: <1199814965.18.0.243220949178.issue1763@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: The current 'path' modules such as posixpath and ntpath have functions that operate on a file path. But I see this module more as a way of getting information related to one's profile. So the name 'winpath' may not be a good choice. ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 19:03:20 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 18:03:20 -0000 Subject: [issue1762] Inheriting from ABC slows Decimal down. Message-ID: <1199815400.31.0.803294723463.issue1762@psf.upfronthosting.co.za> Christian Heimes added the comment: without abc: $ time ./python Lib/test/regrtest.py test_decimal real 0m10.113s user 0m9.685s sys 0m0.196s with numbers.Real subclass: $ time ./python Lib/test/regrtest.py test_decimal real 0m16.232s user 0m15.241s sys 0m0.384s Proposed patch: $ time ./python Lib/test/regrtest.py test_decimal real 0m11.128s user 0m9.533s sys 0m0.260s Only with if instance.__class__ in cls._abc_cache: return True $ time ./python Lib/test/regrtest.py test_decimal real 0m11.201s user 0m10.345s sys 0m0.292s Wow, __instancecheck__ must be called a *lot* of times. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 19:04:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 18:04:36 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents Message-ID: <1199815476.28.0.295712912244.issue1763@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm not very good in naming things. I'm open to suggestions :) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 19:13:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 18:13:13 -0000 Subject: [issue1762] Inheriting from ABC slows Decimal down. Message-ID: <1199815993.14.0.77525252653.issue1762@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch implements the rich cmp slots for <, <=, > and >= required for numbers.Real. Added file: http://bugs.python.org/file9107/trunk_decimal_richcmp.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 19:13:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 18:13:59 -0000 Subject: [issue1760] PEP 341 is not reflected in the documentation Message-ID: <1199816039.0.0.47053120934.issue1760@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl nosy: +georg.brandl priority: -> normal versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 19:32:59 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 08 Jan 2008 18:32:59 -0000 Subject: [issue1737] Windows installer issue (ObjectBrowser.py) Message-ID: <1199817179.78.0.0532013672209.issue1737@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 19:56:12 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 08 Jan 2008 18:56:12 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents Message-ID: <1199818572.75.0.345577551889.issue1763@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I believe Microsoft advises against looking at the registry to find these things, and advocates the use of SHGetFolder instead: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/apcompat/apcompat/use_the_application_programming_interface_to_locate_special_folders.asp As for naming things: I guess an object ShellFolders in ntpath might work fine, with (computed) attributes Desktop, Documents, etc (according to the FOLDERID_ symbolic constants of the API). OTOH, this is entirely ad-hoc, as tons of other Windows API is *not* directly exposed to Python, so it's questionable why this one specifically deserves being supported. The patch has no documentation. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 20:04:35 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 08 Jan 2008 19:04:35 -0000 Subject: [issue1743] IDLE fails to launch Message-ID: <1199819075.03.0.133531433294.issue1743@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can anybody provide a complete, reproducible procedure for that bug (rather than reproducible procedures to work around it)? Such a procedure might have to start with installing Python. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 21:17:33 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 08 Jan 2008 20:17:33 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. In-Reply-To: <1190305618.56.0.684353803069.issue1182@psf.upfronthosting.co.za> Message-ID: <1199823453.38.0.0497226407175.issue1182@psf.upfronthosting.co.za> Mark Dickinson added the comment: Unfortunately, I think this backport still breaks hash: bernoulli:~/python_source/release25-maint dickinsm$ ./python.exe Python 2.5.2a0 (release25-maint:59859M, Jan 8 2008, 11:54:53) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import * >>> x = Decimal("1.634E100") >>> hash(x) == hash(int(x)) False Do we really want to go from a slow-but-working Decimal.__hash__ in Python 2.5.1 to a fast-but- broken hash in Python 2.5.2? I can fix this (it's a 1-line change), and reinstate the extra hash tests, if you like. Or I can post a patch if you prefer. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 21:49:28 2008 From: report at bugs.python.org (Facundo Batista) Date: Tue, 08 Jan 2008 20:49:28 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. In-Reply-To: <1190305618.56.0.684353803069.issue1182@psf.upfronthosting.co.za> Message-ID: <1199825368.04.0.308305039352.issue1182@psf.upfronthosting.co.za> Facundo Batista added the comment: Fix it, please. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 21:55:50 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 08 Jan 2008 20:55:50 -0000 Subject: [issue1381] cmath is numerically unsound In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za> Message-ID: <1199825750.11.0.307107622036.issue1381@psf.upfronthosting.co.za> Mark Dickinson added the comment: A note to any potential reviewers for this patch (cmath3.patch): I'm especially looking for non-mathematical feedback here, so please don't be put off by the mathematics. Some questions: - there's a new file cmath.ctest containing testcases; should this be put directly into Lib/test (where it is right now), or is there a better place. Is the name of this file reasonable? - is the new stuff in pyport.h (checks for _copysign and copysign, and automatic renaming of _copysign to copysign) okay? Should it be in cmathmodule.c instead? - is the code in test_cmath that looks for the testcase file okay? And it would be really great if someone with access to a Windows box could just verify that the tests pass with this patch applied; I've only tested it on OS X and Linux. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 22:25:36 2008 From: report at bugs.python.org (Robin Stocker) Date: Tue, 08 Jan 2008 21:25:36 -0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za> Message-ID: <1199827536.86.0.930822671146.issue1745@psf.upfronthosting.co.za> Robin Stocker added the comment: Guido: The check was only done for call nodes, not for function definitions. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 22:28:00 2008 From: report at bugs.python.org (Robin Stocker) Date: Tue, 08 Jan 2008 21:28:00 -0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za> Message-ID: <1199827680.79.0.208694641263.issue1745@psf.upfronthosting.co.za> Robin Stocker added the comment: Ok, I checked all the logs and updated the patch. test_collections uses n = 254 now and all tests pass. I left revision 54043 out on purpose, because it fixes Lib/inspect.py and Lib/pydoc.py for both PEP 3102 and 3107, so it should be included in the patch for PEP 3107. Added file: http://bugs.python.org/file9108/backport-keyword-only-arguments-full.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 22:47:04 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 08 Jan 2008 21:47:04 -0000 Subject: [issue1761] Bug in re.sub() In-Reply-To: <1199784122.17.0.476084084614.issue1761@psf.upfronthosting.co.za> Message-ID: <1199828824.07.0.674822291809.issue1761@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: In the previous samples we forgot the /g option needed to match ALL occurrences of the pattern: """ use Data::Dumper; $a = "a\nb\nc"; $a =~ s/$/#/g; print Dumper($a); $a = "a\nb\n"; $a =~ s/$/#/g; print Dumper($a); """ Which now gives the same output as Python: $VAR1 = 'a b c#'; $VAR1 = 'a b# #'; Perl is too difficult for us ;-) What shall we do? - mark the issue as invalid - diverge from Perl regular expressions - file a bug in the PCRE issue tracker And in every case: add these samples to the test suite. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 22:47:53 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 08 Jan 2008 21:47:53 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. In-Reply-To: <1190305618.56.0.684353803069.issue1182@psf.upfronthosting.co.za> Message-ID: <1199828873.01.0.678635034013.issue1182@psf.upfronthosting.co.za> Mark Dickinson added the comment: hash fixed in revision 59863. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 23:15:39 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2008 22:15:39 -0000 Subject: [issue1761] Bug in re.sub() In-Reply-To: <1199784122.17.0.476084084614.issue1761@psf.upfronthosting.co.za> Message-ID: <1199830539.15.0.853145756732.issue1761@psf.upfronthosting.co.za> Guido van Rossum added the comment: Then I'd say, this is the correct semantics, for better or for worse; add an example to the docs, and a test to the test suite, and close this as wont fix. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 23:26:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 22:26:47 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za> Message-ID: <1199831207.76.0.228984097794.issue1763@psf.upfronthosting.co.za> Christian Heimes added the comment: Here is a new patch which adds os.path.getshellfolders(). It uses SHGetFolderPathW which is compatible with Windows 2000. I've implemented the API because several of my project need the path to my documents. I've a personal interested in the specific feature. It may also be required for a new, user specific site-package directory. The feature is currently being discussed on the python-dev list. Added file: http://bugs.python.org/file9111/trunk_os_getshellfolders.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 23:42:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 22:42:19 -0000 Subject: [issue1381] cmath is numerically unsound In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za> Message-ID: <1199832139.64.0.199821502395.issue1381@psf.upfronthosting.co.za> Christian Heimes added the comment: * I've added a configure test for copysign a while ago. I'm using this constructor for Windows compatibility in mathmodule.c: #ifdef MS_WINDOWS # define copysign _copysign # define HAVE_COPYSIGN 1 #endif #ifdef HAVE_COPYSIGN #endif I know no platform besides Windows with a _copysign method. You don't have to add tests for _copysign for Windows. You may want to add the code to PC/pyconfig.h and define HAVE_COPYSIGN there. * test_file = testdir + os.sep + 'cmath.ctest make that: test_file = os.path.join(testdir, 'cmath.ctest') * Windows doesn't have log1p, the hyperbolic area functions (asinh) and some other functions, too. IIRC Windows does only implement the Bessel functions of 1st and 2nd kind but non of the other C99 math functions. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 23:54:10 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 08 Jan 2008 22:54:10 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. In-Reply-To: <1190305618.56.0.684353803069.issue1182@psf.upfronthosting.co.za> Message-ID: <1199832850.63.0.197420565078.issue1182@psf.upfronthosting.co.za> Raymond Hettinger added the comment: If this something missing from Colishaw's test suite, you should submit the result to him so they can include it in the next update. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 23:54:59 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 08 Jan 2008 22:54:59 -0000 Subject: [issue1381] cmath is numerically unsound In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za> Message-ID: <1199832898.98.0.427393869707.issue1381@psf.upfronthosting.co.za> Mark Dickinson added the comment: Okay: would it be okay for me to move the #ifdef MS_WINDOWS sequence somewhere where it can be used by both mathmodule.c and cmathmodule.c, then? There are replacements for log1p and asinh in the patch, so it shouldn't matter than they're missing on Windows---it might mean that the accuracy of some of the functions is slightly reduced on Windows, though. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 8 23:58:18 2008 From: report at bugs.python.org (Achim Gaedke) Date: Tue, 08 Jan 2008 22:58:18 -0000 Subject: [issue1137] pyexpat patch for changing buffer_size In-Reply-To: <1189356011.84.0.968400197849.issue1137@psf.upfronthosting.co.za> Message-ID: <1199833098.63.0.384065102924.issue1137@psf.upfronthosting.co.za> Achim Gaedke added the comment: Also the shortend version will bring better performance. Thanks! __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 00:16:55 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 23:16:55 -0000 Subject: [issue1381] cmath is numerically unsound In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za> Message-ID: <1199834215.98.0.151596062774.issue1381@psf.upfronthosting.co.za> Christian Heimes added the comment: It may even be a good idea to move asinh, copysign and log1p to a new file Python/pymath.c and add compensatory implementations of acosh, atanh and expm1, too. The math related code in pyport.h could then be moved to Include/pymath.h. In the past some people have asked me to implement the reverse hyperbolic functions for the math module. This is beyond a simple fix for the cmath module and should be discussed on the python-dev list first. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 00:17:22 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 08 Jan 2008 23:17:22 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. In-Reply-To: <1190305618.56.0.684353803069.issue1182@psf.upfronthosting.co.za> Message-ID: <1199834242.42.0.555487227393.issue1182@psf.upfronthosting.co.za> Mark Dickinson added the comment: I don't think anything's missing from Cowlishaw's test-suite. An old, buggy test (nrmx218) was both renamed (to redx218) and fixed by Cowlishaw. I think Facundo ended up with both tests---so naturally the old, broken test failed. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 00:50:20 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 23:50:20 -0000 Subject: [issue1576] [Patch] Working post import hook and lazy modules In-Reply-To: <1197230661.71.0.762361261009.issue1576@psf.upfronthosting.co.za> Message-ID: <1199836220.9.0.660278382847.issue1576@psf.upfronthosting.co.za> Christian Heimes added the comment: The new patch applies against the latest svn revision. Several functions were renamed. Added file: http://bugs.python.org/file9112/py3k_post_import_lazy.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 00:50:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 23:50:27 -0000 Subject: [issue1576] [Patch] Working post import hook and lazy modules In-Reply-To: <1197230661.71.0.762361261009.issue1576@psf.upfronthosting.co.za> Message-ID: <1199836227.6.0.0512005005999.issue1576@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8909/py3k_post_import_hook3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 00:50:30 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 23:50:30 -0000 Subject: [issue1576] [Patch] Working post import hook and lazy modules In-Reply-To: <1197230661.71.0.762361261009.issue1576@psf.upfronthosting.co.za> Message-ID: <1199836230.94.0.578212359448.issue1576@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8914/py3k_post_import_hook4.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 00:50:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 08 Jan 2008 23:50:34 -0000 Subject: [issue1576] [Patch] Working post import hook and lazy modules In-Reply-To: <1197230661.71.0.762361261009.issue1576@psf.upfronthosting.co.za> Message-ID: <1199836234.67.0.335135014226.issue1576@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8928/py3k_post_import_hook_lazy.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 01:02:06 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2008 00:02:06 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> New submission from Guido van Rossum: We should either change the API so you can pass in a '<' comparator, or get rid of it completely (since key=... takes care of all use cases I can think of). ---------- messages: 59575 nosy: gvanrossum priority: normal severity: normal status: open title: Remove cmp parameter to list.sort() and builtin.sorted() versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 01:02:16 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2008 00:02:16 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1199836936.97.0.146388585336.issue1771@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- components: +Interpreter Core __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 01:06:11 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 09 Jan 2008 00:06:11 -0000 Subject: [issue1683] Thread local storage and PyGILState_* mucked up by os.fork() In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za> Message-ID: <1199837171.56.0.0068152721986.issue1683@psf.upfronthosting.co.za> Christian Heimes added the comment: Bug day task ---------- nosy: +tiran priority: -> high versions: -Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 01:32:45 2008 From: report at bugs.python.org (Senthil) Date: Wed, 09 Jan 2008 00:32:45 -0000 Subject: [issue1722] Undocumented urllib functions In-Reply-To: <1199733730.78.0.524451191239.issue1722@psf.upfronthosting.co.za> Message-ID: <20080109004418.GA3682@gmail.com> Senthil added the comment: > Georg Brandl added the comment: > > There are quite a lot more functions in __all__, more than 10 split* > functions... should they all be documented? > > Also, isn't urlparse meant to do such tasks? I agree. I too feel that not everything in the __all__ list should be documented. And in this specific case of splithost, it is more appropriate for the user to use urlparse. ---------- nosy: +orsenthil __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 01:37:53 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 09 Jan 2008 00:37:53 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1199839073.97.0.909623538588.issue1771@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I support removal; however, there is an uncommon corner-case that is well served by __cmp__ where a primary key is sorted ascending and a secondary key is sorted descending -- that case is a PITA with the key= function because you need a way to invert the sense of the reversed input (there are tricks for this but they are obscure). ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 01:42:21 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 09 Jan 2008 00:42:21 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1199839341.36.0.815625309928.issue1771@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Forgot to mention, the easy work-around is to do two consecutive sorts and take advantage of the guaranteed stability: l.sort(key=secondary, reverse=True) l.sort(key=primary) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 07:22:59 2008 From: report at bugs.python.org (Stephan Hoermann) Date: Wed, 09 Jan 2008 06:22:59 -0000 Subject: [issue1772] popen fails when there are two or more pathnames/parameters with spaces In-Reply-To: <1199859779.21.0.234395665559.issue1772@psf.upfronthosting.co.za> Message-ID: <1199859779.21.0.234395665559.issue1772@psf.upfronthosting.co.za> New submission from Stephan Hoermann: If commands similar to this (including all quotation marks) '"C:\\Program Files\\test.bat" blah "C:\\Data Files\\test2.txt"' are executed using popen, then the following is returned from stderr "'C:\\Program' is not recognized as an internal or external command,\noperable program or batch file.\n". No use of quotation has been able to fix this. As soon as there is more than one pair of quotations inside the command string popen will not handle the command correctly. ---------- components: Library (Lib), Windows messages: 59580 nosy: shoermann severity: major status: open title: popen fails when there are two or more pathnames/parameters with spaces type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 08:00:09 2008 From: report at bugs.python.org (Alan McIntyre) Date: Wed, 09 Jan 2008 07:00:09 -0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za> Message-ID: <1199862009.9.0.576661102944.issue1622@psf.upfronthosting.co.za> Alan McIntyre added the comment: Here's the first draft of a patch (zipfile-unsigned-fixes.diff) that does a few things: - Interpret fields as unsigned unless required (CRC, etc.) - Corrects reading of ZIP files with large archive comments - Replaces hard-coded structure sizes with module-level variables (calculated using struct.calcsize) - When writing a file in ZipFile.close(), if the ZipFile instance has a comment value, this value is now written as the archive comment - Renamed some of the module variables to better match the names used in the ZIP file spec - General cleanup & addition of comments to (hopefully) make the code a little easier to follow Test & doc changes are included, & this code currently passes regression test suite with -uall on OS X. Added file: http://bugs.python.org/file9113/zipfile-unsigned-fixes.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 08:12:18 2008 From: report at bugs.python.org (Adam Olsen) Date: Wed, 09 Jan 2008 07:12:18 -0000 Subject: [issue1683] Thread local storage and PyGILState_* mucked up by os.fork() In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za> Message-ID: <1199862738.77.0.00247630736932.issue1683@psf.upfronthosting.co.za> Changes by Adam Olsen: ---------- nosy: +rhamphoryncus __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 08:36:25 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Wed, 09 Jan 2008 07:36:25 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1199864185.54.0.551339308957.issue1682@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Thanks again for the excellent comments. __init__: good catch. repr(Rational): The rule for repr is "eval(repr(object)) == object". Unfortunately, that doesn't decide between the two formats, since both assume some particular import statements. I picked the one more likely to be unique, and I assume Decimal picked the shorter one. I can go either way. _gcd's sign: It's a happy accident for me. Possibly Sjoerd Mullender designed it that way. I've added a comment and a test. __ceil__: I like that implementation better. 2-argument round: Fixed and tested. equality: Very good point. I've stolen the sandbox code and added Rational.from_float() using it. I think I also need to make this change to the comparisons. hashing: oops, yes these should be hashable. Decimal cheats by comparing != to even floats that it's equal to, so I'm going to assume that they also want Rational(5,2) != Decimal('2.5'). The new patch is against 2.6. ---------- keywords: +patch Added file: http://bugs.python.org/file9114/rational.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 10:04:44 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 09 Jan 2008 09:04:44 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1199869484.16.0.534493607911.issue1682@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I'm -1 on moving this module to the standard library. There has been basically *zero* demand for something like this. Because rational implementations seem to be more fun to write than to use, I think there are some competing implementations. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 10:05:36 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 09 Jan 2008 09:05:36 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za> Message-ID: <1199869536.66.0.586895497055.issue1763@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > It uses SHGetFolderPathW which is compatible with Windows 2000. Is Python supposed to still work on Windows NT 4? http://svn.python.org/projects/python/trunk/README says that support will be droppen in 2.6 for Win9x and WinME, but says nothing about NT4. OTOH, the msdn library site removed many references to NT4 (see the doc for CreateFile, for example). It could be wise to say that python 2.6 is supported only on Windows 2000 and up. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 10:18:42 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 09 Jan 2008 09:18:42 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za> Message-ID: <1199870322.19.0.22201455211.issue1763@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It was never explicitly discussed, however, I always assumed that NT4 support is not necessary anymore. I would like to pose a policy that Python does not need to support Windows releases which have left Microsoft's "extended support". For NT 4 WS, this was on 30.6.2004. For Windows 2000 Pro, this will be on 13.7.2010. Of course, *testing* the releases on Windows 2000 will become difficult - I don't have access to Windows 2000 installations anymore. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 10:52:25 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 09 Jan 2008 09:52:25 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za> Message-ID: <1199872345.15.0.782199263697.issue1763@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: OK. We should also remove references to older versions on the website: http://www.python.org/download/releases/2.5.1/ and the various READMEs. For testing older platforms, we can still use virtual machines. I think this is how Christian develops on Windows XP. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 11:10:59 2008 From: report at bugs.python.org (albert hofkamp) Date: Wed, 09 Jan 2008 10:10:59 -0000 Subject: [issue1773] Reference to Python issue tracker incorrect In-Reply-To: <1199873459.46.0.46987451089.issue1773@psf.upfronthosting.co.za> Message-ID: <1199873459.46.0.46987451089.issue1773@psf.upfronthosting.co.za> New submission from albert hofkamp: In the Python reference manual (the online current documentation), in the "About this document" section, there is a reference to the Sourceforge bug tracker for reporting errors in the document. This tracker however has been closed, and has been replaced by the one at http://bugs.python.org/ ---------- components: Documentation messages: 59587 nosy: aioryi severity: normal status: open title: Reference to Python issue tracker incorrect versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 11:14:03 2008 From: report at bugs.python.org (albert hofkamp) Date: Wed, 09 Jan 2008 10:14:03 -0000 Subject: [issue1774] Reference to New style classes documentation is incorrect In-Reply-To: <1199873642.96.0.268775813123.issue1774@psf.upfronthosting.co.za> Message-ID: <1199873642.96.0.268775813123.issue1774@psf.upfronthosting.co.za> New submission from albert hofkamp: In the Python reference manual (the online current documentation), in Section 3.3 "New-style and classic classes", there is a reference to external documentation about new style classes. The reference is however incorrect, it should be http://www.python.org/doc/newstyle/ rather than the mentioned http://www.python.org/doc/newstyle.html ---------- components: Documentation messages: 59588 nosy: aioryi severity: normal status: open title: Reference to New style classes documentation is incorrect versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 13:30:19 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 09 Jan 2008 12:30:19 -0000 Subject: [issue1114] _curses issues on 64-bit big-endian (e.g, AIX) In-Reply-To: <1189049554.49.0.320613302462.issue1114@psf.upfronthosting.co.za> Message-ID: <1199881818.99.0.161210582909.issue1114@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Rev. 59870 on trunk fixes another usage of &attr in the wrapper for the chgat() method. Luke, a 2.5.2 release is not too far off. If possible, can you please try compiling the 25-maint branch on AIX to check that the problems are fixed? Thanks! __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 13:44:14 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 09 Jan 2008 12:44:14 -0000 Subject: [issue1773] Reference to Python issue tracker incorrect In-Reply-To: <1199873459.46.0.46987451089.issue1773@psf.upfronthosting.co.za> Message-ID: <1199882654.71.0.782252737147.issue1773@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Fixed in rev. 57394 of the 2.5 branch; thanks for reporting this! The web site's copy of the documentation will be updated when Python 2.5.2 is released. ---------- assignee: -> akuchling nosy: +akuchling resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 13:48:13 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 09 Jan 2008 12:48:13 -0000 Subject: [issue1731] Random errors on interpreter shutdown In-Reply-To: <1199402921.07.0.182156121035.issue1731@psf.upfronthosting.co.za> Message-ID: <1199882893.8.0.587932696165.issue1731@psf.upfronthosting.co.za> A.M. Kuchling added the comment: The fix has been applied (by GvR) to 2.5 in r59724. This issue can probably be closed now. ---------- nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 13:49:23 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 09 Jan 2008 12:49:23 -0000 Subject: [issue1266] segfault in curses when calling redrawwin() before refresh() In-Reply-To: <1192126484.51.0.25368750134.issue1266@psf.upfronthosting.co.za> Message-ID: <1199882963.98.0.664573105345.issue1266@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 13:52:29 2008 From: report at bugs.python.org (Andre Roberge) Date: Wed, 09 Jan 2008 12:52:29 -0000 Subject: [issue1775] filehandle.write() does not return None (Python 3.0a2) In-Reply-To: <1199883149.22.0.23332594805.issue1775@psf.upfronthosting.co.za> Message-ID: <1199883149.22.0.23332594805.issue1775@psf.upfronthosting.co.za> New submission from Andre Roberge: According to the docs, and consistent with the Python 2.x behavior, filehandle.write() should return None. However, under 3.0a2 (and 3.0a1), it returns the number of characters written. Either the documentation http://docs.python.org/dev/3.0/tutorial/inputoutput.html#reading-and-writing-files is wrong, or it is a bug. I would *much* prefer if the behavior would stay the same as before. Below is a sample session illustrating the behavior. Note that I also get an error message when exiting the session using exit() - this is an unrelated problem. Python 3.0a2 (r30a2:59382, Dec 27 2007, 15:48:14) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> handle = open('test_file.txt.', 'w') >>> handle.write('spam') 4 >>> r = handle.write('more spam') >>> print(r) 9 >>> exit() /usr/local/py3k/lib/python3.0/io.py:1210: RuntimeWarning: Trying to close unclosable fd! self.buffer.close() ---------- components: Interpreter Core messages: 59592 nosy: aroberge severity: normal status: open title: filehandle.write() does not return None (Python 3.0a2) type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 14:16:50 2008 From: report at bugs.python.org (Facundo Batista) Date: Wed, 09 Jan 2008 13:16:50 -0000 Subject: [issue1774] Reference to New style classes documentation is incorrect In-Reply-To: <1199873642.96.0.268775813123.issue1774@psf.upfronthosting.co.za> Message-ID: <1199884610.27.0.378021033284.issue1774@psf.upfronthosting.co.za> Changes by Facundo Batista: ---------- assignee: -> facundobatista nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 14:30:20 2008 From: report at bugs.python.org (Fredrik Lundh) Date: Wed, 09 Jan 2008 13:30:20 -0000 Subject: [issue1761] Bug in re.sub() In-Reply-To: <1199784122.17.0.476084084614.issue1761@psf.upfronthosting.co.za> Message-ID: <1199885420.88.0.100438219652.issue1761@psf.upfronthosting.co.za> Fredrik Lundh added the comment: For the record, $ is defined to match "before a newline at the end of the string, or at the end of the string" in normal mode, and "before any newline, or at the end of the string" in multiline mode. (and I have a vague memory that the "before a newline" behaviour in normal mode was added for Perl compatibility) > It seems that it matches BOTH the end of the string AND just before the newline at the end of the string. Of course it does: re.sub scans the string for matches from left to right, and does the substitution everywhere the pattern matches, only skipping over the matched parts. Or in other words, if a pattern matches N characters on position X has no influence on whether it matches on position X+N or not. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 15:00:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 09 Jan 2008 14:00:31 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents In-Reply-To: <1199872345.15.0.782199263697.issue1763@psf.upfronthosting.co.za> Message-ID: <4784D397.8060709@cheimes.de> Christian Heimes added the comment: Amaury Forgeot d'Arc wrote: > For testing older platforms, we can still use virtual machines. I think > this is how Christian develops on Windows XP. Correct, I'm using a VMWare installation of Windows XP SP2 German and DesktopBSD (FreeBSD variant) to test Python on Windows and BSD. Several of the build bots seem to use a VMWare installation, too. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 15:22:47 2008 From: report at bugs.python.org (Facundo Batista) Date: Wed, 09 Jan 2008 14:22:47 -0000 Subject: [issue846388] Check for signals during regular expression matches Message-ID: <1199888567.87.0.598743046798.issue846388@psf.upfronthosting.co.za> Facundo Batista added the comment: Retried it in a platform where I trust timing, and it proved ok. So, problem solved, no performance impact, all tests pass ok. Commited in r59862. Thank you all! ---------- resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Jan 9 15:24:11 2008 From: report at bugs.python.org (Facundo Batista) Date: Wed, 09 Jan 2008 14:24:11 -0000 Subject: [issue1379209] socket.recv(OOB) raises exception on closed socket Message-ID: <1199888650.99.0.76822819331.issue1379209@psf.upfronthosting.co.za> Facundo Batista added the comment: Tried it on Linux, but the behaviour is the same on Py2.5. It was already fixed in the trunk (it returns "", as in the inbound read). Thanks for the report! ---------- resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 9 15:26:40 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 09 Jan 2008 14:26:40 -0000 Subject: [issue1776] __import__ must not accept filenames In-Reply-To: <1199888800.48.0.716255470665.issue1776@psf.upfronthosting.co.za> Message-ID: <1199888800.48.0.716255470665.issue1776@psf.upfronthosting.co.za> New submission from Christian Heimes: See http://permalink.gmane.org/gmane.comp.python.devel/90960 It's also "broken" in 2.5 but we must not change the behavior in a maintenance release. ---------- components: Interpreter Core messages: 59602 nosy: tiran priority: normal severity: normal status: open title: __import__ must not accept filenames versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 15:27:03 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 09 Jan 2008 14:27:03 -0000 Subject: [issue1729930] 2.5.1 latest svn fails test_curses and test_timeout Message-ID: <1199888823.82.0.96047225347.issue1729930@psf.upfronthosting.co.za> A.M. Kuchling added the comment: According to the man page for endwin() from ncurses, "In this implementation endwin returns an error if the terminal was not initialized." This doesn't make the problem any clearer to me. Perhaps the setupterm() or initscr() in Lib/tests/test_curses is failing in a way that we aren't noticing. ---------- nosy: +akuchling _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 9 15:27:50 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 09 Jan 2008 14:27:50 -0000 Subject: [issue1642054] Python 2.5 gets curses.h warning on HPUX Message-ID: <1199888870.16.0.975217332867.issue1642054@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 9 15:34:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 09 Jan 2008 14:34:47 -0000 Subject: [issue1775] filehandle.write() does not return None (Python 3.0a2) Message-ID: <1199889287.37.0.0680460050656.issue1775@psf.upfronthosting.co.za> Christian Heimes added the comment: Guido, Mike and Mark have implemented most of the new IO library. I'm sure they can shed some light on the design decision. I've fixed the other bug a while ago. I don't use exit() and I didn't noticed the problem until Joseph pointed me in the right direction. ---------- assignee: -> gvanrossum components: +Library (Lib) -Interpreter Core nosy: +georg.brandl, gvanrossum, mark_t_russell, tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 15:34:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 09 Jan 2008 14:34:54 -0000 Subject: [issue1774] Reference to New style classes documentation is incorrect Message-ID: <1199889294.77.0.19974744978.issue1774@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 16:10:00 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2008 15:10:00 -0000 Subject: [issue1775] filehandle.write() does not return None (Python 3.0a2) Message-ID: <1199891400.15.0.594102025328.issue1775@psf.upfronthosting.co.za> Guido van Rossum added the comment: The intention was that the lowest-level (unbuffered) stream object can write fewer bytes than given to it, as it is a direct interface to the underlying system call, which has this property (especially when the file is in non-blocking mode). I think it's fine to return None from the higher-level classes' write() method (buffered and text). Though this makes it a bit harder to switch between buffered and unbuffered binary output. Perhaps text I/O should return None and bytes I/O should return a byte count? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 16:38:11 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2008 15:38:11 -0000 Subject: [issue1761] Bug in re.sub() Message-ID: <1199893091.54.0.168255886687.issue1761@psf.upfronthosting.co.za> Guido van Rossum added the comment: Which is why I like to use \Z to match *only* the end of the string. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 16:46:56 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 09 Jan 2008 15:46:56 -0000 Subject: [issue1761] Bug in re.sub() Message-ID: <1199893616.63.0.263756213471.issue1761@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Aha, I always thought that \Z was an alias for $. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 17:09:21 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2008 16:09:21 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. Message-ID: <1199894961.1.0.488713210152.issue1682@psf.upfronthosting.co.za> Guido van Rossum added the comment: Raymond, do you *always* have to be such a grinch? The mere existance of competing implementations proves that there's a need. Hopefully having one in the stdlib will inspire others to contribute improvements rather than starting from scratch. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 17:17:34 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Wed, 09 Jan 2008 16:17:34 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1199895454.56.0.667080336683.issue1210@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: You're correct in pointing out that IMAP4 supports arbitrary encodings, so simply hard-coding ASCII is not correct. The encoding isn't connection-level, but applies to particular sequences of bytes in the connection stream. To correctly interpret the bytes as characters, decoding must be integrated with the rest of the protocol implementation. ---------- nosy: +exarkun __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 17:37:41 2008 From: report at bugs.python.org (Facundo Batista) Date: Wed, 09 Jan 2008 16:37:41 -0000 Subject: [issue1774] Reference to New style classes documentation is incorrect Message-ID: <1199896661.65.0.240591628415.issue1774@psf.upfronthosting.co.za> Facundo Batista added the comment: It was ok in the trunk docs. Fixed it in the 2.5 maint branch. Thanks for the report! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 18:29:14 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2008 17:29:14 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior Message-ID: <1199899754.69.0.590809258366.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: Alexandre, which Python version did you compile with -Wstrict-overflow? It would behoove us to check 2.5.2 thoroughly before it goes out the door. I will contact Coverity to ask if they check for this kind of thing. (They just upgraded us to "Rung 2", whatever that may mean. :-) MvL: I don't want 2s complement throughout the language, I just want the overflow checks to be reliable. Since I'd forgotten about the difference between unsigned and signed overflow, I have no idea how many overflow checks have been submitted that are relying on signed overflow; though apparently (if the -Wstrict-overflow results can be trusted) we're okay. FWIW, I've heard that some commercial compilers (e.g. XLC) assume that even *unsigned* overflow is undefined, violating the C standard. This would suggest that buffer overflow checks should be coded without relying on arithmetic overflow at all. This is possible, just a bit hairy. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 18:31:00 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2008 17:31:00 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior Message-ID: <1199899860.61.0.192062874889.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: Marc-Andre: what do you mean by breaking lots and lots of extensions? Extensions also contain buffer overflow checks (at least I hope they do :-) and those should also be guaranteed safe by using -fwrapv or -fno-strict-overflow (GCC 4.2 and higher) until we're sure there aren't any. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 18:46:07 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2008 17:46:07 -0000 Subject: [issue1608] test_str.py crashes Message-ID: <1199900767.94.0.485912848668.issue1608@psf.upfronthosting.co.za> Guido van Rossum added the comment: It would actually be better to use -fno-strict-overflow instead of -fwrapv, if it exists (GCC 4.2 and later). See also http://bugs.python.org/issue1621 which suggests there aren't actually many places that need this; gcc -Wstrict-overflow should help auditing the code. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 18:48:34 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 09 Jan 2008 17:48:34 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. Message-ID: <1199900914.88.0.925647218368.issue1682@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Not sure I'm the grinch on this one. I thought PEPs on this were rejected long ago and no one complained afterwards. After years of watching newsgroup discussions and feature requests, I do not recall a single request or seeing a single problem that was better solved with a rational package. On python-help and the tutorial newsgroup, I've never seen a question about the existing module in the Tools directory or even a question on the topic. I think rational modules are ubiquitous for the same reason as Sudoku solvers -- they are cute, an easy exercise, and fun to write. There is some variation in how each chooses to make compromises so the denominators do not get unusably large. Also, there is some variation in sophistication of the GCD/LCD algorithm. I had thought the standards for inclusion in the standard library had risen quite a bit (best-in-class category killers and whatnot). ISTM, this is aspiring cruft -- I cannot remember encountering a real business or engineering problem that needed rational arithmetic (the decimal module seems to meet the rare need for high precision arithmetic). All that being said, maybe the module with serve some sort of educational purpose or will serve to show-off the numeric tower abstract base classes. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 18:55:36 2008 From: report at bugs.python.org (Facundo Batista) Date: Wed, 09 Jan 2008 17:55:36 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. Message-ID: <1199901336.04.0.320143476609.issue1682@psf.upfronthosting.co.za> Facundo Batista added the comment: The PEP 239 is Rejected (http://www.python.org/dev/peps/pep-0239/). If a Rational data type would be included in the stdlib, my recommendation is that first that PEP would be reopened and pushed until get accepted. Also, note the kind of questions Mark is asking here: the analysis and answer of those questions belongs to a PEP, not to a patch. We risk to not be very rational (1/2 wink) in these decisions. I'd close this patch as Rejected (as for the PEP), at least until the PEP gets accepted (if ever). ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 19:13:11 2008 From: report at bugs.python.org (Ismail Donmez) Date: Wed, 09 Jan 2008 18:13:11 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior Message-ID: <1199902391.58.0.807062869714.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: -Wstrict-overflow=3 with gcc 4.3 trunk here shows : Modules/cPickle.c: In function 'Unpickler_noload': Modules/cPickle.c:4232: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false Modules/cPickle.c:194: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false Modules/cPickle.c: In function 'load': Modules/cPickle.c:4232: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false But also note that -fno-strict-aliasing is also just another workaround and its more serious than -fwrapv. ---------- nosy: +cartman __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 19:44:05 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 09 Jan 2008 18:44:05 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents In-Reply-To: <1199872345.15.0.782199263697.issue1763@psf.upfronthosting.co.za> Message-ID: <478515F1.5000208@v.loewis.de> Martin v. L?wis added the comment: > OK. We should also remove references to older versions on the website: > http://www.python.org/download/releases/2.5.1/ and the various READMEs. No. Python 2.5.1 *does* support Windows 95 (I have myself tested that). Only 2.6 will drop support for 9x. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 19:58:08 2008 From: report at bugs.python.org (Grant Monroe) Date: Wed, 09 Jan 2008 18:58:08 -0000 Subject: [issue1777] ElementTree/cElementTree findtext inconsistency In-Reply-To: <1199905088.24.0.426478607654.issue1777@psf.upfronthosting.co.za> Message-ID: <1199905088.24.0.426478607654.issue1777@psf.upfronthosting.co.za> New submission from Grant Monroe: cElementTree findtext seems to return None when it should return a string. ---------- components: Library (Lib) files: etree_test.py messages: 59618 nosy: gmonroe severity: normal status: open title: ElementTree/cElementTree findtext inconsistency type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9115/etree_test.py __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 19:59:18 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 09 Jan 2008 18:59:18 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1199902391.58.0.807062869714.issue1621@psf.upfronthosting.co.za> Message-ID: <47851983.50405@v.loewis.de> Martin v. L?wis added the comment: > But also note that -fno-strict-aliasing is also just another workaround > and its more serious than -fwrapv. Sure - however, that is fixed in Python 3 (and unrelated to this issue) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 20:09:14 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2008 19:09:14 -0000 Subject: [issue1731] Random errors on interpreter shutdown In-Reply-To: <1199402921.07.0.182156121035.issue1731@psf.upfronthosting.co.za> Message-ID: <1199905754.0.0.528197127448.issue1731@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 20:22:15 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 09 Jan 2008 19:22:15 -0000 Subject: [issue1777] ElementTree/cElementTree findtext inconsistency In-Reply-To: <1199905088.24.0.426478607654.issue1777@psf.upfronthosting.co.za> Message-ID: <1199906535.14.0.751281437596.issue1777@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Fredrik, can you take a look? ---------- assignee: -> effbot nosy: +effbot, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 20:35:50 2008 From: report at bugs.python.org (Fredrik Lundh) Date: Wed, 09 Jan 2008 19:35:50 -0000 Subject: [issue1777] ElementTree/cElementTree findtext inconsistency In-Reply-To: <1199905088.24.0.426478607654.issue1777@psf.upfronthosting.co.za> Message-ID: <1199907350.31.0.155291954282.issue1777@psf.upfronthosting.co.za> Fredrik Lundh added the comment: Looks like the mechanisms used decide when to invoke the full ElementPath machinery differs somewhat. I've added this to the TODO list for ET 1.3; in the meantime, my advice is "don't do that". (adding a check for '.' to the PATHCHAR macro should fix this, I think.) ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 20:56:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 09 Jan 2008 19:56:56 -0000 Subject: [issue1776] __import__ must not accept filenames In-Reply-To: <1199888800.48.0.716255470665.issue1776@psf.upfronthosting.co.za> Message-ID: <1199908616.81.0.538425421851.issue1776@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59876 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 20:57:59 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 09 Jan 2008 19:57:59 -0000 Subject: [issue1750] Test: This is title In-Reply-To: <1199660809.31.0.345671159416.issue1750@psf.upfronthosting.co.za> Message-ID: <1199908679.07.0.876716965222.issue1750@psf.upfronthosting.co.za> Georg Brandl added the comment: testing __________________________________ From report at bugs.python.org Wed Jan 9 21:01:52 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 09 Jan 2008 20:01:52 -0000 Subject: [issue1750] Test: This is title In-Reply-To: <1199660809.31.0.345671159416.issue1750@psf.upfronthosting.co.za> Message-ID: <1199908912.87.0.865707604356.issue1750@psf.upfronthosting.co.za> Georg Brandl added the comment: testing __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 22:12:38 2008 From: report at bugs.python.org (Andre Roberge) Date: Wed, 09 Jan 2008 21:12:38 -0000 Subject: [issue1775] filehandle.write() does not return None (Python 3.0a2) In-Reply-To: <1199883149.22.0.23332594805.issue1775@psf.upfronthosting.co.za> Message-ID: <1199913158.58.0.582447502499.issue1775@psf.upfronthosting.co.za> Andre Roberge added the comment: After doing some more reading, I realize that the current behaviour is totally consistent with http://www.python.org/dev/peps/pep-3116/ which I should have consulted first. So perhaps it should be considered to be simply a case of a documentation error, as I alluded to when I open this issue. (sorry for the noise) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 22:22:14 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 09 Jan 2008 21:22:14 -0000 Subject: [issue1448325] re search infinite loop Message-ID: <1199913734.39.0.213325055852.issue1448325@psf.upfronthosting.co.za> Ralf Schmitt added the comment: You're being a victim of two issues here: 1.regular expression matching can take a long time. see: http://bugs.python.org/issue1662581 2. regular expression matching was not interruptible: http://bugs.python.org/issue846388 ---------- nosy: +schmir versions: +Python 2.3, Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 9 22:26:36 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 09 Jan 2008 21:26:36 -0000 Subject: [issue1662581] the re module can perform poorly: O(2**n) versus O(n**2) Message-ID: <1199913996.2.0.0197386435449.issue1662581@psf.upfronthosting.co.za> Ralf Schmitt added the comment: here are two other bug reports about the same issue: http://bugs.python.org/issue1448325 http://bugs.python.org/issue1566086 ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 9 22:28:20 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 09 Jan 2008 21:28:20 -0000 Subject: [issue1277] mailbox.Maildir: factory not used In-Reply-To: <1192377763.05.0.280093607923.issue1277@psf.upfronthosting.co.za> Message-ID: <1199914100.42.0.298873933336.issue1277@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 9 22:29:36 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 09 Jan 2008 21:29:36 -0000 Subject: [issue756982] mailbox should use email not rfc822 Message-ID: <1199914176.9.0.626703113965.issue756982@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: barry -> akuchling ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Jan 9 22:37:13 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 09 Jan 2008 21:37:13 -0000 Subject: [issue1566086] RE (regular expression) matching stuck in loop Message-ID: <1199914633.59.0.6017168481.issue1566086@psf.upfronthosting.co.za> Ralf Schmitt added the comment: With python 2.6 the program can be interrupted with ctrl-c (see http://bugs.python.org/issue846388). I think this one should be closed as a duplicate of: http://bugs.python.org/issue1662581 ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 9 22:53:30 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 09 Jan 2008 21:53:30 -0000 Subject: [issue1720992] automatic imports Message-ID: <1199915610.27.0.508045972609.issue1720992@psf.upfronthosting.co.za> Ralf Schmitt added the comment: it won't get better than: http://pypi.python.org/pypi/autoimp/ I suggest this should be closed. ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 9 23:29:21 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 09 Jan 2008 22:29:21 -0000 Subject: [issue1488934] file.write + closed pipe = no error Message-ID: <1199917761.71.0.260420057352.issue1488934@psf.upfronthosting.co.za> Ralf Schmitt added the comment: the c program is broken as it does not check the error code of fflush. The real problem is buffering. while True: __print 'Hello' __time.sleep (1) will not notice an error until the buffers are flushed. Running python t.py |head -n2 and killing head does not give me an error. with PYTHONUNBUFFERED=1 or when using sys.stdout.flush() the program breaks with: ~/ PYTHONUNBUFFERED=1 python t.py|head -n2 ralf at rat64 ok Hello Hello Traceback (most recent call last): File "t.py", line 5, in print "Hello" IOError: [Errno 32] Broken pipe ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 9 23:34:42 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 09 Jan 2008 22:34:42 -0000 Subject: [issue1488934] file.write + closed pipe = no error Message-ID: <1199918082.29.0.856687127499.issue1488934@psf.upfronthosting.co.za> Ralf Schmitt added the comment: ahh.no. the c program does the fflush on the logfile...sorry. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 9 23:38:04 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 09 Jan 2008 22:38:04 -0000 Subject: [issue1566086] RE (regular expression) matching stuck in loop Message-ID: <1199918284.1.0.345893957474.issue1566086@psf.upfronthosting.co.za> Georg Brandl added the comment: Done. ---------- nosy: +georg.brandl resolution: -> duplicate status: open -> closed superseder: -> the re module can perform poorly: O(2**n) versus O(n**2) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 10 00:11:02 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2008 23:11:02 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1199920262.44.0.485321589182.issue1682@psf.upfronthosting.co.za> Guido van Rossum added the comment: The rejection of PEP 239 was years ago. PEP 3141 was accepted; it includes adding a rational type to the stdlib, and Jeffrey is doing this with my encouragement. The motivation is to have at least one example of each type in our modest numeric tower in the stdlib. I'm sure there will be plenty of uses for rational.py, e.g. in education. Of course, if someone has a better candidate or a proposed improvement, speak up now! It looks like Mark's suggestions can be treated as code review; I don't think we need a new PEP. Note that the mere existence of PEP 239 again points out that the demand is not zero. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 00:19:47 2008 From: report at bugs.python.org (Achim Gaedke) Date: Wed, 09 Jan 2008 23:19:47 -0000 Subject: [issue1778] SyntaxError.offset sometimes wrong In-Reply-To: <1199920786.95.0.62807405199.issue1778@psf.upfronthosting.co.za> Message-ID: <1199920786.95.0.62807405199.issue1778@psf.upfronthosting.co.za> New submission from Achim Gaedke: The value SyntaxError.offset is for most SyntaxErrors an offset from beginning of line SyntaxError.lineno. In case of an triple-quoted string which is not at all closed, offset seems to be the offset from beginning of the buffer. ---------- components: Interpreter Core files: compile_test.py messages: 59634 nosy: AchimGaedke severity: normal status: open title: SyntaxError.offset sometimes wrong type: behavior versions: Python 2.4, Python 2.5 Added file: http://bugs.python.org/file9116/compile_test.py __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 01:04:56 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 10 Jan 2008 00:04:56 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1199923496.11.0.966544671754.issue1682@psf.upfronthosting.co.za> Raymond Hettinger added the comment: If this goes in, I have some recommendations: * Follow the decimal module's lead in assiduously avoiding float->rational conversions. Something like Rat.from_float(1.1) is likely to produce unexpected results (like locking in an inexact input and having an unexpectedly large denominator). * Likewise, follow decimal's lead in avoiding all automatic coercisions from floats: Rational(3,10) + 0.3 for example. The two don't mix. * Consider following decimal's lead on having a context that can limit the maximum size of a denominator. There are various strategies for handling a limit overflow including raising an exception or finding the nearest rational upto the max denominator (there are some excellent though complex published algorithms for this) or rounding the nearest fixed-base (very easy). I'll dig out my HP calculator manuals at some point -- they had worked-out a number of challenges with fractional arithmetic (including their own version of an Inexact tag). * Consider adding Decimal.from_rational and Rational.from_decimal. I believe these are both easy and can be done losslessly. * Automatic coercions to/from Decimal need to respect the active decimal context. For example the result of Rational(3,11) + Decimal('3.1415926') is context dependent and may not be commutative. * When in doubt, keep the API minimal so we don't lock-in design mistakes. * Test the API by taking a few numerical algorithms and seeing how well they work with rational inputs (for starters, try http://docs.python.org/lib/decimal-recipes.html ). * If you do put in a method that accepts floats, make sure that it can accept arguments to control the rational approximation. Ideally, you would get something something like this Rational.approximate(math.pi, 6) --> 355/113 that could produce the smallest rationalal approximation to a given level of accuracy. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 01:13:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 10 Jan 2008 00:13:54 -0000 Subject: [issue1778] SyntaxError.offset sometimes wrong In-Reply-To: <1199920786.95.0.62807405199.issue1778@psf.upfronthosting.co.za> Message-ID: <1199924034.65.0.467323714478.issue1778@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 01:14:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 10 Jan 2008 00:14:36 -0000 Subject: [issue1277] mailbox.Maildir: factory not used In-Reply-To: <1192377763.05.0.280093607923.issue1277@psf.upfronthosting.co.za> Message-ID: <1199924076.97.0.222693383519.issue1277@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch priority: -> normal versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 01:15:36 2008 From: report at bugs.python.org (Facundo Batista) Date: Thu, 10 Jan 2008 00:15:36 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1199924136.09.0.353696986266.issue1682@psf.upfronthosting.co.za> Facundo Batista added the comment: 2008/1/9, Raymond Hettinger said: > * Consider adding Decimal.from_rational and Rational.from_decimal. I > believe these are both easy and can be done losslessly. If it's lossless, why not just allow Decimal(Rational(...)) and Rational(Decimal(...))? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 01:20:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 10 Jan 2008 00:20:02 -0000 Subject: [issue1381] cmath is numerically unsound In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za> Message-ID: <1199924402.11.0.931365499395.issue1381@psf.upfronthosting.co.za> Christian Heimes added the comment: Guido, how do you like the idea of Include/pymath.h and Python/pymath.c containing supplementary mathematical functions and mathematical constants? Mark's patch for cmath is rather large, can it still be applied to 2.5? ---------- nosy: +gvanrossum versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 01:29:07 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2008 00:29:07 -0000 Subject: [issue1381] cmath is numerically unsound In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za> Message-ID: <1199924947.07.0.0869474652867.issue1381@psf.upfronthosting.co.za> Guido van Rossum added the comment: Are you crazy? Adding new features to 2.5? No way! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 01:29:17 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 10 Jan 2008 00:29:17 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1199924957.32.0.750589984318.issue1682@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > If it's lossless, why not just allow >Decimal(Rational(...)) and Rational(Decimal(...))? Those conversions are fine. It's the float<-->rational conversions that are problematic. There are exact float to rational conversions using math.frexp() but I don't think the results tend to match what users expect (since 1.1 isn't exactly represented). Also, there may be overflow issues with trying to go from rationals to floats when the denomintor is very large. I think the history of rational modules is that simplistic implementations get built and then the writers find that exploding denominators limit their usefulness for anything other than trivial problems. The solution is to limit denominators but that involves less trivial algorithms and a more sophisticated API. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 01:38:35 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2008 00:38:35 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1199924957.32.0.750589984318.issue1682@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On Jan 9, 2008 4:29 PM, Raymond Hettinger wrote: > I think the history of rational modules is that simplistic > implementations get built and then the writers find that exploding > denominators limit their usefulness for anything other than trivial > problems. The solution is to limit denominators but that involves less > trivial algorithms and a more sophisticated API. A "rational" type that limits denominators (presumably by rounding) isn't needed -- we alreay have Decimal. The proposed rational type is meant for "pure" mathematical uses, just like Python's long ints. Regarding float->rational, I propose to refuse Rational(1.1) for the same reasons as Decimal(1.1) is refused, but to add a separate constructor (a class method?) that converts a float to a rational exactly (as long as it isn't nan or inf), large denominators be damned. This can help people who are interested in taking floating point numbers apart. float(Rational()) should be fine. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 02:00:03 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2008 01:00:03 -0000 Subject: [issue1779] int("- 1") is valud, but float("- 1") isn't. Which is right? In-Reply-To: <1199926803.21.0.243129638352.issue1779@psf.upfronthosting.co.za> Message-ID: <1199926803.21.0.243129638352.issue1779@psf.upfronthosting.co.za> New submission from Guido van Rossum: I discovered that when converting a string to an int or float, the int conversion allows whitespace after the sign, while the float conversion doesn't. I think they should be consistent. ---------- components: Interpreter Core messages: 59641 nosy: gvanrossum priority: low severity: normal status: open title: int("- 1") is valud, but float("- 1") isn't. Which is right? versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 02:01:46 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Jan 2008 01:01:46 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> New submission from Mark Dickinson: After seeing issue #1761, I realized that there's a bug in the Decimal constructor: it accepts newline-terminated strings: >>> from decimal import * >>> s = "2.3\n" >>> Decimal(s) Decimal("2.3") I think this is, strictly speaking, a bug because: (1) The IBM decimal specification explicitly disallows additional whitespace in a numeric string (see http://www2.hursley.ibm.com/decimal/daconvs.html), (2) the operation to-number is supposed only to accept numeric strings, and (3) Decimal.__new__ is currently the method that implements to-number. Is this worth fixing? This buggy behaviour might well be useful (e.g. to someone parsing a file with one Decimal per line). I'll fix it if anyone thinks it's worth it. Even if it should be fixed, I don't think this is worth backporting to Python 2.5, especially since it might break things. ---------- assignee: facundobatista components: Library (Lib) messages: 59642 nosy: facundobatista, marketdickinson priority: normal severity: minor status: open title: Decimal constructor accepts newline terminated strings type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 02:04:41 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2008 01:04:41 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1199927080.98.0.703948638142.issue1780@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'd propose doing the same thing as int() and float(), which accept and strip leading and trailing whitespace. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 02:20:50 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 10 Jan 2008 01:20:50 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1199928050.27.0.399697519079.issue1780@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I concur with Guido. The to-number operation is part of the spec. The constructor belongs to us and should match the rest of the language. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 02:23:23 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Thu, 10 Jan 2008 01:23:23 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1199923496.11.0.966544671754.issue1682@psf.upfronthosting.co.za> Message-ID: <5d44f72f0801091723j57ad3a38o2a933b68d798279@mail.gmail.com> Jeffrey Yasskin added the comment: > * Follow the decimal module's lead in assiduously avoiding > float->rational conversions. Something like Rat.from_float(1.1) is > likely to produce unexpected results (like locking in an inexact input > and having an unexpectedly large denominator). I agree that it's not usually what people ought to use, and I don't think it's an essential part of the API. It might be a useful starting point for the approximation methods though. .trim() and .approximate() in http://svn.python.org/view/sandbox/trunk/rational/Rational.py?rev=40988&view=auto and Haskell's approxRational (http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-Ratio.html) start from rationals instead of floats. On the other hand, it might make sense to provide explicit methods to approximate from floats instead of asking people to execute the two-phase process. I'm happy to give it a different name or drop it entirely. > * Likewise, follow decimal's lead in avoiding all automatic coercisions > from floats: Rational(3,10) + 0.3 for example. The two don't mix. I'm reluctant to remove the fallback to float, unless the consensus is that it's always a bad idea to support mixed-mode arithmetic (which is possible: I was surprised by the loss of precision of "10**23/1" while writing this). Part of the purpose of this class is to demonstrate how to implement cross-type operations. Note that it is an automatic coercion _to_ floats, so it doesn't look like you've gotten magic extra precision. > * Consider following decimal's lead on having a context that can limit > the maximum size of a denominator. There are various strategies for > handling a limit overflow including raising an exception or finding the > nearest rational upto the max denominator (there are some excellent > though complex published algorithms for this) or rounding the nearest > fixed-base (very easy). I'll dig out my HP calculator manuals at some > point -- they had worked-out a number of challenges with fractional > arithmetic (including their own version of an Inexact tag). Good idea, but I'd like to punt that to a later revision if you don't mind. If we do punt, that'll force the default context to be "infinite precision" but won't prevent us from adding explicit contexts. Do you see any problems with that? > * Consider adding Decimal.from_rational and Rational.from_decimal. I > believe these are both easy and can be done losslessly. Decimal.from_rational(Rat(1, 3)) wouldn't be lossless, but Rational.from_decimal is easier than from_float. Then Decimal.from_rational() could rely on just numbers.Rational, so it would be independent of this module. Is that a method you'd want on Decimal anyway? The question becomes whether we want the rational to import decimal to implement the typecheck, or just assume that .as_tuple() does the right thing. These are just as optional as .from_float() though, so we can also leave them for future consideration. > * Automatic coercions to/from Decimal need to respect the active decimal > context. For example the result of Rational(3,11) + > Decimal('3.1415926') is context dependent and may not be commutative. Since I don't have any tests for that, I don't know whether it works. I suspect it currently returns a float! :) What do you want it to do? Unfortunately, giving it any special behavior reduces the value of the class as an example of falling back to floats, but that shouldn't necessarily stop us from making it do the right thing. > * When in doubt, keep the API minimal so we don't lock-in design mistakes. Absolutely! > * Test the API by taking a few numerical algorithms and seeing how well > they work with rational inputs (for starters, try > http://docs.python.org/lib/decimal-recipes.html ). Good idea. I'll add some of those to the test suite. > * If you do put in a method that accepts floats, make sure that it can > accept arguments to control the rational approximation. Ideally, you > would get something something like this Rational.approximate(math.pi, 6) > --> 355/113 that could produce the smallest rationalal approximation to > a given level of accuracy. Right. My initial plan was to use Rational.from_float(math.pi).simplest_fraction_within(Rational(1, 10**6)) but I'm not set on that, and, because there are several choices for the approximation method, I'm skeptical whether it should go into the initial revision at all. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 02:28:54 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Jan 2008 01:28:54 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1199928534.49.0.194044915103.issue1780@psf.upfronthosting.co.za> Mark Dickinson added the comment: Okay: in that case, I propose: (1) adding a to_number method to the Decimal and Context class, so that we're still in full compliance with the specification, and (2) altering Decimal.__new__ to allow trailing and leading whitespace. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 02:50:11 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Jan 2008 01:50:11 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1199929810.99.0.45146133332.issue1780@psf.upfronthosting.co.za> Mark Dickinson added the comment: Aargh! It's only the Context class that needs a to_number method---it makes no sense as a Decimal method. And to_number is almost already there, in the form of Context.create_decimal. I'll work out exactly what the minimum is that needs to be done to comply with the specification, and post a patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 02:54:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 10 Jan 2008 01:54:41 -0000 Subject: [issue1720992] automatic imports Message-ID: <1199930081.18.0.987063658453.issue1720992@psf.upfronthosting.co.za> Christian Heimes added the comment: The idea is against the basic principals and Zen Of Python (type "import this at the Python prompt to read more about the Zen Of Python). Ralf's link about autoimp is a nice solution but don't ever use it in real code! ---------- nosy: +tiran resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 10 02:55:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 10 Jan 2008 01:55:51 -0000 Subject: [issue1448325] re search infinite loop Message-ID: <1199930151.92.0.657701387655.issue1448325@psf.upfronthosting.co.za> Christian Heimes added the comment: Duplicate and partly fixed ---------- nosy: +tiran resolution: -> duplicate status: open -> closed superseder: -> Check for signals during regular expression matches _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 10 02:58:47 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 10 Jan 2008 01:58:47 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1199930327.74.0.944846044889.issue1682@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Decimal.from_rational(Rat(1, 3)) wouldn't be lossless It should be implemented as Decimal(1)/Decimal(3) and then let the context handle any inexactness. > Rational.from_decimal is easier than from_float. Yes. Just use Decimal.as_tuple() to get the integer components. > Then Decimal.from_rational() could rely on just numbers. > Rational, so it would be independent of this module. >Is that a method you'd want on Decimal anyway? Instead, just expand the decimal constructor to accept a rational input. > Regarding float->rational, I propose to refuse Rational(1.1) > for the same reasons as Decimal(1.1) is refused, +1 > but to add a separate constructor (a class method?) that > converts a float to a rational exactly (as long as it > isn't nan or inf), large denominators be damned. This > can help people who are interested in taking floating > point numbers apart. Here's how to pick the integer components out of a float: mant, exp = math.frexp(x) mant, exp = int(mant * 2.0 ** 53), exp-53 >> * Likewise, follow decimal's lead in avoiding all >> automatic coercions from floats: >> Rational(3,10) + 0.3 for example. The two don't mix. > I'm reluctant to remove the fallback to float, You will need some plan to scale-down long integers than exceed the range of floats (right shifting the numerator and denominator until they fit). __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 03:01:14 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 10 Jan 2008 02:01:14 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1199930473.97.0.416024191265.issue1682@psf.upfronthosting.co.za> Raymond Hettinger added the comment: One other thought, the Decimal and Rational constructors can be made to talk to each other via a magic method so that neither has to import the other (somewhat like we do now with __int__ and __float__). __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 03:42:50 2008 From: report at bugs.python.org (Tim Lesher) Date: Thu, 10 Jan 2008 02:42:50 -0000 Subject: [issue1781] ConfigParser: add_section('DEFAULT') causes duplicate sections. In-Reply-To: <1199932970.3.0.196882211496.issue1781@psf.upfronthosting.co.za> Message-ID: <1199932970.3.0.196882211496.issue1781@psf.upfronthosting.co.za> New submission from Tim Lesher: ConfigParser doesn't prevent "manually" adding a section named DEFAULT; however, doing so creates a duplicate, inaccessible [DEFAULT] section in the config file: ---- >>> import sys, ConfigParser >>> c = ConfigParser.ConfigParser() >>> c.add_section('DEFAULT') >>> c.write(sys.stdout) [DEFAULT] >>> c.set('DEFAULT', 'color', 'yellow') >>> c.write(sys.stdout) [DEFAULT] color = yellow [DEFAULT] ---- It seems that the correct thing to do would be to disallow add_section('DEFAULT'). ---------- components: Library (Lib) messages: 59652 nosy: tlesher severity: normal status: open title: ConfigParser: add_section('DEFAULT') causes duplicate sections. type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 04:00:12 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2008 03:00:12 -0000 Subject: [issue1781] ConfigParser: add_section('DEFAULT') causes duplicate sections. In-Reply-To: <1199932970.3.0.196882211496.issue1781@psf.upfronthosting.co.za> Message-ID: <1199934012.87.0.575980096394.issue1781@psf.upfronthosting.co.za> Guido van Rossum added the comment: Care to provide a patch? Otherwise this may be a good bug day candidate. The next one's Jan 19. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 04:10:36 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Jan 2008 03:10:36 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1199934636.55.0.591981289941.issue1780@psf.upfronthosting.co.za> Mark Dickinson added the comment: In the spirit of making the Decimal constructor match the rest of the language, can I propose another change: make Decimal("not a decimal") raise a ValueError. Currently, Decimal("not a decimal") either raises InvalidOperation or returns a Decimal NaN, depending on whether the InvalidOperation trap is set in the current context or not. This behaviour presumably again comes directly from the specification, but as pointed out already Decimal.__new__ doesn't need to rigidly follow the specification---we just need to make sure that the functionality of to-number is present somewhere (and create_decimal seems like a good candidate for that). It seems to me that: Decimal.__new__ shouldn't care about the current context. The fact that __new__ takes a context parameter at the moment is potentially confusing: one might reasonably expect that passing a context to __new__ would result in the Decimal being rounded to fit that context (as happens with create_decimal). In fact, the *only* reason the context argument is there because it's needed to raise InvalidOperation; if the first argument to __new__ is valid then the context is entirely unused. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 04:29:39 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 10 Jan 2008 03:29:39 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1199935779.54.0.530591253934.issue1780@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think the decimal exceptions should continue to be raised as-is. There is a well-defined and thought-out structure for the Decimal exceptions. Also, the constructor's exceptions tend to be raised in an environment where there are other decimal operations taking place -- it would be a shame to have to catch both types of exception. I spent about a month working on this module and put a decent amount of thought into integrating the API. I would prefer to not revisit all of those decisions one at a time. Instead, let's graft on any new magic methods and fix straight-out bugs. Having lots of little microscopic API changes will harm more than it will help. Why introduce incompatabilities for no gain. I'm inclined to dismiss this whole bug report. It doesn't help anything to muck with the existing choices about whitespace handling. Recommend closing this as yagni / don't-care. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 04:51:17 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Jan 2008 03:51:17 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1199937077.11.0.78867968871.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: Allowing automatic coercion to and from Decimal sounds dangerous and complicated to me. Mightn't it be safer just to disallow this (at least for now)? I think something like trim() (find the closest rational approximation with denominator bounded by a given integer) would be useful to have as a Rational method, but probably only for explicit use. I'm still worried about equality tests: is it possible to give a good reason why Decimal("2.5") == Rational(5, 2) should return False, while Rational(5, 2) == 2.5 returns True. Can someone articulate some workable principle that dictates when an int/float/complex/Rational/Decimal instance compares equal to some other int/float/complex/Rational/Decimal instance of possibly different type but the same numerical value? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 05:35:38 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2008 04:35:38 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1199937077.11.0.78867968871.issue1682@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: All in all, Decimal is the odd man out -- it may never become a full member of the Real ABC. The built-in types complex, float and int (and long in 2.x) all support mixed-mode arithmetic, and this is one of the assumptions of the numeric tower -- and of course of mathematics. The new Rational type can be designed to fit in this system pretty easily, because it has no pre-existing constraints; but the Decimal type defies coercion, and is perhaps best left alone. It's already breaking the commonly understood properties of equality, e.g. 1.0 == 1 == Decimal("1") != 1.0. --Guido On Jan 9, 2008 7:51 PM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Allowing automatic coercion to and from Decimal sounds dangerous and > complicated to me. Mightn't it be safer just to disallow this (at least for > now)? > > I think something like trim() (find the closest rational approximation with > denominator bounded by a given integer) would be useful to have as a Rational > method, but probably only for explicit use. > > I'm still worried about equality tests: is it possible to give a good reason > why Decimal("2.5") == Rational(5, 2) should return False, while Rational(5, 2) > == 2.5 returns True. Can someone articulate some workable principle that > dictates when an int/float/complex/Rational/Decimal instance compares equal to > some other int/float/complex/Rational/Decimal instance of possibly different > type but the same numerical value? > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 05:52:19 2008 From: report at bugs.python.org (=?utf-8?q?Juan_Manuel_Borges_Ca=C3=83=C2=B1o?=) Date: Thu, 10 Jan 2008 04:52:19 -0000 Subject: [issue1720992] automatic imports Message-ID: <1199940739.5.0.416501432854.issue1720992@psf.upfronthosting.co.za> Juan Manuel Borges Ca??o added the comment: Thank you for the link. I think this bug is already closed. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 10 06:18:51 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 10 Jan 2008 05:18:51 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1199942331.54.0.892676209069.issue1682@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Would it be reasonable then to not have any of the numeric tower stuff put in the decimal module -- basically leave it alone (no __ceil__, etc)? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 13:09:48 2008 From: report at bugs.python.org (Facundo Batista) Date: Thu, 10 Jan 2008 12:09:48 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1199966988.34.0.585415323525.issue1780@psf.upfronthosting.co.za> Facundo Batista added the comment: I think that the Spec disallows additional whitespace to not allow, for example, "2. 34" as "2.34", or "10 e-12". I don't see any harm in having " 2.34" or "5.73\n" as good input values, as long we remove those characters at both ends. I propose to just make a .strip() at the input string, change the documentation to reflect this, and that's all. The doc says: "If value is a string, it should conform to the decimal numeric string syntax:" We can put: "If value is a string, it should conform to the decimal numeric string syntax after being stripped on both ends:" __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 13:31:45 2008 From: report at bugs.python.org (Nashev) Date: Thu, 10 Jan 2008 12:31:45 -0000 Subject: [issue1207589] Right Click Context Menu Message-ID: <1199968305.26.0.172690717355.issue1207589@psf.upfronthosting.co.za> Nashev added the comment: 1) in file EditorWindow.py 2 editings: a) remove selection-killer command on popup def right_menu_event(self, event): -- self.text.tag_remove("sel", "1.0", "end") b) add ability to make separators in popup menu def make_rmenu(self): rmenu = Menu(self.text, tearoff=0) for label, eventname in self.rmenu_specs: ++ if label != "-": def command(text=self.text, eventname=eventname): text.event_generate(eventname) rmenu.add_command(label=label, command=command) ++ else: ++ rmenu.add_separator() self.rmenu = rmenu 2) in PyShell.py extend rmenu_specs rmenu_specs = [ ++ ("Cut", "<>"), ++ ("Copy", "<>"), ++ ("Paste", "<>"), ++ ("-", ""), ("Set Breakpoint", "<>"), ("Clear Breakpoint", "<>") ] done... And now I can't find easy way to next two desired features: 1) disable cut/copy commands in case no selection (but it is not exists in main menu too) 2) display assigned hot keys in popup menu ---------- nosy: +Nashev _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 10 15:47:52 2008 From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=) Date: Thu, 10 Jan 2008 14:47:52 -0000 Subject: [issue1782] PyModule_AddIntConstant and PyModule_AddStringConstant can leak In-Reply-To: <1199976472.88.0.939409341911.issue1782@psf.upfronthosting.co.za> Message-ID: <1199976472.88.0.939409341911.issue1782@psf.upfronthosting.co.za> New submission from Hrvoje Nik?i?: PyModule_AddObject has somewhat strange reference-counting behavior in that it *conditionally* steals a reference. In case of error it doesn't change the reference to the passed object, but in case of success it steals it. This means that, as written, PyModule_AddIntConstant and PyModuleAddStringConstant can leak created objects if PyModule_AddObject fails. As far as I can tell, the correct way to write those functions would be (using PyModule_AddIntConstant as the example): int PyModule_AddIntConstant(PyObject *m, const char *name, long value) { PyObject *o = PyInt_FromLong(value); if (PyModule_AddObject(m, name, o) == 0) return 0; Py_XDECREF(o); return -1; } PyModule_AddObject was obviously intended to enable writing the "simple" code (it even gracefully handles being passed NULL object to add) like the one in PyModule_AddIntConstant, but I don't see a way to enable such usage and avoid both leaks and an interface change. Changing the reference-counting behavior of PyModule_AddObject would be backward-incompatible, but it might be a good idea to consider it for Python 3. If there is agreement that my analysis and the proposed fixes are correct, I will produce a proper patch. ---------- components: Interpreter Core messages: 59662 nosy: hniksic severity: normal status: open title: PyModule_AddIntConstant and PyModule_AddStringConstant can leak type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 16:54:22 2008 From: report at bugs.python.org (Jukka Laurila) Date: Thu, 10 Jan 2008 15:54:22 -0000 Subject: [issue1783] nonexistent data items declared as exports in sysmodule.h In-Reply-To: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za> Message-ID: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za> New submission from Jukka Laurila: sysmodule.h contains the following declarations for data to be exported from the Python DLL, but these variables don't seem to exist anywhere: PyAPI_DATA(PyObject *) _PySys_TraceFunc, *_PySys_ProfileFunc; PyAPI_DATA(int) _PySys_CheckInterval; Either the declarations should be removed or the variables should be defined somewhere. I'm proposing the former. ---------- components: Interpreter Core messages: 59663 nosy: jlaurila severity: normal status: open title: nonexistent data items declared as exports in sysmodule.h versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 17:10:16 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 10 Jan 2008 16:10:16 -0000 Subject: [issue1782] PyModule_AddIntConstant and PyModule_AddStringConstant can leak In-Reply-To: <1199976472.88.0.939409341911.issue1782@psf.upfronthosting.co.za> Message-ID: <1199981416.48.0.640283931769.issue1782@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks for your analysis! I *think* you are right but I've to study the code more carefully before I can make a decision. We can't target the change for 2.5 though. Guido would accuse my of being insane again. *g* The problem should be discussed at the upcoming bug day. ---------- nosy: +tiran priority: -> normal versions: +Python 2.6, Python 3.0 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 17:10:52 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2008 16:10:52 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1199942331.54.0.892676209069.issue1682@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Would it be reasonable then to not have any of the numeric tower stuff > put in the decimal module -- basically leave it alone (no __ceil__, > etc)? If that's the preference of the decimal developers, sure. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 17:11:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 10 Jan 2008 16:11:10 -0000 Subject: [issue1781] ConfigParser: add_section('DEFAULT') causes duplicate sections. In-Reply-To: <1199932970.3.0.196882211496.issue1781@psf.upfronthosting.co.za> Message-ID: <1199981470.52.0.15058362805.issue1781@psf.upfronthosting.co.za> Christian Heimes added the comment: It's an easy task for the bug day unless you can provide a patch and an unit test earlier. ---------- nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 17:12:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 10 Jan 2008 16:12:58 -0000 Subject: [issue1783] nonexistent data items declared as exports in sysmodule.h In-Reply-To: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za> Message-ID: <1199981578.76.0.96978774701.issue1783@psf.upfronthosting.co.za> Christian Heimes added the comment: Sounds good to me. The vars were probably forgotten. The header files may contain more missing vars, too. ---------- nosy: +tiran priority: -> normal versions: +Python 3.0 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 17:22:47 2008 From: report at bugs.python.org (Stuart D Gathman) Date: Thu, 10 Jan 2008 16:22:47 -0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1199982167.95.0.904399620497.issue1025395@psf.upfronthosting.co.za> Changes by Stuart D Gathman: ---------- type: -> behavior _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 10 17:34:09 2008 From: report at bugs.python.org (Stuart D Gathman) Date: Thu, 10 Jan 2008 16:34:09 -0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1199982849.83.0.98101676998.issue1025395@psf.upfronthosting.co.za> Stuart D Gathman added the comment: # A quick and very dirty fix for common broken cases, with test cases. import rfc822 def parseaddr(t): """Split email into Fullname and address. >>> parseaddr('user at example.com') ('', 'user at example.com') >>> parseaddr('"Full Name" ') ('Full Name', 'foo at example.com') >>> parseaddr('spam at viagra.com ') ('spam at viagra.com', 'foo at example.com') >>> parseaddr('"God" <@hop1.org, at hop2.net:jeff at spec.org>') ('God', 'jeff at spec.org') """ #return email.Utils.parseaddr(t) res = rfc822.parseaddr(t) # dirty fix for some broken cases if not res[0]: pos = t.find('<') if pos > 0 and t[-1] == '>': addrspec = t[pos+1:-1] pos1 = addrspec.rfind(':') if pos1 > 0: addrspec = addrspec[pos1+1:] return rfc822.parseaddr('"%s" <%s>' % (t[:pos].strip(),addrspec)) if not res[1]: pos = t.find('<') if pos > 0 and t[-1] == '>': addrspec = t[pos+1:-1] pos1 = addrspec.rfind(':') if pos1 > 0: addrspec = addrspec[pos1+1:] return rfc822.parseaddr('%s<%s>' % (t[:pos].strip(),addrspec)) return res _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 10 17:37:38 2008 From: report at bugs.python.org (Stuart D Gathman) Date: Thu, 10 Jan 2008 16:37:38 -0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1199983058.73.0.776503492963.issue1025395@psf.upfronthosting.co.za> Stuart D Gathman added the comment: Ok, I see the '@' is technically not allowed in an atom. But it either needs to throw an invalid syntax exception, or heuristically return something reasonable. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 10 17:39:05 2008 From: report at bugs.python.org (Stuart D Gathman) Date: Thu, 10 Jan 2008 16:39:05 -0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1199983145.31.0.340478672037.issue1025395@psf.upfronthosting.co.za> Stuart D Gathman added the comment: Repeating because previous real life test case was rejected as 'spam': It also fails to parse: >>> from email.Utils import parseaddr >>> parseaddr('foo at spammer.com ') ('', 'foo at spammer.com') Getting the wrong part as the actual email to boot! Checked 2.4 and 2.5. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 10 18:09:52 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 10 Jan 2008 17:09:52 -0000 Subject: [issue1784] Error with OptionParser.parse_args() In-Reply-To: <1199984992.34.0.280732186134.issue1784@psf.upfronthosting.co.za> Message-ID: <1199984992.34.0.280732186134.issue1784@psf.upfronthosting.co.za> New submission from Raghuram Devarakonda: Sorry for the generic title but I couldn't think of a better one. My attempt to do "svn up && make" failed with the following exception from setup.py: ---------------------- File "./setup.py", line 314, in detect_modules if options.dirs: AttributeError: Values instance has no attribute 'dirs' ---------------------- I isolated the problem to a small script. ---------------------- import optparse parser = optparse.OptionParser() parser.add_option("-I", dest="dirs", action="append") options = parser.parse_args(['-I.', '-IInclude', '-I./Include'])[0] if options.dirs: print "opt = ", options.dirs ---------------------- When run with 2.5.1, the script prints "opt = ['.', 'Include', './Include']" but python from trunk gives the error: Traceback (most recent call last): File "../opttest.py", line 6, in if options.dirs: AttributeError: Values instance has no attribute 'dirs' ---------- components: Library (Lib) messages: 59672 nosy: draghuram severity: normal status: open title: Error with OptionParser.parse_args() type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 18:31:41 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2008 17:31:41 -0000 Subject: [issue1782] PyModule_AddIntConstant and PyModule_AddStringConstant can leak In-Reply-To: <1199976472.88.0.939409341911.issue1782@psf.upfronthosting.co.za> Message-ID: <1199986301.55.0.588300594314.issue1782@psf.upfronthosting.co.za> Guido van Rossum added the comment: These are meant purely for the convenience of module initialization, and there correct handling of reference counts in the light of failures is of marginal importance. So while these may technically have leaks, you shouldn't care. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 18:32:46 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 10 Jan 2008 17:32:46 -0000 Subject: [issue1784] Error with OptionParser.parse_args() In-Reply-To: <1199984992.34.0.280732186134.issue1784@psf.upfronthosting.co.za> Message-ID: <1199986366.87.0.794196233951.issue1784@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: It is my mistake. I modified optparse.py for an earlier issue and that change is the cause of the problem reported here. Please close it as invalid. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 18:35:46 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2008 17:35:46 -0000 Subject: [issue1784] Error with OptionParser.parse_args() In-Reply-To: <1199984992.34.0.280732186134.issue1784@psf.upfronthosting.co.za> Message-ID: <1199986546.4.0.706603895296.issue1784@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 18:39:32 2008 From: report at bugs.python.org (Dieter Maurer) Date: Thu, 10 Jan 2008 17:39:32 -0000 Subject: [issue1785] "inspect" gets broken by some descriptors In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za> Message-ID: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za> New submission from Dieter Maurer: The inspect functions "getmembers(cls)" and "classify_class_attrs(cls)" require that for a class *cls* each name in "dir(cls)" can be retrieved by "getattr(cls, name)". While this holds for usual class attributes, it may well fail for descriptors (descriptors set by 'zope.interface' are a real world example for this). Attached it as small script that demonstrates the problem. The bug affects 'pydoc' and the built in 'help' (which is in fact 'pydoc.help'). While 'pydoc' and 'help' do not break completely, they can not present meaningful information for classes with some descriptors ---------- components: Library (Lib) files: inspectBug.py messages: 59675 nosy: dmaurer severity: normal status: open title: "inspect" gets broken by some descriptors type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9117/inspectBug.py __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 18:58:33 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2008 17:58:33 -0000 Subject: [issue1785] "inspect" gets broken by some descriptors In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za> Message-ID: <1199987913.48.0.854076704767.issue1785@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please submit a patch. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 20:18:19 2008 From: report at bugs.python.org (Dieter Maurer) Date: Thu, 10 Jan 2008 19:18:19 -0000 Subject: [issue1785] "inspect" gets broken by some descriptors In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za> Message-ID: <1199992699.9.0.783525375183.issue1785@psf.upfronthosting.co.za> Dieter Maurer added the comment: In "dm.zdoc" (a "pydoc" wrapper for Zope) I simply filter out all names returned by "dir" which cannot be "getattr"ed. But, I am not sure, that this is good enough to be accepted as a patch (although it already improves upon the current state) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 20:45:40 2008 From: report at bugs.python.org (Eric Huss) Date: Thu, 10 Jan 2008 19:45:40 -0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1199862009.9.0.576661102944.issue1622@psf.upfronthosting.co.za> Message-ID: Eric Huss added the comment: Alan, your changes look good to me, but it is missing my patch in this bug that fixes the sign issue in _decodeExtra. While you're there, you might as well change the other 3 unpack lines to use a capital Q. -Eric __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 21:25:28 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 10 Jan 2008 20:25:28 -0000 Subject: [issue1781] ConfigParser: add_section('DEFAULT') causes duplicate sections. In-Reply-To: <1199932970.3.0.196882211496.issue1781@psf.upfronthosting.co.za> Message-ID: <1199996728.24.0.51277064081.issue1781@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Please see cfgparser.diff for the fix. It has tests and doc change. ---------- nosy: +draghuram Added file: http://bugs.python.org/file9118/cfgparser.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 21:32:49 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 10 Jan 2008 20:32:49 -0000 Subject: [issue1781] ConfigParser: add_section('DEFAULT') causes duplicate sections. In-Reply-To: <1199996728.24.0.51277064081.issue1781@psf.upfronthosting.co.za> Message-ID: <2c51ecee0801101232s38100239s14b7107ffb32ee39@mail.gmail.com> Raghuram Devarakonda added the comment: I should add that the patch disallows not only 'DEFAULT' but all other variants such as "Default" and "default". I am not entirely sure if my description of this behaviour as "DEFAULT or any of it's case-insensitive variants". __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 23:03:04 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 10 Jan 2008 22:03:04 -0000 Subject: [issue1761] Bug in re.sub() In-Reply-To: <1199784122.17.0.476084084614.issue1761@psf.upfronthosting.co.za> Message-ID: <1200002584.24.0.812665520398.issue1761@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This may be a surprising behaviour, but consistent with Perl and the pcre library. Added a sentence in documentation, and specific tests. Committed as r59896. ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 23:06:13 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 10 Jan 2008 22:06:13 -0000 Subject: [issue1472] Small bat files to build docs on Windows In-Reply-To: <1195529295.02.0.66501222215.issue1472@psf.upfronthosting.co.za> Message-ID: <1200002773.07.0.452408509723.issue1472@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This batch file is a good idea. I have two remarks: - it assumes that the python program is spelled "python25". This could be configurable. Something along: IF "%PYTHON%"=="" SET PYTHON=python25 Or is there a better way? - Also, I suggest to insert a SETLOCAL command on the second line of the script, so that the variables set in the script are restored at the end. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 10 23:24:06 2008 From: report at bugs.python.org (Alan McIntyre) Date: Thu, 10 Jan 2008 22:24:06 -0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za> Message-ID: <1200003846.3.0.258527715471.issue1622@psf.upfronthosting.co.za> Alan McIntyre added the comment: Thanks for the reminder, Eric; I'll include that and post the updated patch. As a side note, on OS X, running regrtest with -uall or -ulargefile still skips test_zipfile4 for some reason. I'll have a look at that before submitting the next version of the patch as well. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 00:25:26 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Jan 2008 23:25:26 -0000 Subject: [issue1785] "inspect" gets broken by some descriptors In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za> Message-ID: <1200007526.82.0.479963547737.issue1785@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is my attempt at a patch for this. It fixes inspect.getmembers and inspect.classify_class_attrs to work with Dieter's example. I hope it doesn't mess anything else. As for pydoc, things look a bit more complicated... The annoying thing is that the logic to browse object contents is duplicated inside the different renderers (pydoc.Repr subclasses). Also, I couldn't find any unit tests for pydoc. Are there any? ---------- nosy: +pitrou Added file: http://bugs.python.org/file9119/inspect-bug.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 00:25:32 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Jan 2008 23:25:32 -0000 Subject: [issue1785] "inspect" gets broken by some descriptors In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za> Message-ID: <1200007532.89.0.875442701904.issue1785@psf.upfronthosting.co.za> Changes by Antoine Pitrou: ---------- versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 01:19:30 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 11 Jan 2008 00:19:30 -0000 Subject: [issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2 In-Reply-To: <1198357772.97.0.682407228029.issue1688@psf.upfronthosting.co.za> Message-ID: <1200010770.13.0.303800445565.issue1688@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Isn't it enough to encode the prompt with the console encoding, instead of letting the default utf-8 conversion? This patch corrects the issue on Windows: Index: ../Python/bltinmodule.c =================================================================== --- ../Python/bltinmodule.c (revision 59843) +++ ../Python/bltinmodule.c (working copy) @@ -1358,12 +1358,19 @@ else Py_DECREF(tmp); if (promptarg != NULL) { - po = PyObject_Str(promptarg); + PyObject *stringpo = PyObject_Str(promptarg); + if (stringpo == NULL) { + Py_DECREF(stdin_encoding); + return NULL; + } + po = PyUnicode_AsEncodedString(stringpo, + PyUnicode_AsString(stdin_encoding), NULL); + Py_DECREF(stringpo); if (po == NULL) { Py_DECREF(stdin_encoding); return NULL; } - prompt = PyUnicode_AsString(po); + prompt = PyString_AsString(po); if (prompt == NULL) { Py_DECREF(stdin_encoding); Py_DECREF(po); __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 02:05:06 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Jan 2008 01:05:06 -0000 Subject: [issue1786] pdb should set stdin+stdout around exec call In-Reply-To: <1200013506.35.0.644025895195.issue1786@psf.upfronthosting.co.za> Message-ID: <1200013506.35.0.644025895195.issue1786@psf.upfronthosting.co.za> New submission from Guido van Rossum: When you type a command in pdb that happens to print something, the output goes to sys.stdout, even if self.stdout references another file. This makes it hard to debug code running inside a web server where sys.stdout/stdout are connected to a socket (or a WSGI wrapper file); the output "disappears" and ends up messing up the response. Attached is a fix that temporarily changes sys.stdin/stdout to the debugger's input and output. What do people think of this? ---------- components: Library (Lib) files: pdb.diff messages: 59686 nosy: gvanrossum priority: low severity: normal status: open title: pdb should set stdin+stdout around exec call type: behavior versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9120/pdb.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 02:05:11 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Jan 2008 01:05:11 -0000 Subject: [issue1786] pdb should set stdin+stdout around exec call In-Reply-To: <1200013506.35.0.644025895195.issue1786@psf.upfronthosting.co.za> Message-ID: <1200013511.69.0.519951246041.issue1786@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 02:13:33 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 11 Jan 2008 01:13:33 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1200014013.19.0.906897863019.issue1780@psf.upfronthosting.co.za> Mark Dickinson added the comment: Allowing leading and trailing whitespace causes failures in Cowlishaw's test suite. I guess Raymond's right: this bug report should be dismissed. It still bothers me a little that there isn't a strictly conforming implementation of to-number in decimal, but I can live with it. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 02:16:30 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Jan 2008 01:16:30 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1200014190.13.0.738023499667.issue1780@psf.upfronthosting.co.za> Guido van Rossum added the comment: > Allowing leading and trailing whitespace causes failures in Cowlishaw's > test suite. I guess Raymond's right: this bug report should be > dismissed. It still bothers me a little that there isn't a strictly > conforming implementation of to-number in decimal, but I can live with it. Not sure what you mean. Can't you fix the code to reject the trailing \n? Or are we talking about something else now? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 02:49:27 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 11 Jan 2008 01:49:27 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1200016167.31.0.330869270183.issue1780@psf.upfronthosting.co.za> Mark Dickinson added the comment: I can certainly fix the Decimal constructor to reject trailing newlines, if that's what people want, but that doesn't fit with the proposal to accept and strip leading and trailing whitespace. The other option that maintains full compliance with the specification is to do what we like with Decimal.__new__ (e.g. allowing leading and trailing whitespace), but make sure that there's a fully conforming to-number elsewhere in the Decimal module. I'm happy to make either of the above fixes, or to do nothing (which leaves us with a slightly buggy implementation of the specification---but probably not so that anyone would notice). I'll leave the decision of which of these three options is most desirable to the more seasoned developers. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 02:55:17 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Jan 2008 01:55:17 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1200016167.31.0.330869270183.issue1780@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I'd say that accepting a trailing \n is a bug that should be fixed. I think that ideally we'd be allowed to specify whitespace around the value. I am always annoyed at programs that require me to type e.g. an integer and don't let me put spaces before and/or after (which often happen due to copy/paste). See also bug #1779 BTW. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 02:56:04 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Jan 2008 01:56:04 -0000 Subject: [issue1779] int("- 1") is valud, but float("- 1") isn't. Which is right? In-Reply-To: <1199926803.21.0.243129638352.issue1779@psf.upfronthosting.co.za> Message-ID: <1200016564.41.0.304375899147.issue1779@psf.upfronthosting.co.za> Guido van Rossum added the comment: Moreover I think float is right and int is wrong. Something to fix in 3.0, probably not in 2.6 (don't want to break too much stuff that worked in 2.5). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 04:06:26 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 11 Jan 2008 03:06:26 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200020786.21.0.490444212115.issue1621@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Hm. I don't get any warning, related to the overflow issue, neither with -Wstrict-overflow=3, nor -Wstrict-overflow=5. Are the cPickle warnings already fixed? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 04:24:38 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 11 Jan 2008 03:24:38 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200021878.63.0.0908639613535.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Make sure you use gcc 4.3 trunk and at least -O2 is enabled. I tested revision 59895 from release25-maint branch. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 04:26:30 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 11 Jan 2008 03:26:30 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200021990.16.0.977254088313.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: FWIW gcc hacker Ian Lance Taylor has a nice article about signed overflow optimizations in gcc, see http://www.airs.com/blog/archives/120 . Reading that it might be better to use -fno-strict-overflow instead of -fwrapv. Regards, ismail __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 09:36:33 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 11 Jan 2008 08:36:33 -0000 Subject: [issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2 In-Reply-To: <1200010770.13.0.303800445565.issue1688@psf.upfronthosting.co.za> Message-ID: <47872A8D.10000@v.loewis.de> Martin v. L?wis added the comment: > Isn't it enough to encode the prompt with the console encoding, instead > of letting the default utf-8 conversion? This patch corrects the issue > on Windows: Sounds right. Technically, you should be using the stdout encoding, but I don't think it should ever differ from the stdin_encoding. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 09:43:38 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 11 Jan 2008 08:43:38 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1200021990.16.0.977254088313.issue1621@psf.upfronthosting.co.za> Message-ID: <47872C36.3060309@v.loewis.de> Martin v. L?wis added the comment: > FWIW gcc hacker Ian Lance Taylor has a nice article about signed > overflow optimizations in gcc, see http://www.airs.com/blog/archives/120 > . Reading that it might be better to use -fno-strict-overflow instead of > -fwrapv. Please be specific. I read it, and I don't think it's better to use -fno-strict-overflow. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 09:46:28 2008 From: report at bugs.python.org (Christian Theune) Date: Fri, 11 Jan 2008 08:46:28 -0000 Subject: [issue1787] segfault in obmalloc.c In-Reply-To: <1200041188.61.0.1232394323.issue1787@psf.upfronthosting.co.za> Message-ID: <1200041188.61.0.1232394323.issue1787@psf.upfronthosting.co.za> New submission from Christian Theune: Python 2.4.4 on Linux crashes with following backtrace. Application is a Zope server. The other threads seem to be idle at that moment, only the segfaulting thread gives a reasonable backtrace (see attachment). ---------- components: Interpreter Core files: backtrace messages: 59697 nosy: ctheune severity: critical status: open title: segfault in obmalloc.c type: crash versions: Python 2.4 Added file: http://bugs.python.org/file9121/backtrace __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 09:46:41 2008 From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=) Date: Fri, 11 Jan 2008 08:46:41 -0000 Subject: [issue1782] PyModule_AddIntConstant and PyModule_AddStringConstant can leak In-Reply-To: <1199976472.88.0.939409341911.issue1782@psf.upfronthosting.co.za> Message-ID: <1200041201.55.0.623119573332.issue1782@psf.upfronthosting.co.za> Hrvoje Nik?i? added the comment: I agree that a leak would very rarely occur in practice, but since there is a straightforward fix, why not apply it? If nothing else, the code in the core should be an example of writing leak-free Python/C code, and a fix will also prevent others from wasting time on this in the future. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 10:47:53 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 11 Jan 2008 09:47:53 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200044873.4.0.460554702035.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Ian says -fno-strict-overflow still allows some optimizations, and his example code shows less assembly is produced with -fno-strict-overflow. But of course your opinion matters on this one, not mine. Regards, ismail __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 11:23:41 2008 From: report at bugs.python.org (Rich) Date: Fri, 11 Jan 2008 10:23:41 -0000 Subject: [issue1743] IDLE fails to launch In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za> Message-ID: <1200047021.85.0.879439413309.issue1743@psf.upfronthosting.co.za> Rich added the comment: I can't get it to do it again. Unless someone else is still experiencing the problem, perhaps it was fixed (deliberately or otherwise) by this month's Vista hotfixes that came down automatically a couple of days ago. Thanks for your help everyone. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 11:31:06 2008 From: report at bugs.python.org (Rich) Date: Fri, 11 Jan 2008 10:31:06 -0000 Subject: [issue1544] IDLE installation problems and no message errors In-Reply-To: <1196658687.21.0.152111885524.issue1544@psf.upfronthosting.co.za> Message-ID: <1200047466.83.0.991989550159.issue1544@psf.upfronthosting.co.za> Rich added the comment: If you are using Vista, then we discovered that there might be a problem associated with the recent-files.lst file (usually found in .idle in the C:\Users\Yourname directory). That's all written down in Issue 1743. If that doesn't apply to you then if you specify what version of Windows you are using, and what ways you have tried of opening IDLE, and hopefully someone cleverer than me will get back to you... ---------- nosy: +richjtd __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 12:22:46 2008 From: report at bugs.python.org (Christopher Yeleighton) Date: Fri, 11 Jan 2008 11:22:46 -0000 Subject: [issue1788] Outdated link in the tutorial In-Reply-To: <1200050566.48.0.239641058268.issue1788@psf.upfronthosting.co.za> Message-ID: <1200050566.48.0.239641058268.issue1788@psf.upfronthosting.co.za> New submission from Christopher Yeleighton: The page "About Python Tutorial" incorrectly refers to the Python Bug Tracker at SourceForge as . That page says "This tracker is CLOSED. Please use the new tracker instead.". The new tracker is? guess where? At . ---------- components: Documentation messages: 59702 nosy: spe-anatol severity: minor status: open title: Outdated link in the tutorial type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 12:26:04 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 11 Jan 2008 11:26:04 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1200050764.08.0.187491491134.issue1780@psf.upfronthosting.co.za> Facundo Batista added the comment: Mark Dickinson: > The other option that maintains full compliance with the > specification is to do what we like with Decimal.__new__ > (e.g. allowing leading and trailing whitespace), but > make sure that there's a fully conforming to-number > elsewhere in the Decimal module. I'm +1 to be more permissive in the __new__ regarding spaces, tabs, and even newlines. I'm -0 to add an special module that does not allow this. I don't see the value of it more than be compliant to the standard in that particular sentence. Guido van Rossum: > I'd say that accepting a trailing \n is a bug that should > be fixed. > > I think that ideally we'd be allowed to specify whitespace > around the value. I am always annoyed at programs that require Do you want to be able to do Decimal("3 ") but not Decimal("3\n")? That confused me, I always read "whitespace" here as all these characters, as in the string module: >>> string.whitespace '\t\n\x0b\x0c\r ' To be more practical about my point, I'm +1 to do a .strip() in __new__ before parsing the number. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 12:31:13 2008 From: report at bugs.python.org (Christopher Yeleighton) Date: Fri, 11 Jan 2008 11:31:13 -0000 Subject: [issue1789] incorrect assumption about unsigned long byte size In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za> Message-ID: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za> New submission from Christopher Yeleighton: Text of section 11.3 "Working with Binary Data Record Layouts" at incorrectly assumes that unsigned long is 4 bytes long (with pack codes "H" and "L" representing two and four byte unsigned numbers respectively). It is may be a valid description of the author?s environment, but it is invalid as a general statement and it creates the wrong impression that the sample programme is portable and ready-to-go. ---------- components: Documentation messages: 59704 nosy: spe-anatol severity: normal status: open title: incorrect assumption about unsigned long byte size type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 12:42:12 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 11 Jan 2008 11:42:12 -0000 Subject: [issue1788] Outdated link in the tutorial In-Reply-To: <1200050566.48.0.239641058268.issue1788@psf.upfronthosting.co.za> Message-ID: <1200051732.74.0.510779517895.issue1788@psf.upfronthosting.co.za> Facundo Batista added the comment: Already fixed in the trunk and 2.5 maintenance branch. ---------- nosy: +facundobatista resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 14:24:20 2008 From: report at bugs.python.org (Vilya Harvey) Date: Fri, 11 Jan 2008 13:24:20 -0000 Subject: [issue1790] xmlrpclib ServerProxy page has out-of-date content In-Reply-To: <1200057860.28.0.108205643467.issue1790@psf.upfronthosting.co.za> Message-ID: <1200057860.28.0.108205643467.issue1790@psf.upfronthosting.co.za> New submission from Vilya Harvey: The page at 'http://docs.python.org/lib/serverproxy-objects.html' contains the following text which should be removed as it's (a) not especially relevant; and (b) out of date: "Introspection methods are currently supported by servers written in PHP, C and Microsoft .NET. Partial introspection support is included in recent updates to UserLand Frontier. Introspection support for Perl, Python and Java is available at the XML-RPC Hacks page." In particular: Python has built in introspection support now; and the URL for the XML-RPC hacks page returns a 404 error. ---------- components: Documentation messages: 59706 nosy: vilya severity: normal status: open title: xmlrpclib ServerProxy page has out-of-date content __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 14:27:34 2008 From: report at bugs.python.org (Vilya Harvey) Date: Fri, 11 Jan 2008 13:27:34 -0000 Subject: [issue1791] The Library Reference still refers to the old bug tracker. In-Reply-To: <1200058054.48.0.510848038146.issue1791@psf.upfronthosting.co.za> Message-ID: <1200058054.48.0.510848038146.issue1791@psf.upfronthosting.co.za> New submission from Vilya Harvey: The page at http://docs.python.org/lib/about.html refers people to the old SourceForge bug tracker, rather than bugs.python.org. ---------- messages: 59707 nosy: vilya severity: normal status: open title: The Library Reference still refers to the old bug tracker. versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 15:04:31 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 11 Jan 2008 14:04:31 -0000 Subject: [issue1791] The Library Reference still refers to the old bug tracker. In-Reply-To: <1200058054.48.0.510848038146.issue1791@psf.upfronthosting.co.za> Message-ID: <1200060271.51.0.197053571559.issue1791@psf.upfronthosting.co.za> Facundo Batista added the comment: Already fixed in trunk and 2.5 branch. ---------- nosy: +facundobatista resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 15:18:39 2008 From: report at bugs.python.org (Alan McIntyre) Date: Fri, 11 Jan 2008 14:18:39 -0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za> Message-ID: <1200061119.29.0.415081279499.issue1622@psf.upfronthosting.co.za> Alan McIntyre added the comment: Currently the extra field data is only parsed when it contains Zip64 extended information. It could probably be broken up into a list of (id, data) pairs at a minimum for all data types, since the spec says that's the structure that "should" be used. I don't know whether the results of that parse should be kept in a new slot; putting it in the ZipInfo.extra slot would probably be bad for 2.6, since users might be counting on the current behavior of a raw chunk of data still being there. Does anybody else have any suggestions for this? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 15:21:26 2008 From: report at bugs.python.org (Aaron Watters) Date: Fri, 11 Jan 2008 14:21:26 -0000 Subject: [issue1792] o(n*n) marshal.dumps performance for largish objects with patch In-Reply-To: <1200061286.09.0.117532205028.issue1792@psf.upfronthosting.co.za> Message-ID: <1200061286.09.0.117532205028.issue1792@psf.upfronthosting.co.za> New submission from Aaron Watters: Much to my surprise I found that one of my applications seemed to be running slow as a result of marshal.dumps. I think the culprit is the w_more(...) function, which grows the marshal buffer in 1k units. This means that a marshal of size 100k will have 100 reallocations and string copies. Other parts of Python (and java etc) have a proportional reallocation strategy which reallocates a new size based on the existing size. This mean a 100k marshal requires just 5 or so reallocations and string copies (n log n versus n**2 asymptotic performance). I humbly submit the following patch (based on python 2.6a0 source). I think it is a strict improvement on the existing code, but I've been wrong before (twice ;)). -- Aaron Watters ---------- components: Interpreter Core files: marshal.diff messages: 59710 nosy: aaron_watters severity: normal status: open title: o(n*n) marshal.dumps performance for largish objects with patch type: resource usage versions: Python 2.6 Added file: http://bugs.python.org/file9122/marshal.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 15:25:52 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 11 Jan 2008 14:25:52 -0000 Subject: [issue1792] o(n*n) marshal.dumps performance for largish objects with patch In-Reply-To: <1200061286.09.0.117532205028.issue1792@psf.upfronthosting.co.za> Message-ID: <1200061552.02.0.912767766485.issue1792@psf.upfronthosting.co.za> Facundo Batista added the comment: Why not just double the size? The "doubling + 1024" address some specific issue? If so, it should be commented. Also, do you have an example of a marshal.dumps() that suffers from this issue? Thank you! ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 15:54:16 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 Jan 2008 14:54:16 -0000 Subject: [issue1785] "inspect" gets broken by some descriptors In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za> Message-ID: <1200063256.31.0.849302983576.issue1785@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For the record the same problem also happens with toscawidgets. >>> from toscawidgets.widgets.forms import validators >>> help(validators) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/site.py", line 351, in __call__ return pydoc.help(*args, **kwds) File "/usr/lib/python2.5/pydoc.py", line 1646, in __call__ self.help(request) File "/usr/lib/python2.5/pydoc.py", line 1690, in help else: doc(request, 'Help on %s:') File "/usr/lib/python2.5/pydoc.py", line 1481, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "/usr/lib/python2.5/pydoc.py", line 324, in document if inspect.ismodule(object): return self.docmodule(*args) File "/usr/lib/python2.5/pydoc.py", line 1072, in docmodule contents.append(self.document(value, key, name)) File "/usr/lib/python2.5/pydoc.py", line 325, in document if inspect.isclass(object): return self.docclass(*args) File "/usr/lib/python2.5/pydoc.py", line 1173, in docclass classify_class_attrs(object)) File "/usr/lib/python2.5/pydoc.py", line 179, in classify_class_attrs return map(fixup, inspect.classify_class_attrs(object)) File "/usr/lib/python2.5/inspect.py", line 246, in classify_class_attrs obj = getattr(cls, name) File "/usr/lib/python2.5/site-packages/FormEncode-0.7.1-py2.5.egg/formencode/declarative.py", line 105, in __get__ obj = type.singleton() File "/usr/lib/python2.5/site-packages/FormEncode-0.7.1-py2.5.egg/formencode/declarative.py", line 166, in singleton setattr(cls, name, cls(declarative_count=cls.declarative_count)) TypeError: __init__() got an unexpected keyword argument 'declarative_count' __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 15:59:38 2008 From: report at bugs.python.org (Thomas Heller) Date: Fri, 11 Jan 2008 14:59:38 -0000 Subject: [issue1793] ctypes.util.find_msvcrt() function In-Reply-To: <1200063578.88.0.774833430715.issue1793@psf.upfronthosting.co.za> Message-ID: <1200063578.88.0.774833430715.issue1793@psf.upfronthosting.co.za> New submission from Thomas Heller: I'm uploading this patch for discussion, in case someone cares. This code (for Windows) adds a function ctypes.util.find_msvcrt(). This function returns the filename of the MSVC runtime library that the current Python executable uses. If calling functions from the C runtime library, it is very important to use the SAME dll that Python uses. Further, this patch changes ctypes.util.find_library(name) so that the MSVC runtime library name is returned when searching for "c" or "m". ---------- assignee: theller components: Extension Modules files: ctypes-util.patch keywords: patch messages: 59713 nosy: theller severity: normal status: open title: ctypes.util.find_msvcrt() function type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9123/ctypes-util.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 16:07:51 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Fri, 11 Jan 2008 15:07:51 -0000 Subject: [issue1472] Small bat files to build docs on Windows In-Reply-To: <1195529295.02.0.66501222215.issue1472@psf.upfronthosting.co.za> Message-ID: <1200064071.01.0.0820097566598.issue1472@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Is referencing the built python binary in the build tree a good idea? Just in case they do not have python installed on the system already? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 16:14:59 2008 From: report at bugs.python.org (Aaron Watters) Date: Fri, 11 Jan 2008 15:14:59 -0000 Subject: [issue1792] o(n*n) marshal.dumps performance for largish objects with patch In-Reply-To: <1200061552.02.0.912767766485.issue1792@psf.upfronthosting.co.za> Message-ID: Aaron Watters added the comment: Facundo 1) the +1024 was an accelerator to jump up to over 1k at the first resize. I think it's a good idea or at least doesn't hurt. 2) Here is an example program: def test(): from marshal import dumps from time import time testString = "abc"*100000000 print "now testing" now = time() dump = dumps(testString) elapsed = time()-now print "elapsed", elapsed if __name__=="__main__": test() Here are two runs: the first with the old marshal and the second with the patched marshal. The second is better than 2* faster than the first. arw:/home/arw/test> ~/apache2/htdocs/pythonsrc/Python/python_old mtest1.py now testing elapsed 4.13367795944 arw:/home/arw/test> ~/apache2/htdocs/pythonsrc/Python/python mtest1.py now testing elapsed 1.7495341301 arw:/home/arw/test> The example that inspired this research was very complicated and involved millions of calls to dumps which caused a number of anomalies (system calls went berzerk for some reason, maybe paging). -- Aaron Watters On Jan 11, 2008 9:25 AM, Facundo Batista wrote: > > Facundo Batista added the comment: > > Why not just double the size? The "doubling + 1024" address some > specific issue? If so, it should be commented. > > Also, do you have an example of a marshal.dumps() that suffers from this > issue? > > Thank you! > > ---------- > nosy: +facundobatista > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9124/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080111/6ffa3a93/attachment.txt From report at bugs.python.org Fri Jan 11 16:15:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 15:15:32 -0000 Subject: [issue1782] PyModule_AddIntConstant and PyModule_AddStringConstant can leak In-Reply-To: <1199976472.88.0.939409341911.issue1782@psf.upfronthosting.co.za> Message-ID: <1200064532.83.0.248068325863.issue1782@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't mind if you like to pursue the issue. I won't invest any time into it. But if you can come up with a patch we can surely apply it. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 16:17:33 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 15:17:33 -0000 Subject: [issue1472] Small bat files to build docs on Windows In-Reply-To: <1200064071.01.0.0820097566598.issue1472@psf.upfronthosting.co.za> Message-ID: <4787888A.9010103@cheimes.de> Christian Heimes added the comment: Joseph Armbruster wrote: > Is referencing the built python binary in the build tree a good idea? > Just in case they do not have python installed on the system already? The doc builder requires Python 2.5 and *may* work with 2.6 but definitely not with 3.x. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 16:20:25 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Fri, 11 Jan 2008 15:20:25 -0000 Subject: [issue1472] Small bat files to build docs on Windows In-Reply-To: <1195529295.02.0.66501222215.issue1472@psf.upfronthosting.co.za> Message-ID: <1200064825.0.0.155418422104.issue1472@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Ah, good to know :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 17:21:47 2008 From: report at bugs.python.org (Aaron Watters) Date: Fri, 11 Jan 2008 16:21:47 -0000 Subject: [issue1792] o(n*n) marshal.dumps performance for largish objects with patch In-Reply-To: Message-ID: Aaron Watters added the comment: also: I just modified the code to do iterations using increasingly large data sizes and I see the kind of very unpleasant behaviour for the old implementation (max time varies wildly from min time) that I saw in my more complex program. The new implementation doesn't have these problems. First the runs and then the modified code runs arw:/home/arw/test> arw:/home/arw/test> ~/apache2/htdocs/pythonsrc/Python/python_old mtest1.pyold old 0 40 elapsed max= 2.28881835938e-05 min= 4.76837158203e-06 ratio= 4.8 1 160 elapsed max= 1.59740447998e-05 min= 9.05990600586e-06 ratio= 1.76315789474 2 640 elapsed max= 2.40802764893e-05 min= 2.19345092773e-05 ratio= 1.09782608696 3 2560 elapsed max= 8.79764556885e-05 min= 3.981590271e-05 ratio= 2.20958083832 4 10240 elapsed max= 0.000290155410767 min= 0.000148057937622 ratio= 1.95974235105 5 40960 elapsed max= 0.000867128372192 min= 0.00060510635376 ratio= 1.43301812451 6 163840 elapsed max= 0.00739598274231 min= 0.00339317321777 ratio= 2.17966554244 7 655360 elapsed max= 0.0883929729462 min= 0.0139379501343 ratio= 6.34189189189 8 2621440 elapsed max= 1.69851398468 min= 0.0547370910645 ratio= 31.0304028155 9 10485760 elapsed max= 9.98945093155 min= 0.213104963303 ratio= 46.875730986 10 41943040 elapsed max= 132.281101942 min= 0.834150075912 ratio= 158.581897625 arw:/home/arw/test> ~/apache2/htdocs/pythonsrc/Python/python mtest1.py new new 0 40 elapsed max= 2.19345092773e-05 min= 5.00679016113e-06 ratio= 4.38095238095 1 160 elapsed max= 1.00135803223e-05 min= 9.05990600586e-06 ratio= 1.10526315789 2 640 elapsed max= 3.19480895996e-05 min= 1.28746032715e-05 ratio= 2.48148148148 3 2560 elapsed max= 5.69820404053e-05 min= 3.981590271e-05 ratio= 1.43113772455 4 10240 elapsed max= 0.000186920166016 min= 0.000138998031616 ratio= 1.34476843911 5 40960 elapsed max= 0.00355315208435 min= 0.000746965408325 ratio= 4.75678263645 6 163840 elapsed max= 0.00326490402222 min= 0.00304794311523 ratio= 1.07118272841 7 655360 elapsed max= 0.0127630233765 min= 0.0122020244598 ratio= 1.04597588855 8 2621440 elapsed max= 0.0511522293091 min= 0.0484230518341 ratio= 1.05636112082 9 10485760 elapsed max= 0.198891878128 min= 0.187420129776 ratio= 1.06120873124 10 41943040 elapsed max= 0.758435964584 min= 0.729014158249 ratio= 1.04035834696 arw:/home/arw/test> Above high ratio numbers indicate strange and unpleasant performance variance. For iteration 7 and higher the old implementation has a much worse max time performance than the new one. Here is the test code: def test(): from marshal import dumps from time import time size = 10 for i in range(11): size = size*4 testString = "abc"*size #print "now testing", i, size minelapsed = None for j in range(11): now = time() dump = dumps(testString) elapsed = time()-now if minelapsed is None: minelapsed = elapsed maxelapsed = elapsed else: minelapsed = min(elapsed, minelapsed) maxelapsed = max(elapsed, maxelapsed) print i, size, "elapsed max=", maxelapsed, "min=", minelapsed, "ratio=", maxelapsed/minelapsed if __name__=="__main__": import sys print sys.argv[1] test() -- Aaron Watters On Jan 11, 2008 10:14 AM, Aaron Watters < report at bugs.python.org> wrote: > > Aaron Watters added the comment: > > Facundo > > 1) the +1024 was an accelerator to jump up to over 1k at the first resize. > I think it's a good idea or at least doesn't hurt. > > 2) Here is an example program: > > def test(): > from marshal import dumps > from time import time > testString = "abc"*100000000 > print "now testing" > now = time() > dump = dumps(testString) > elapsed = time()-now > print "elapsed", elapsed > > if __name__=="__main__": > test() > > Here are two runs: the first with the old marshal and the second with the > patched marshal. The second is > better than 2* faster than the first. > > arw:/home/arw/test> ~/apache2/htdocs/pythonsrc/Python/python_old mtest1.py > now testing > elapsed 4.13367795944 > arw:/home/arw/test> ~/apache2/htdocs/pythonsrc/Python/python mtest1.py > now testing > elapsed 1.7495341301 > arw:/home/arw/test> > > The example that inspired this research was very complicated and involved > millions of calls to dumps > which caused a number of anomalies (system calls went berzerk for some > reason, maybe paging). > > -- Aaron Watters > > On Jan 11, 2008 9:25 AM, Facundo Batista wrote: > > > > > Facundo Batista added the comment: > > > > Why not just double the size? The "doubling + 1024" address some > > specific issue? If so, it should be commented. > > > > Also, do you have an example of a marshal.dumps() that suffers from this > > issue? > > > > Thank you! > > > > ---------- > > nosy: +facundobatista > > > > __________________________________ > > Tracker > > > > __________________________________ > > > > Added file: http://bugs.python.org/file9124/unnamed > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9125/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080111/f50e5c47/attachment-0001.txt From report at bugs.python.org Fri Jan 11 17:58:18 2008 From: report at bugs.python.org (Nashev) Date: Fri, 11 Jan 2008 16:58:18 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> New submission from Nashev: In most platform-depended applications hot keys are working by the specified keys on a keyboard, independent of a current keyboard layout. Not by the specified char. Some application menus is displaying keyboard shortcut localized to main layout for current language. But still working in any layout of keyboard currently selected. IDLE is not. :( Can any one do something with it unpleasant situation? ---------- components: IDLE, Tkinter messages: 59720 nosy: Nashev severity: normal status: open title: Hot keys must work in any keyboard layout versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 18:09:25 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 11 Jan 2008 17:09:25 -0000 Subject: [issue1472] Small bat files to build docs on Windows In-Reply-To: <4787888A.9010103@cheimes.de> Message-ID: <4787A2AE.4030909@gmx.net> Georg Brandl added the comment: Christian Heimes schrieb: > Christian Heimes added the comment: > > Joseph Armbruster wrote: >> Is referencing the built python binary in the build tree a good idea? >> Just in case they do not have python installed on the system already? > > The doc builder requires Python 2.5 and *may* work with 2.6 but > definitely not with 3.x. It should work with 2.6 without problems. 3k compatibility is another story, of course :) ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 18:26:22 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Jan 2008 17:26:22 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1200072382.45.0.750654709671.issue1794@psf.upfronthosting.co.za> Guido van Rossum added the comment: Not being familiar with localized keyboards, I don't understand your question. Can you provide some screen dumps of what you see and explain what you expected to see? PS. What OS? ---------- nosy: +gvanrossum priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 18:30:32 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Jan 2008 17:30:32 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1200072632.38.0.740292085853.issue1780@psf.upfronthosting.co.za> Guido van Rossum added the comment: > Do you want to be able to do Decimal("3 ") but not Decimal("3\n")? I want either both or none, with a slight preference for both but only if it can be done without breaking the spec. The status quo is that "3 " is refused but "3\n" is accepted; that seems wrong. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 18:31:22 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 17:31:22 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1200072682.0.0.269546496758.issue1794@psf.upfronthosting.co.za> Christian Heimes added the comment: I *think* Nashev is talking about assigning hot keys by scan code rather than by character code. E.g. on a German keyboard the 'z' and 'y' are switched and the 'z' key is left to the 't' key. If a program assigns a hot key to 'z' by character code than the user has to press the 'z' key which is a different key on the German keyboard. However if a hot key is assigned by scan code (not sure if it's the right term) than the hot key is still assigned the physical key in the lower left corner. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 18:33:13 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Jan 2008 17:33:13 -0000 Subject: [issue1787] segfault in obmalloc.c In-Reply-To: <1200041188.61.0.1232394323.issue1787@psf.upfronthosting.co.za> Message-ID: <1200072793.81.0.405977095832.issue1787@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, there's just no way that this is going to be dealt with on the Python core tracker. Who says it isn't memory corruption caused by some Zope extension module... ---------- nosy: +gvanrossum resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 18:34:36 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Jan 2008 17:34:36 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1200072876.82.0.988062191532.issue1794@psf.upfronthosting.co.za> Guido van Rossum added the comment: So what's a hot key? Now I'm really confused. I don't recall anything using scan codes in IDLE, at least not for the memory shortcuts etc. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 18:36:57 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 11 Jan 2008 17:36:57 -0000 Subject: [issue1560327] copy() method of dictionaries is not "deep" Message-ID: <1200073016.99.0.857239194519.issue1560327@psf.upfronthosting.co.za> A.M. Kuchling added the comment: The Infogami FAQ is no longer available from python.org, so I'll just close this item. ---------- resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 11 18:41:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 17:41:21 -0000 Subject: [issue1793] ctypes.util.find_msvcrt() function In-Reply-To: <1200063578.88.0.774833430715.issue1793@psf.upfronthosting.co.za> Message-ID: <1200073281.86.0.930565253999.issue1793@psf.upfronthosting.co.za> Christian Heimes added the comment: In general I like the idea. But wouldn't it be better to have a cross platform function which returns the c runtime library? msvcrt?? on Windows, libc on Linux and whatever Mac and BSD are using. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 18:47:52 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 11 Jan 2008 17:47:52 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200072682.0.0.269546496758.issue1794@psf.upfronthosting.co.za> Message-ID: <4787AB32.7010604@gmx.net> Georg Brandl added the comment: Christian Heimes schrieb: > Christian Heimes added the comment: > > I *think* Nashev is talking about assigning hot keys by scan code rather > than by character code. > > E.g. on a German keyboard the 'z' and 'y' are switched and the 'z' key > is left to the 't' key. If a program assigns a hot key to 'z' by > character code than the user has to press the 'z' key which is a > different key on the German keyboard. However if a hot key is assigned > by scan code (not sure if it's the right term) than the hot key is still > assigned the physical key in the lower left corner. On which platforms do hotkeys have that behavior? I've never seen it. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 18:48:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 17:48:27 -0000 Subject: [issue1792] o(n*n) marshal.dumps performance for largish objects with patch In-Reply-To: <1200061286.09.0.117532205028.issue1792@psf.upfronthosting.co.za> Message-ID: <1200073707.74.0.727242909256.issue1792@psf.upfronthosting.co.za> Christian Heimes added the comment: It looks like a reasonable and good patch. Aaron's tests clearly show the speed up. However the maximum resize should be limited to a value around 256 to 1024k: size = min(2*size + 1024, 512*1024); ---------- keywords: +patch nosy: +tiran priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 18:50:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 17:50:52 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1200073852.74.0.838180419004.issue1794@psf.upfronthosting.co.za> Christian Heimes added the comment: > On which platforms do hotkeys have that behavior? I've never seen it. Some computer games define hot keys by scan code rather than by character. I'm not sure if it's a good idea for IDLE but for games it often makes sense. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 19:27:02 2008 From: report at bugs.python.org (Thomas Heller) Date: Fri, 11 Jan 2008 18:27:02 -0000 Subject: [issue1793] ctypes.util.find_msvcrt() function In-Reply-To: <1200063578.88.0.774833430715.issue1793@psf.upfronthosting.co.za> Message-ID: <1200076022.58.0.0251146901133.issue1793@psf.upfronthosting.co.za> Thomas Heller added the comment: The cross-platform function is ctypes.util.find_library, which is currently not very useful on Windows. This patch changes it so that, on Windows, find_library("c") or find_library("m") finds the MS C runtime lib which exposes functions the are typically in libc and libm. The runtime lib in Windows is special anyway; the 'open' function, for example, is exported as '_open'. However, the easiest way on Linux (don't know about other platforms) to load the C runtime lib is to use ctypes.CDLL(None), which translates to dlopen(NULL) in C. Linux exposes all symbols from all loaded libraries to the returned handle. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 19:27:16 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Fri, 11 Jan 2008 18:27:16 -0000 Subject: [issue1472] Small bat files to build docs on Windows In-Reply-To: <1195529295.02.0.66501222215.issue1472@psf.upfronthosting.co.za> Message-ID: <1200076036.75.0.54037963714.issue1472@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Which brings up a question. Would all things in the tree ideally work with the version that was built from checkout? Just in case something like this comes up in the future, i'd want to know if it is better to have it configured as this or to auto-magically point to the "right place" in the build tree for the python binary. Curiosity more than anything. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 19:27:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 18:27:32 -0000 Subject: [issue1795] PEP 754 update In-Reply-To: <1200076052.83.0.229945394685.issue1795@psf.upfronthosting.co.za> Message-ID: <1200076052.83.0.229945394685.issue1795@psf.upfronthosting.co.za> New submission from Christian Heimes: Hello Gregory! I've implemented some of your ideas of PEP 754 for Python 2.6. I like to update your PEP. Are you fine with the patch? ---------- components: Documentation files: pep-0754.txt.patch messages: 59734 nosy: tiran, warnes priority: normal severity: normal status: open title: PEP 754 update type: rfe versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9126/pep-0754.txt.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 20:08:48 2008 From: report at bugs.python.org (Stuart D Gathman) Date: Fri, 11 Jan 2008 19:08:48 -0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1200078528.4.0.418816326688.issue1025395@psf.upfronthosting.co.za> Stuart D Gathman added the comment: Same or related issues: Issue1221, Issue1409460 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 11 20:12:27 2008 From: report at bugs.python.org (Nashev) Date: Fri, 11 Jan 2008 19:12:27 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1200078747.06.0.0165019917492.issue1794@psf.upfronthosting.co.za> Nashev added the comment: WOW, so active discussion! OS - Windows & Mac OS X, both Programs - most system and many others. Keyboard layouts - I mean mostly non latin (see http://en.wikipedia.org/wiki/Keyboard_layout#Keyboard_layouts_for_non-Roman_alphabetic_scripts) In case of russian keyboard layout i have in place of latin char 'x' russian letter '?', and want to call <> command by pressing this hot key when keyboard really sent to application some like Ctrl+? too In Windows we have messages WM_KeyDown and WM_KeyUp that send always key index, stored as constants (defined in windows.h or messages.h) like wk_return, wk_F1, etc. For letter keys, messages come with codes that always equal to index of similar uppercase latin chars. for example, first key code in middle row equal ord ('A') = 65. And in context of russian layout this code translated to Cyrillic letter ? and sent to window with next message wm_char. Hot key handling based on WM_KeyDown, nor WM_Char P.S.: Samples of localized showing of the hot keys in menu based on interface language or current keyboard layout I can't find right now, but i remember that I have this experience. This is feature not necessary, because reading some like Ctrl+? near menu Cut is really frustrating. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 20:14:27 2008 From: report at bugs.python.org (Stuart D Gathman) Date: Fri, 11 Jan 2008 19:14:27 -0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1200078867.28.0.685302540556.issue1025395@psf.upfronthosting.co.za> Stuart D Gathman added the comment: Test cases so far: >>> parseaddr('user at example.com') ('', 'user at example.com') >>> parseaddr('"Full Name" ') ('Full Name', 'foo at example.com') >>> parseaddr('spam at spammer.com ') ('spam at spammer.com', 'foo at example.com') >>> parseaddr('God at heaven <@hop1.org, at hop2.net:jeff at spec.org>') ('God at heaven', 'jeff at spec.org') >>> parseaddr('Real Name ((comment)) ') ('Real Name', 'addr... at example.com') >>> parseaddr('a(WRONG)@b') ('', 'a at b') _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 11 20:17:08 2008 From: report at bugs.python.org (Thomas Heller) Date: Fri, 11 Jan 2008 19:17:08 -0000 Subject: [issue1796] ctypes should allow a tuple when an Array is expected In-Reply-To: <1200079028.65.0.512467714236.issue1796@psf.upfronthosting.co.za> Message-ID: <1200079028.65.0.512467714236.issue1796@psf.upfronthosting.co.za> New submission from Thomas Heller: Another ctypes patch for discussion, if someone cares. This patch allows to pass a tuple of the correct size, a ctypes pointer to the correct itemtype, or None to foreign functions that expect ctypes array instances. 'None' is passed as a NULL pointer. Currently, only array instances are accepted. ---------- assignee: theller components: Extension Modules files: ctypes-arrays.patch keywords: patch messages: 59738 nosy: theller severity: normal status: open title: ctypes should allow a tuple when an Array is expected type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9127/ctypes-arrays.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 20:30:55 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 11 Jan 2008 19:30:55 -0000 Subject: [issue1790] xmlrpclib ServerProxy page has out-of-date content In-Reply-To: <1200057860.28.0.108205643467.issue1790@psf.upfronthosting.co.za> Message-ID: <1200079855.46.0.234308994692.issue1790@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 20:33:52 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 11 Jan 2008 19:33:52 -0000 Subject: [issue1790] xmlrpclib ServerProxy page has out-of-date content In-Reply-To: <1200057860.28.0.108205643467.issue1790@psf.upfronthosting.co.za> Message-ID: <1200080032.45.0.458517278067.issue1790@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Text removed, and the link updated in rev. 59924. Thanks for reporting this! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 20:37:16 2008 From: report at bugs.python.org (Stuart D Gathman) Date: Fri, 11 Jan 2008 19:37:16 -0000 Subject: [issue1221] email.Utils.parseaddr("a(WRONG)@b") In-Reply-To: <1191155944.58.0.169174625904.issue1221@psf.upfronthosting.co.za> Message-ID: <1200080236.44.0.831969526295.issue1221@psf.upfronthosting.co.za> Stuart D Gathman added the comment: see Issue1029395 ---------- nosy: +sdgathman __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 20:38:27 2008 From: report at bugs.python.org (Stuart D Gathman) Date: Fri, 11 Jan 2008 19:38:27 -0000 Subject: [issue1221] email.Utils.parseaddr("a(WRONG)@b") In-Reply-To: <1191155944.58.0.169174625904.issue1221@psf.upfronthosting.co.za> Message-ID: <1200080307.44.0.351302626523.issue1221@psf.upfronthosting.co.za> Stuart D Gathman added the comment: See Issue1025395 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 20:58:45 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Jan 2008 19:58:45 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1200081525.91.0.322396585882.issue1794@psf.upfronthosting.co.za> Guido van Rossum added the comment: IDLE is written using Tkinter, not native Windows UI programming APIs, I don't know if the scan code is available in the keyboard events. If you want something to happen on this, I suggest you try to create a patch to IDLE yourself -- it's unlikely that any of the current developers has the time to figure this out, given that we don't have Russian keyboards nor Russian versions of Windows or Mac. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 21:20:16 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 Jan 2008 20:20:16 -0000 Subject: [issue1785] "inspect" gets broken by some descriptors In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za> Message-ID: <1200082816.33.0.971482611021.issue1785@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a (hopefully complete) patch against both pydoc and inspect. It fixes one more bug compared to the previous one (descriptors can also have a special __getattr__ in addition to __get__, which gave problems when trying to access __classobj__). Added file: http://bugs.python.org/file9128/inspect-and-pydoc-bug.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 21:34:58 2008 From: report at bugs.python.org (Thomas Heller) Date: Fri, 11 Jan 2008 20:34:58 -0000 Subject: [issue1797] ctypes NULL function pointers should have a False bool value. In-Reply-To: <1200083698.65.0.997886461661.issue1797@psf.upfronthosting.co.za> Message-ID: <1200083698.65.0.997886461661.issue1797@psf.upfronthosting.co.za> New submission from Thomas Heller: ctypes NULL function pointers should have a False bool value. ---------- assignee: theller components: Extension Modules files: ctypes-funcptr.patch keywords: patch messages: 59744 nosy: theller severity: normal status: open title: ctypes NULL function pointers should have a False bool value. type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9129/ctypes-funcptr.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 21:38:35 2008 From: report at bugs.python.org (Thomas Heller) Date: Fri, 11 Jan 2008 20:38:35 -0000 Subject: [issue1797] ctypes function pointer enhancements In-Reply-To: <1200083698.65.0.997886461661.issue1797@psf.upfronthosting.co.za> Message-ID: <1200083915.38.0.0775844687865.issue1797@psf.upfronthosting.co.za> Thomas Heller added the comment: The patch will be extended ASAP so that 'None' is accepted by foreign functions where a function pointer (callback function) is expected. For consistency it should be possible to call the ctypes function prototype with None to create a NULL callback function pointer. ---------- title: ctypes NULL function pointers should have a False bool value. -> ctypes function pointer enhancements __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 21:41:00 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Jan 2008 20:41:00 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1200084060.02.0.334134316281.issue1794@psf.upfronthosting.co.za> Raymond Hettinger added the comment: IDLE lets you configure your own mappings without doing any programming. >From the menu, pick Options, Configure Idle and goto the Keys tab. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 21:50:33 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Fri, 11 Jan 2008 20:50:33 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200084633.61.0.847700630556.issue1682@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: If the consensus is that Decimal should not implement Real, I'll reply to that thread and withdraw the patch. Raymond, do you want me to add Decimal.__init__(Rational) in this patch or another issue/thread? I don't understand the comment about scaling down long integers. It's already the case that float(Rational(10**23, 10**24 + 7))==0.1. Mark, I agree that .trim() and/or .approximate() (which I think is the same as Haskell's approxRational) would be really useful. Do you have particular reasons to pick .trim? Are those the best names for the concepts? I'd also really like to be able to link from their docstrings to a proof that their implementations are correct. Does anyone know of one? Finally, Decimal("2.5") != Rational(5, 2) because Decimal("2.5") != 2.5 (so it'd make equality even more intransitive) and hash(Decimal("2.5")) != hash(2.5) so we couldn't follow the rule about equal objects implying equal hash codes, which is probably more serious. I don't have a principled explanation for Decimal's behavior, but given that it's fixed, I think the behavior of non-integral Rationals is determined too. On the other hand, I currently have a bug where Rational(3,1) != Decimal("3") where the hash code could be consistent. I'll fix that by the next patch. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 21:51:37 2008 From: report at bugs.python.org (Thomas Heller) Date: Fri, 11 Jan 2008 20:51:37 -0000 Subject: [issue1798] Add ctypes calling convention that allows safe access of errno In-Reply-To: <1200084697.63.0.170138698691.issue1798@psf.upfronthosting.co.za> Message-ID: <1200084697.63.0.170138698691.issue1798@psf.upfronthosting.co.za> New submission from Thomas Heller: This patch adds new calling conventions to ctypes foreign functions by passing 'errno=True' or 'GetLastError=True' to the CDLL or WinDLL constructor. If CDLL(..., errno=True) or WinDLL(..., errno=True) is used, the function objects available in the CDLL or WinDLL instance will set the C global errno to zero before the actual call, and attach the C global errno value after the call as 'errno' attribute to the function object. This attribute is stored in thread-local storage. Similarly, if CDLL(..., GetLastError=True) or WinDLL(..., GetLastError=True) is used, the win32 api function 'SetLastError(0)' is used to reset the windows last error code before the actual call, and the value returned by 'GetLastError()' is attached as 'LastError' attribute to the function object, in thread local storage. Of course this only occurs on Windows. The LastError and errno attributes are readonly from Python code, accessing them before a foreign function call has occurred in the current thread raises a ValueError. ---------- assignee: theller components: Extension Modules files: ctypes-errno.patch keywords: patch messages: 59748 nosy: theller severity: normal status: open title: Add ctypes calling convention that allows safe access of errno type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9130/ctypes-errno.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 22:06:29 2008 From: report at bugs.python.org (Nashev) Date: Fri, 11 Jan 2008 21:06:29 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1200085589.54.0.637583468844.issue1794@psf.upfronthosting.co.za> Nashev added the comment: Guido, I think now it is must be suggestion to TK team, in they's issue tracker... Raymond, I know I can make try localized hot key mapping for my keyboard layout for my self, but i think the best way is - help to make our public libraries better for all. But any way, Thank You for try solve my local problem. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 22:12:00 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 11 Jan 2008 21:12:00 -0000 Subject: [issue1098749] Single-line option to pygettext.py Message-ID: <1200085920.17.0.47803687886.issue1098749@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Is this change still useful for 2.6? ---------- nosy: +akuchling versions: +Python 2.6 -Python 2.4 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 11 22:18:12 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 21:18:12 -0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1200086292.88.0.419494240482.issue1025395@psf.upfronthosting.co.za> Christian Heimes added the comment: An example from #1221: >>> email.Utils.parseaddr("a(WRONG)@b") ('WRONG WRONG', 'a at b') ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 11 22:18:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 21:18:32 -0000 Subject: [issue1221] email.Utils.parseaddr("a(WRONG)@b") In-Reply-To: <1191155944.58.0.169174625904.issue1221@psf.upfronthosting.co.za> Message-ID: <1200086312.17.0.585540847322.issue1221@psf.upfronthosting.co.za> Christian Heimes added the comment: Duplicated ---------- nosy: +tiran priority: -> normal resolution: -> duplicate status: open -> closed superseder: -> email.Utils.parseaddr fails to parse valid addresses __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 22:21:48 2008 From: report at bugs.python.org (Stuart D Gathman) Date: Fri, 11 Jan 2008 21:21:48 -0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1200086508.58.0.00293584530023.issue1025395@psf.upfronthosting.co.za> Stuart D Gathman added the comment: tiran: yes, but that is the wrong answer, and that example is already in the testcase list (with what I believe is the right answer). _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 11 22:23:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 21:23:29 -0000 Subject: [issue1799] Per user site-packages and setup.py install --user patch In-Reply-To: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za> Message-ID: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch adds a per user site-packages directory and a --user option for distutils' setup.py install. It also cleans up site.py a bit and makes addsitepackages() extensible. I'm going to write a mini PEP soonish. ---------- components: Distutils, Library (Lib) files: trunk_usersite.patch keywords: patch messages: 59754 nosy: tiran priority: normal severity: normal status: open title: Per user site-packages and setup.py install --user patch type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9131/trunk_usersite.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 22:26:09 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Jan 2008 21:26:09 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200086769.56.0.671574012292.issue1682@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > If the consensus is that Decimal should not implement Real, > I'll reply to that thread and withdraw the patch. Thanks. That would be nice. > Raymond, do you want me to add Decimal.__init__(Rational) > in this patch How about focusing on the rational module and when you've done, I'll adapt the Decimal constructor to accept a rational input. > I don't understand the comment about scaling down long integers. My understanding is that you're going to let numerators and denominators grow arbitrarily large. When they get over several hundred digits each, you will have to scale the down before converting to a float. For example when numerator=long('2'*400+'7') and denominator=long('3'*400+'1'), the long-->float conversion will overflow, so it is necessary to first scale-down the two before computing the ratio: scale=325; float_ratio=float(numerator>>scale)/float(denominator>>scale) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 22:27:52 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 11 Jan 2008 21:27:52 -0000 Subject: [issue1798] Add ctypes calling convention that allows safe access of errno In-Reply-To: <1200084697.63.0.170138698691.issue1798@psf.upfronthosting.co.za> Message-ID: <1200086872.52.0.872764863612.issue1798@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I like this way to tell that a function modifies errno or GetLastError. But this thread-local attribute on the function seems bizarre to me. I would prefer another way to get the errno. I can see two alternatives: - the function returns a tuple (normalresult, errno) on each call. - when errno is not zero, EnvironmentError (or WindowsError) is raised. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 11 23:32:39 2008 From: report at bugs.python.org (Nashev) Date: Fri, 11 Jan 2008 22:32:39 -0000 Subject: [issue1721083] Add File - Reload Message-ID: <1200090759.07.0.0399622584842.issue1721083@psf.upfronthosting.co.za> Nashev added the comment: It is very nice feature, that exists in many advanced and professional GUI-based editors on the Windows and Mac. For example, i can fast name TextWrangler, HomeSite, Flash, PhotoShop and it is only first names in mind. It feature for simplify tool's usage, it is improve GUI usability. ---------- nosy: +Nashev _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 11 23:36:37 2008 From: report at bugs.python.org (Nashev) Date: Fri, 11 Jan 2008 22:36:37 -0000 Subject: [issue1721083] Add File - Reload Message-ID: <1200090997.87.0.173631734033.issue1721083@psf.upfronthosting.co.za> Nashev added the comment: There are command in menu is called "Revert". P.S.: for knowing that file changed, programs in windows can register OS callback for this event and just react on it. In Mac i think too, but i don't know how with it on unix and python. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 00:15:00 2008 From: report at bugs.python.org (Lenard Lindstrom) Date: Fri, 11 Jan 2008 23:15:00 -0000 Subject: [issue1800] ctypes callback fails when called in Python with array argument In-Reply-To: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za> Message-ID: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za> New submission from Lenard Lindstrom: When a callback is created with an array argument and then is called from Python the callback function receives an array full of garbage. Here is an example: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> A = c_int * 1 >>> A >>> Foo = CFUNCTYPE(None, A) >>> def py_foo(a): ... print a ... print a[0] ... >>> foo = Foo(py_foo) >>> foo(A(42)) <__main__.c_long_Array_1 object at 0x00B54440> 11879448 It works correctly when the callback is declared with a pointer argument instead: >>> A = c_int * 1 >>> Foo = CFUNCTYPE(None, POINTER(c_int)) >>> def py_foo(p): ... print p ... print p[0] ... >>> foo = Foo(py_foo) >>> foo(A(42)) 42 ---------- components: Library (Lib), Windows messages: 59759 nosy: kermode severity: normal status: open title: ctypes callback fails when called in Python with array argument type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 00:31:39 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 11 Jan 2008 23:31:39 -0000 Subject: [issue1574217] isinstance swallows exceptions Message-ID: <1200094299.11.0.67569797135.issue1574217@psf.upfronthosting.co.za> Ralf Schmitt added the comment: The return value should be -1 in case of errors. There's also a second code path swallowing all errors. I've converted brian's test.py to a unit test testing both code paths and added an updated patch for this one. This patch is against trunk. All tests in Lib/test/test_isinstance.py pass. ---------- nosy: +schmir versions: +Python 2.6 Added file: http://bugs.python.org/file9132/issue1574217_dont_mask_errors.txt _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 00:41:43 2008 From: report at bugs.python.org (Matthias Kievernagel) Date: Fri, 11 Jan 2008 23:41:43 -0000 Subject: [issue961805] Text.edit_modified() fails Message-ID: <1200094903.91.0.72567045584.issue961805@psf.upfronthosting.co.za> Matthias Kievernagel added the comment: Retested revision 59927 from the trunk. Error is still there, is demonstrated by attached editModified.py (click 'modified?') and patch is still applicable and corrects the problem. Regards, Matthias Kievernagel ---------- versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 12 00:46:33 2008 From: report at bugs.python.org (David Gardner) Date: Fri, 11 Jan 2008 23:46:33 -0000 Subject: [issue1809] docs for os.symlink(src, dst) doesn't mention exceptions In-Reply-To: <1200095193.22.0.167933676219.issue1809@psf.upfronthosting.co.za> Message-ID: <1200095193.22.0.167933676219.issue1809@psf.upfronthosting.co.za> New submission from David Gardner: the docs for os.symlink at: http://docs.python.org/lib/os-file-dir.html don't mention if the function raises an exception if there was a file permission failure. ---------- components: Documentation files: symtest.py messages: 59762 nosy: dgardner severity: minor status: open title: docs for os.symlink(src, dst) doesn't mention exceptions type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9133/symtest.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 00:48:32 2008 From: report at bugs.python.org (David Gardner) Date: Fri, 11 Jan 2008 23:48:32 -0000 Subject: [issue1809] docs for os.symlink(src, dst) doesn't mention exceptions In-Reply-To: <1200095193.22.0.167933676219.issue1809@psf.upfronthosting.co.za> Message-ID: <1200095312.35.0.0871699022703.issue1809@psf.upfronthosting.co.za> David Gardner added the comment: the output of symtest.py looks like: (13, 'Permission denied') [Errno 13] Permission denied __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 00:53:09 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 11 Jan 2008 23:53:09 -0000 Subject: [issue1809] docs for os.symlink(src, dst) doesn't mention exceptions In-Reply-To: <1200095193.22.0.167933676219.issue1809@psf.upfronthosting.co.za> Message-ID: <1200095589.5.0.000814730728021.issue1809@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl nosy: +georg.brandl priority: -> normal versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 00:58:42 2008 From: report at bugs.python.org (Thomas Lee) Date: Fri, 11 Jan 2008 23:58:42 -0000 Subject: [issue1810] Partial AST compile() patch In-Reply-To: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za> Message-ID: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za> New submission from Thomas Lee: This patch against HEAD provides the inverse operations to all the ast2obj_* functions in Python/Python-ast.c: effectively, this allows conversion to & from a PyObject representation of a Python AST. Additionally, it updates the compile() builtin to allow it to compile Python ASTs to bytecode. The patch seems to work for most simple cases, but crashes out with a segfault when trying to compile functions for some reason. ---------- components: Interpreter Core files: ast-r01.patch messages: 59764 nosy: thomas.lee severity: normal status: open title: Partial AST compile() patch versions: Python 2.6 Added file: http://bugs.python.org/file9134/ast-r01.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 01:00:37 2008 From: report at bugs.python.org (Thomas Lee) Date: Sat, 12 Jan 2008 00:00:37 -0000 Subject: [issue1810] Partial AST compile() patch In-Reply-To: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za> Message-ID: <1200096037.63.0.930946240939.issue1810@psf.upfronthosting.co.za> Thomas Lee added the comment: Attaching a sample program to demonstrate the crash. Added file: http://bugs.python.org/file9135/ast.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 01:03:25 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 00:03:25 -0000 Subject: [issue1810] Partial AST compile() patch In-Reply-To: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za> Message-ID: <1200096205.57.0.0884153253019.issue1810@psf.upfronthosting.co.za> Christian Heimes added the comment: Georg is working on the AST front. ---------- assignee: -> georg.brandl keywords: +patch nosy: +georg.brandl, tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 01:04:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 00:04:28 -0000 Subject: [issue1800] ctypes callback fails when called in Python with array argument In-Reply-To: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za> Message-ID: <1200096268.7.0.528625416095.issue1800@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> theller nosy: +theller priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 01:50:15 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 00:50:15 -0000 Subject: [issue1337648] Elemental Security contribution - parsexml.py Message-ID: <1200099015.59.0.283563477772.issue1337648@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Is this module still of interest? Given that PyXML is no longer being developed or released, the module would need to either go straight into the stdlib, or be released separately. ---------- nosy: +akuchling type: -> rfe _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 01:53:02 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 00:53:02 -0000 Subject: [issue1411695] XML.sax.saxutils.escape -- always escapes <, >, &, Message-ID: <1200099182.24.0.203571170591.issue1411695@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 01:56:48 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 00:56:48 -0000 Subject: [issue1433694] normalize function in minidom unlinks empty child nodes Message-ID: <1200099408.6.0.715545785537.issue1433694@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 01:57:34 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 00:57:34 -0000 Subject: [issue1675533] setup.py LDFLAGS regexp is wrong Message-ID: <1200099454.08.0.00342947285683.issue1675533@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 02:00:24 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:00:24 -0000 Subject: [issue1463043] test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Message-ID: <1200099624.25.0.590303334325.issue1463043@psf.upfronthosting.co.za> A.M. Kuchling added the comment: This seems to be an XML issue, not actually a build-related one. ---------- components: +XML -Build nosy: +akuchling _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 02:02:08 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:02:08 -0000 Subject: [issue687648] classic division in demos/ directory Message-ID: <1200099728.04.0.120831718221.issue687648@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 12 02:03:30 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:03:30 -0000 Subject: [issue1550] help('modules') broken by several 3rd party libraries (svn patch attached) In-Reply-To: <1196699649.3.0.798271270482.issue1550@psf.upfronthosting.co.za> Message-ID: <1200099810.45.0.530359014858.issue1550@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:06:21 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:06:21 -0000 Subject: [issue1741] .pypirc not found on windows In-Reply-To: <1199616321.65.0.452980154178.issue1741@psf.upfronthosting.co.za> Message-ID: <1200099981.11.0.870241515785.issue1741@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:12:18 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:12:18 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. In-Reply-To: <1196215842.85.0.855394455026.issue1509@psf.upfronthosting.co.za> Message-ID: <1200100338.19.0.441177343667.issue1509@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:14:29 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 12 Jan 2008 01:14:29 -0000 Subject: [issue1337648] Elemental Security contribution - parsexml.py Message-ID: <1200100469.08.0.118437046612.issue1337648@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll just withdraw it. ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 02:14:42 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:14:42 -0000 Subject: [issue976880] mmap needs a rfind method Message-ID: <1200100482.05.0.922271057478.issue976880@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 12 02:15:22 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2008 01:15:22 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1200100522.47.0.860866216952.issue1780@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a patch that alters the Decimal constructor to allow leading and trailing whitespace. The Context.create_decimal method should now be a fully conforming implementation of to-number: it doesn't accept any leading or trailing whitespace. ---------- keywords: +patch Added file: http://bugs.python.org/file9136/issue1780.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:15:52 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:15:52 -0000 Subject: [issue1751519] curses - new window methods: addchstr and addchnstr Message-ID: <1200100552.7.0.359260461358.issue1751519@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling nosy: +akuchling _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 02:17:28 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:17:28 -0000 Subject: [issue1019] Cleanup pass on _curses and _curses_panel In-Reply-To: <1188041116.84.0.34357084027.issue1019@psf.upfronthosting.co.za> Message-ID: <1200100648.41.0.0993468125908.issue1019@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:28:40 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:28:40 -0000 Subject: [issue1598083] Top-level exception handler writes to stdout unsafely Message-ID: <1200101320.07.0.230342982597.issue1598083@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 02:27:28 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:27:28 -0000 Subject: [issue1286] fileinput, StringIO, and cStringIO do not support the with protocol In-Reply-To: <1192538556.96.0.72107595061.issue1286@psf.upfronthosting.co.za> Message-ID: <1200101248.7.0.844711534648.issue1286@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:30:40 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Jan 2008 01:30:40 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1200101440.6.0.461665358451.issue1780@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please apply the patch and close the bug. Thx ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:36:47 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:36:47 -0000 Subject: [issue1679] tokenizer permits invalid hex integer In-Reply-To: <1198240546.79.0.598190279926.issue1679@psf.upfronthosting.co.za> Message-ID: <1200101807.08.0.609780574747.issue1679@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:40:08 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2008 01:40:08 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200102008.89.0.193446346616.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: More comments, questions, and suggestions on the latest patch: 1. In _binary_float_to_ratio, the indentation needs adjusting. Also 'top = 0L' could be replaced with 'top = 0', unless you need this code to work with Python 2.3 and earlier, in which case top needs to be a long so that << behaves correctly. Otherwise, this looks good. 2. Rational() should work, and it should be possible to initialize from a string. I'd suggest that Rational(' 1729 '), Rational('-3/4') and (' +7/18 \n') should be acceptable: i.e. leading and trailing whitespace, and an optional - or + sign should be permitted. But space between the optional sign and the numerator, or on either side of the / sign, should be disallowed. Not sure whether the numerator and denominator should be allowed to have leading zeros or not---probably yes, for consistency with int(). 3. I don't think representing +/-inf and nan as Rationals (1/0, -1/0, 0/0) is a good idea---special values should be kept out of the Rational type, else it won't be an implementation of the Rationals any more---it'll be something else. 4. hash(n) doesn't agree with hash(Rational(n)) for large integers (I think you already mentioned this above). 5. Equality still doesn't work for complex numbers: >>> from rational import * >>> Rational(10**23) == complex(10**23) # expect False here True >>> Rational(10**23) == float(10**23) False >>> float(10**23) == complex(10**23) True 6. Why the parentheses around the str() of a Rational? 7. How about having hash of a Rational (in the case that it's not equal to an integer or a float) be given by hash((self.numerator, self.denominator))? That is, let the tuple hash take care of avoiding lots of hash collisions. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:41:18 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:41:18 -0000 Subject: [issue1298813] sysmodule.c: realpath() is unsafe Message-ID: <1200102078.85.0.458620120088.issue1298813@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- type: -> security _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 02:43:20 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:43:20 -0000 Subject: [issue1269] Exception in pstats print_callers() In-Reply-To: <1192173262.83.0.27550877069.issue1269@psf.upfronthosting.co.za> Message-ID: <1200102200.11.0.248375116336.issue1269@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:43:34 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:43:34 -0000 Subject: [issue1339] smtplib starttls() should ehlo() if it needs to In-Reply-To: <1193441174.56.0.280335873353.issue1339@psf.upfronthosting.co.za> Message-ID: <1200102214.49.0.103576531149.issue1339@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:46:50 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:46:50 -0000 Subject: [issue1274] doctest fails to run file based tests with 8bit paths In-Reply-To: <1192213919.32.0.843568182453.issue1274@psf.upfronthosting.co.za> Message-ID: <1200102410.41.0.319293332225.issue1274@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:47:46 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2008 01:47:46 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200102466.63.0.367268529533.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: About .trim and .approximate: it sounds like these are different, but quite closely related, methods: one takes a positive integer and returns the best approximation with denominator bounded by that integer; the other returns the 'smallest' rational in a given interval centered at the original rational. I guess we probably don't need both of these, but I can't give any good reason for preferring one over the other. I don't have anything to offer about names, either. I can try to find out whether the algorithms are published anywhere on the web---certainly, neither algorithm should be particularly hard to implement and prove the correctness of; they both essentially rely on computing the continued fraction development of the given rational. Almost any not-too-basic elementary number theory text should contain proofs of the relevant results about continued fractions. Am willing to help out with implementing either of these, if that's at all useful. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:47:55 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:47:55 -0000 Subject: [issue1704474] test_optparse.py mod. for jython Message-ID: <1200102475.81.0.173681533655.issue1704474@psf.upfronthosting.co.za> A.M. Kuchling added the comment: The patch would need to be checked against Jython's last release and/or the current trunk. ---------- keywords: +easy nosy: +akuchling _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 02:52:20 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 12 Jan 2008 01:52:20 -0000 Subject: [issue1160] Medium size regexp crashes python In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za> Message-ID: <1200102739.98.0.632204714348.issue1160@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Trying effbot's suggested experiment is easy, at least, and would provide useful info. If it fails, then fixing this bug might be difficult. ---------- keywords: +easy nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:56:41 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2008 01:56:41 -0000 Subject: [issue1780] Decimal constructor accepts newline terminated strings In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za> Message-ID: <1200103001.27.0.900611592558.issue1780@psf.upfronthosting.co.za> Mark Dickinson added the comment: Committed, revision 59929. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 02:58:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 01:58:10 -0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1200103090.44.0.524340380704.issue1180@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 03:44:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 02:44:26 -0000 Subject: [issue1714] ConfigParser.py do not allow leading (and trailing) space in values. In-Reply-To: <1199115002.03.0.289718233868.issue1714@psf.upfronthosting.co.za> Message-ID: <1200105866.46.0.889966869236.issue1714@psf.upfronthosting.co.za> Christian Heimes added the comment: Please provide a patch against 2.6 with an unit test and documentation updates. ---------- keywords: +easy nosy: +tiran priority: -> low versions: +Python 2.6 -Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 03:44:38 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 02:44:38 -0000 Subject: [issue1714] ConfigParser.py do not allow leading (and trailing) space in values. In-Reply-To: <1199115002.03.0.289718233868.issue1714@psf.upfronthosting.co.za> Message-ID: <1200105878.99.0.172995697647.issue1714@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Library (Lib) -Extension Modules __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 03:45:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 02:45:59 -0000 Subject: [issue1627] Problem with httplib and Content-Length: -1 In-Reply-To: <1197636721.61.0.0455165758222.issue1627@psf.upfronthosting.co.za> Message-ID: <1200105959.83.0.710298100819.issue1627@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: -> low versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 03:51:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 02:51:53 -0000 Subject: [issue1353344] python.desktop Message-ID: <1200106313.28.0.278573887512.issue1353344@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 03:54:02 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sat, 12 Jan 2008 02:54:02 -0000 Subject: [issue1286] fileinput, StringIO, and cStringIO do not support the with protocol In-Reply-To: <1192538556.96.0.72107595061.issue1286@psf.upfronthosting.co.za> Message-ID: <1200106442.6.0.0109424292975.issue1286@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: FYI, StringIO and BytesIO, in Python 3K, already support the context management protocol. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 04:12:35 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 03:12:35 -0000 Subject: [issue1297] pyconfig.h not compatible with MS VC++ Express Edition In-Reply-To: <1192727177.86.0.467865548072.issue1297@psf.upfronthosting.co.za> Message-ID: <1200107555.65.0.565063494106.issue1297@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 04:15:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 03:15:56 -0000 Subject: [issue1299] distutils.sysconfig is not cross-platform compatible In-Reply-To: <1192727810.38.0.522851261061.issue1299@psf.upfronthosting.co.za> Message-ID: <1200107756.58.0.557773738515.issue1299@psf.upfronthosting.co.za> Christian Heimes added the comment: It's going to be hard to implement the feature for Windows. The PC/pyconfig.h uses lots of #ifdef and #if defined. If you are still interested in the matter please provide a patch and answer within two weeks. Otherwise this bug will be closed on 2008-01-26. ---------- components: +Windows nosy: +tiran priority: -> low versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 04:23:37 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 03:23:37 -0000 Subject: [issue1239] openpty does not give bidirectional pipe In-Reply-To: <1191571947.24.0.64790674647.issue1239@psf.upfronthosting.co.za> Message-ID: <1200108217.57.0.803052233111.issue1239@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 04:31:58 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2008 03:31:58 -0000 Subject: [issue1516613] Decimal should allow leading or trailing spaces. Message-ID: <1200108718.96.0.086041068699.issue1516613@psf.upfronthosting.co.za> Mark Dickinson added the comment: I spoke too soon. This came up again in the discussion for issue #1780 and there was general support for allowing trailing and leading whitespace. Fixed for Python 2.6, revision 59929 ---------- resolution: -> fixed status: open -> closed superseder: -> Decimal constructor accepts newline terminated strings _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 05:19:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:19:51 -0000 Subject: [issue1669637] Some Compiler Warnings on VC6 Message-ID: <1200111591.57.0.885099338809.issue1669637@psf.upfronthosting.co.za> Christian Heimes added the comment: VC6 is no longer the main stream compiler. Please provide a patch if you like to have these errors fixed in 2.6. I don't see the warnings in VS 2008. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 05:21:17 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:21:17 -0000 Subject: [issue1749567] PLATFORM macro in PC/pyconfig.h already defined by Apache Message-ID: <1200111677.66.0.813255408166.issue1749567@psf.upfronthosting.co.za> Christian Heimes added the comment: Please provide a patch and documentation updates (if required) or I'm going to close the bug in two weeks (2008-01-26). ---------- components: +Build nosy: +tiran status: open -> pending type: -> rfe versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 05:23:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:23:52 -0000 Subject: [issue1675] Race condition in os.makedirs In-Reply-To: <1198180171.38.0.482360233935.issue1675@psf.upfronthosting.co.za> Message-ID: <1200111832.02.0.444977525455.issue1675@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Library (Lib) keywords: +easy versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 05:26:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:26:28 -0000 Subject: [issue1616] compiler warnings (gcc 2.96) In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za> Message-ID: <1200111988.39.0.361450260634.issue1616@psf.upfronthosting.co.za> Christian Heimes added the comment: 2.96 is ancient and I don't see those warnings with 4.x series. Can I close this bug? ---------- components: +Build nosy: +tiran status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 05:28:42 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:28:42 -0000 Subject: [issue1174614] site enhancements Message-ID: <1200112122.96.0.522125460574.issue1174614@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm going to check the patch for my new PEP about per user site directories. ---------- assignee: -> tiran nosy: +tiran versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 05:31:16 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:31:16 -0000 Subject: [issue936813] fast modular exponentiation Message-ID: <1200112276.56.0.844356484853.issue936813@psf.upfronthosting.co.za> Christian Heimes added the comment: Re-targeting for 2.6 We should discuss it at the bug day. ---------- nosy: +tiran type: -> rfe versions: +Python 2.6 -Python 2.5 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 12 05:34:30 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:34:30 -0000 Subject: [issue1309352] Make fcntl work properly on AMD64 Message-ID: <1200112470.22.0.132132131853.issue1309352@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 05:39:06 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:39:06 -0000 Subject: [issue1391872] floating point literals don't work in non-US locale in 2.5 Message-ID: <1200112746.49.0.230374206578.issue1391872@psf.upfronthosting.co.za> Christian Heimes added the comment: Do we have a test for the problem which verifies the behavior or can I close the bug? ---------- nosy: +tiran status: open -> pending type: -> behavior versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 05:43:23 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:43:23 -0000 Subject: [issue1479611] speed up function calls Message-ID: <1200113003.45.0.394279515632.issue1479611@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> rfe versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 05:54:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:54:34 -0000 Subject: [issue1220212] os.kill on windows Message-ID: <1200113674.48.0.308868816855.issue1220212@psf.upfronthosting.co.za> Christian Heimes added the comment: This should be implemented differently. Users should substitute their popen and exec calls with subprocess. The subprocess.Popen class should gain two new methods terminate() and send_signal(int) where send_signal is restricted to SIGKILL (+SIGTERM ?) on Windows. The idea was discussed on the Python dev list early last year. ---------- nosy: +tiran versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 05:56:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:56:02 -0000 Subject: [issue1467201] size_t warnings on OSX 10.3 Message-ID: <1200113762.68.0.643376289981.issue1467201@psf.upfronthosting.co.za> Christian Heimes added the comment: *PING* Is this still a problem, Anthony? ---------- nosy: +tiran status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 05:58:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 04:58:54 -0000 Subject: [issue1528620] Python 2.5b2 fails to build on Solaris 10 (Sun Compiler) Message-ID: <1200113934.63.0.349277587502.issue1528620@psf.upfronthosting.co.za> Christian Heimes added the comment: Guido, have you tested the build on your box? I'm going to close the bug after two week unless you report a new problem. (2008-01-26) ---------- nosy: +tiran status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:00:24 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:00:24 -0000 Subject: [issue1522046] RPM build fails for Py2.5b2 Message-ID: <1200114024.6.0.208765904582.issue1522046@psf.upfronthosting.co.za> Christian Heimes added the comment: Please open a new bug for the /usr/lib64 issue. ---------- nosy: +tiran resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:04:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:04:02 -0000 Subject: [issue1570672] qtsupport.py mistake leads to bad _Qt module Message-ID: <1200114242.61.0.784862137045.issue1570672@psf.upfronthosting.co.za> Christian Heimes added the comment: Qt is a 3rd party extension. ---------- nosy: +tiran resolution: -> invalid status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:05:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:05:18 -0000 Subject: [issue1608805] Py_FileSystemDefaultEncoding can be non-canonical Message-ID: <1200114318.98.0.223508559365.issue1608805@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:07:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:07:53 -0000 Subject: [issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun compiler) Message-ID: <1200114473.61.0.736347984699.issue1544339@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> theller type: -> crash versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:08:42 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:08:42 -0000 Subject: [issue1653416] print >> f, "Hello" produces no error: normal? Message-ID: <1200114522.74.0.375731596227.issue1653416@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> behavior versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:10:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:10:05 -0000 Subject: [issue1653416] print >> f, "Hello" produces no error: normal? Message-ID: <1200114605.81.0.143660417037.issue1653416@psf.upfronthosting.co.za> Christian Heimes added the comment: On Linux both 2.5 and 2.6 are raising an exception: >>> f = open("/etc/passwd") >>> print >>f, "Hello" Traceback (most recent call last): File "", line 1, in IOError: [Errno 9] Bad file descriptor ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:11:24 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:11:24 -0000 Subject: [issue1672336] Building python 2.5 for AMD64 (windows) and VS2005 Message-ID: <1200114684.89.0.354047063985.issue1672336@psf.upfronthosting.co.za> Christian Heimes added the comment: The new build directories for VS 2005 and VS 2008 work for AMD 64. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:12:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:12:41 -0000 Subject: [issue1644818] Allow importing built-in submodules Message-ID: <1200114761.49.0.464034174121.issue1644818@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Build type: -> rfe versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:15:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:15:34 -0000 Subject: [issue1702551] distutils sdist does not exclude SVN/CVS files on Windows Message-ID: <1200114934.71.0.467611040727.issue1702551@psf.upfronthosting.co.za> Christian Heimes added the comment: The code should use \ and / on Windows. ---------- nosy: +tiran type: -> behavior versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:16:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:16:59 -0000 Subject: [issue1720595] Allow T_BOOL in PyMemberDef definitions Message-ID: <1200115019.23.0.938356948847.issue1720595@psf.upfronthosting.co.za> Christian Heimes added the comment: allow or reject it for 2.6, Georg? ---------- nosy: +tiran type: -> rfe versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:19:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:19:03 -0000 Subject: [issue1729014] 0.0 and -0.0 end up referring to the same object Message-ID: <1200115143.14.0.792231443584.issue1729014@psf.upfronthosting.co.za> Christian Heimes added the comment: I mark this bug as duplicate of #1678668. They are both about the same issue. ---------- nosy: +tiran resolution: -> duplicate status: open -> closed superseder: -> fix a bug mixing up 0.0 and-0.0 type: -> behavior _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:19:30 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:19:30 -0000 Subject: [issue1678668] fix a bug mixing up 0.0 and-0.0 Message-ID: <1200115170.42.0.501911444172.issue1678668@psf.upfronthosting.co.za> Christian Heimes added the comment: See also #1678668. ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:20:29 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2008 05:20:29 -0000 Subject: [issue1811] True division of integers could be more accurate In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za> Message-ID: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za> New submission from Mark Dickinson: Division of two longs can produce results that are needlessly inaccurate: >>> from __future__ import division >>> 10**40/10**39 10.000000000000002 The correct result is, of course, 10.0, which is exactly representable as a float. The attached snippet of Python code shows that things don't have to be this way. ---------- files: int_truediv.py messages: 59798 nosy: marketdickinson severity: minor status: open title: True division of integers could be more accurate type: behavior Added file: http://bugs.python.org/file9137/int_truediv.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 06:20:56 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2008 05:20:56 -0000 Subject: [issue1811] True division of integers could be more accurate In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za> Message-ID: <1200115256.08.0.954779843148.issue1811@psf.upfronthosting.co.za> Changes by Mark Dickinson: ---------- components: +Interpreter Core versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 06:21:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:21:18 -0000 Subject: [issue1733134] sqlite3.dll cannot be relocated Message-ID: <1200115278.18.0.98204145546.issue1733134@psf.upfronthosting.co.za> Christian Heimes added the comment: Tim, please help us to track the bug down. I'm going to close the bug in two weeks (2008-01-26) unless you respond. ---------- nosy: +tiran status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:21:55 2008 From: report at bugs.python.org (Miki Tebeka) Date: Sat, 12 Jan 2008 05:21:55 -0000 Subject: [issue1220212] os.kill on windows Message-ID: <1200115315.69.0.0627368787843.issue1220212@psf.upfronthosting.co.za> Miki Tebeka added the comment: > Users should substitute their popen and exec calls with subprocess As long as popen and exec are available, users are free to use them (and probably will :) The Popen(...).terminate() works only if I'm the one who started the process. However there are cases where I want to kill all running python processes. The pids to be killed will come from somewhere else (ps, plist, ...). _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:25:46 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:25:46 -0000 Subject: [issue1254718] GCC detection for runtime_library_dirs when ccache is used Message-ID: <1200115546.3.0.858466377433.issue1254718@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Build type: -> compile error versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:27:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:27:13 -0000 Subject: [issue1367711] Remove usage of UserDict from os.py Message-ID: <1200115633.11.0.724298065614.issue1367711@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> tiran nosy: +tiran type: -> rfe versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:27:24 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 05:27:24 -0000 Subject: [issue1367711] Remove usage of UserDict from os.py Message-ID: <1200115644.03.0.618651939705.issue1367711@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: tiran -> keywords: +easy _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 06:57:35 2008 From: report at bugs.python.org (Peter Donis) Date: Sat, 12 Jan 2008 05:57:35 -0000 Subject: [issue1812] doctest _load_testfile function -- newline handling seems incorrect In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za> Message-ID: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za> New submission from Peter Donis: When running doctest.testfile on a Linux machine, testing a txt file saved on a Windows machine, doctest raised a SyntaxError exception for each Windows newline in the txt file. On examining the code in the _load_testfile function, it looks to me like there are actually two issues: (1) When there is no package keyword argument given, or the package argument points to a package without a __loader__.get_data method, the txt file data is retrieved by calling open(filename).read(); this is the code path that my Windows-saved file triggered. However, since the default file mode for open is 'r', not 'rU', there is no universal newline conversion done on the file data. This was the issue I initially observed. (2) When there is a package.__loader__.get_data method found, that method reads the data (using file mode 'rb'), and then newline conversion is performed by this line: return file_contents.replace(os.linesep, '\n') This does not seem to match what universal newline conversion does; that is supposed to convert both '\r\n' and '\r' to '\n', but running on Linux, os.linesep is '\n', so the replace operation in the current code is a no-op, even if the txt file was saved with Windows or Mac newlines. It seems to me that the correct operation would be: for linesep in ('\r\n', '\r'): file_contents = file_contents.replace(linesep, '\n') I have attached a diff against the current svn trunk showing my suggested fix for both of the above issues. Peter Donis ---------- components: Tests files: doctest-fixes.diff messages: 59801 nosy: pdonis severity: normal status: open title: doctest _load_testfile function -- newline handling seems incorrect type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9138/doctest-fixes.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 07:01:24 2008 From: report at bugs.python.org (Peter Donis) Date: Sat, 12 Jan 2008 06:01:24 -0000 Subject: [issue1812] doctest _load_testfile function -- newline handling seems incorrect In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za> Message-ID: <1200117684.56.0.431421686371.issue1812@psf.upfronthosting.co.za> Peter Donis added the comment: Edit: I should have said that the attached diff also includes changes to test_doctest.py to test for the correct newline behavior. Because the test setup is a little complex, I added an auxiliary script, doctest_testfile.py, and an accompanying text file, doctest_testfile.txt, which intentionally contains mismatched newlines for use in the test. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 07:31:16 2008 From: report at bugs.python.org (Tim Delaney) Date: Sat, 12 Jan 2008 06:31:16 -0000 Subject: [issue1733134] sqlite3.dll cannot be relocated Message-ID: <1200119476.69.0.226613618348.issue1733134@psf.upfronthosting.co.za> Tim Delaney added the comment: I've got no further details on this bug - I've never encountered it myself. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 09:02:21 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Jan 2008 08:02:21 -0000 Subject: [issue1367711] Remove usage of UserDict from os.py Message-ID: <1200124941.79.0.774041052842.issue1367711@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't think the point of this patch is worth doing. The existing code is not buggy and runs fine. Subclassing from dict increases the likelihood that an error will be introduced either now or in the future as the dict object evolves. Recommend this be closed. ---------- nosy: +rhettinger _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 11:15:02 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sat, 12 Jan 2008 10:15:02 -0000 Subject: [issue1746] ZIP files with archive comments longer than 4k not recognized as valid by zipfile module In-Reply-To: <1199659217.24.0.18704559865.issue1746@psf.upfronthosting.co.za> Message-ID: <1200132902.56.0.28019886373.issue1746@psf.upfronthosting.co.za> Alan McIntyre added the comment: A fix for this is included in the patch for issue 1622. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 11:19:15 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 10:19:15 -0000 Subject: [issue1570672] qtsupport.py mistake leads to bad _Qt module Message-ID: <1200133155.22.0.366694878006.issue1570672@psf.upfronthosting.co.za> Georg Brandl added the comment: But qtsupport.py is in the Python distribution. ---------- nosy: +georg.brandl resolution: invalid -> status: closed -> open _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 11:20:16 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 10:20:16 -0000 Subject: [issue1720595] Allow T_BOOL in PyMemberDef definitions Message-ID: <1200133216.0.0.864120064469.issue1720595@psf.upfronthosting.co.za> Georg Brandl added the comment: The question is also what C type to assume for boolean fields -- char or int? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 11:23:03 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 10:23:03 -0000 Subject: [issue1678668] fix a bug mixing up 0.0 and-0.0 Message-ID: <1200133383.92.0.609624711441.issue1678668@psf.upfronthosting.co.za> Georg Brandl added the comment: ITYM #1729014. :) ---------- nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 11:24:39 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sat, 12 Jan 2008 10:24:39 -0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za> Message-ID: <1200133479.86.0.685456241227.issue1622@psf.upfronthosting.co.za> Alan McIntyre added the comment: Here's an updated patch (zipfile-unsigned-fixes2.diff) that contains Eric's fixes. I also changed the structure for the Zip64 extension data to be unsigned. I think this should cover all the deficiencies caused by the improper use of unsigned values. Note: if this patch is committed, then issue 1746 should be closed since it is fixed with this patch. Added file: http://bugs.python.org/file9139/zipfile-unsigned-fixes2.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 11:35:41 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sat, 12 Jan 2008 10:35:41 -0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za> Message-ID: <1200134141.94.0.623641999896.issue1622@psf.upfronthosting.co.za> Alan McIntyre added the comment: I just noticed that my changes for issue 1526 are included in this patch. Eric, if you have time could you have a look at that issue and see if you think I addressed it properly? If not I can back them out into a separate patch for that issue. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 11:35:48 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sat, 12 Jan 2008 10:35:48 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files In-Reply-To: <1196429217.61.0.167287216759.issue1526@psf.upfronthosting.co.za> Message-ID: <1200134148.67.0.63859111799.issue1526@psf.upfronthosting.co.za> Alan McIntyre added the comment: I just noticed that my changes for this issue are included in the patch for issue 1622; if that gets committed then this issue should be closed. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 11:54:09 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 10:54:09 -0000 Subject: [issue1809] docs for os.symlink(src, dst) doesn't mention exceptions In-Reply-To: <1200095193.22.0.167933676219.issue1809@psf.upfronthosting.co.za> Message-ID: <1200135249.65.0.934644805193.issue1809@psf.upfronthosting.co.za> Georg Brandl added the comment: Most of the os functions don't specify that they raise OSError in the case of invalid or inaccessible paths. I've now added a general note to that effect in r59930. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 12:15:18 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 11:15:18 -0000 Subject: [issue1810] Partial AST compile() patch In-Reply-To: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za> Message-ID: <1200136518.91.0.386285748588.issue1810@psf.upfronthosting.co.za> Georg Brandl added the comment: This is great work! The problem is that ast2obj_object translates NULL values to Py_None, but obj2ast_object doesn't translate that back. This definition fixes your testcase: static int obj2ast_object(PyObject* obj, PyObject** out, PyArena* arena) { if (obj == Py_None) obj = NULL; Py_XINCREF(obj); *out = obj; return 0; } __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 12:30:55 2008 From: report at bugs.python.org (Andrew Dalke) Date: Sat, 12 Jan 2008 11:30:55 -0000 Subject: [issue1367711] Remove usage of UserDict from os.py Message-ID: <1200137455.6.0.737187517086.issue1367711@psf.upfronthosting.co.za> Andrew Dalke added the comment: I was optimization tuning and wondered why UserDict was imported by os. Replacing UserDict with dict passes all existing regression tests. I see the concerns that doing that replacement is not future proof. Strange then that Cookie.py is acceptable. There are three places in Lib which derive from dict, and two are in Cookie.py and in both cases it's broken because set_default does not go through the same checks that __setitem__ goes through. (The other place is an internal class in _strptime.) In looking over existing third-party code, I see this nuance of when to use UserDict vs. dict isn't that well known. The documentation says "The need for this class has been largely supplanted by the ability to subclass directly from dict", but that isn't true if anyone is worried about future-proofing and where the subclass changes one of the standard methods. ---------- nosy: +dalke _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 13:27:46 2008 From: report at bugs.python.org (Andrew Dalke) Date: Sat, 12 Jan 2008 12:27:46 -0000 Subject: [issue1367711] Remove usage of UserDict from os.py Message-ID: <1200140866.4.0.214396602035.issue1367711@psf.upfronthosting.co.za> Andrew Dalke added the comment: I should have added my preference. I would like to see UserDict replaced with dict. I didn't like seeing the extra import when I was doing my performance testing, through truthfully it's not a bit overhead. As for future-proofing, of course when there's a change in a base class then there can be problems with derived classes. When that happens, change all of the affected classes in the code base, and make sure to publish the change so third parties know about it. Yes, there's a subtlety here that most people don't know about. But it's not going to go away. As for the evil that is 'exec': exec "locals().data['MACHTYPE']=1; print MACHTYPE" in {}, os.environ gives me another way to mess things up. A point of unit tests is to allow changes like this without worry about code breakage. And it's not like other non-buggy code wasn't updated over time to reflect changing style and best practices. If it's not compatible with Jython or IronPython or PyPy then ignore what I said, but fix Cookie and update the docs to make that clear as people do think that it's better to derived from dict for things like this than to derive from UserDict or UserDictMixin. I can give a lightning talk about this at PyCon. :) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 14:16:09 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 13:16:09 -0000 Subject: [issue1685986] Method cache Message-ID: <1200143769.65.0.778883583047.issue1685986@psf.upfronthosting.co.za> Georg Brandl added the comment: Superseded by #1700288, which is updated for 2.6. ---------- resolution: -> duplicate status: open -> closed superseder: -> Armin's method cache optimization updated for Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 14:46:42 2008 From: report at bugs.python.org (James Henstridge) Date: Sat, 12 Jan 2008 13:46:42 -0000 Subject: [issue1339] smtplib starttls() should ehlo() if it needs to In-Reply-To: <1193441174.56.0.280335873353.issue1339@psf.upfronthosting.co.za> Message-ID: <1200145602.09.0.980000347181.issue1339@psf.upfronthosting.co.za> James Henstridge added the comment: >From RFC 2487 section 5.2: "The client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the TLS negotiation itself. The client SHOULD send an EHLO command as the first command after a successful TLS negotiation." So the starttls() method should probably also be clearing helo_resp and ehlo_resp (and maybe anything else discovered by ehlo()). There are servers in the wild that will (a) refuse to talk to you unless you issue another EHLO after TLS is negotiated and (b) offer a different set of ESMTP features (such as only supporting SMTP AUTH after TLS). This patch isn't enough to talk to such servers. ---------- nosy: +jamesh __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 14:48:21 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 13:48:21 -0000 Subject: [issue1700288] Armin's method cache optimization updated for Python 2.6 Message-ID: <1200145701.7.0.91582662431.issue1700288@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed to trunk as r59931. Leaving open if you want to make more adjustments, Raymond. ---------- nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 14:50:36 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 13:50:36 -0000 Subject: [issue1568] PATCH: Armin's attribute lookup caching for 3.0 In-Reply-To: <1197034097.09.0.871896219058.issue1568@psf.upfronthosting.co.za> Message-ID: <1200145836.79.0.0634417507502.issue1568@psf.upfronthosting.co.za> Georg Brandl added the comment: #1700288's patch has been committed. Leaving this open as a guide to whoever has to merge it to Py3k. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 14:59:29 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 13:59:29 -0000 Subject: [issue1472] Small bat files to build docs on Windows In-Reply-To: <1195529295.02.0.66501222215.issue1472@psf.upfronthosting.co.za> Message-ID: <1200146369.01.0.423759991261.issue1472@psf.upfronthosting.co.za> Georg Brandl added the comment: Ideally, yes. The case of the doc build is a bit more complicated because it relies on external libraries which may or may not work with the tree version. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 15:00:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 14:00:07 -0000 Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100 In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za> Message-ID: <1200146407.6.0.401844856433.issue1491@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 15:00:10 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 12 Jan 2008 14:00:10 -0000 Subject: [issue1492] BaseHTTPServer hard-codes Content-Type for error messages In-Reply-To: <1195823047.2.0.185836867459.issue1492@psf.upfronthosting.co.za> Message-ID: <1200146410.45.0.976331998482.issue1492@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 16:00:13 2008 From: report at bugs.python.org (=?utf-8?q?=C3=81rni_M=C3=A1r_J=C3=B3nsson?=) Date: Sat, 12 Jan 2008 15:00:13 -0000 Subject: [issue1813] Codec lookup failing under turkish locale In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za> Message-ID: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za> New submission from ?rni M?r J?nsson: When switching to a turkish locale, the codecs registry fails on a codec lookup which worked before the locale change. This happens when the codec name contains an uppercase 'I'. What happens, is just before doing a cache lookup, the string is normalized, which includes a call to 's tolower. tolower is locale dependant, and the turkish locale handles 'I's different from other locales. Thus, the lookup fails, since the normalization behaves differently then it did before. Replacing the tolower() call with this made the lookup work: int my_tolower(char c) { if ('A' <= c && c <= 'Z') c += 32; return c; } PS: If the turkish locale is not supported, this here will enable it to an Ubuntu system a) sudo cp /usr/share/i18n/SUPPORTED /var/lib/locales/supported.d/local (or just copy the lines with "tr" in them) b) sudo dpkg-reconfigure locales ---------- components: Interpreter Core files: verify_locale.py messages: 59821 nosy: arnimar severity: normal status: open title: Codec lookup failing under turkish locale type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9140/verify_locale.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 17:26:32 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Jan 2008 16:26:32 -0000 Subject: [issue1367711] Remove usage of UserDict from os.py Message-ID: <1200155192.79.0.0121746842178.issue1367711@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > it's better to derived from dict for things like > this than to derive from UserDict or UserDictMixin That's true for UserDict but not DictMixin. IIRC, the latter will continue to exist in Py3.0 and it has a purpose that is much different than UserDict or dict, namely to build-out objects with a mapping interface but are *not* dicts under the hood. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 17:47:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 16:47:13 -0000 Subject: [issue1570672] qtsupport.py mistake leads to bad _Qt module Message-ID: <1200156432.99.0.802062266031.issue1570672@psf.upfronthosting.co.za> Christian Heimes added the comment: Oh, it's a Mac module :) I'm sorry _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 17:57:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 16:57:19 -0000 Subject: [issue1811] True division of integers could be more accurate In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za> Message-ID: <1200157039.19.0.510205687834.issue1811@psf.upfronthosting.co.za> Christian Heimes added the comment: How fast is your algorithm compared to the current algorithm and where starts the break even zone? Most users use only small integers so it might be a good idea to use a simpler algorithm for longs with Py_SIZE() == 1. This is important for py3k. ---------- nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 17:58:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 16:58:19 -0000 Subject: [issue1812] doctest _load_testfile function -- newline handling seems incorrect In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za> Message-ID: <1200157099.1.0.786562475003.issue1812@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 17:58:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 16:58:27 -0000 Subject: [issue1812] doctest _load_testfile function -- newline handling seems incorrect In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za> Message-ID: <1200157107.03.0.843614773565.issue1812@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 18:05:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 17:05:03 -0000 Subject: [issue936813] fast modular exponentiation Message-ID: <1200157503.72.0.502661537455.issue936813@psf.upfronthosting.co.za> Christian Heimes added the comment: Mark, as the second math guru in our team, you are probably interested in these patches. Trevor has written an interesting patch to optimize longs for cryptographic problems. In fact it might be two patches now, one for the Montgomery Reduction and one containing other optimizations. The 2005 patch applies almost cleanly. ---------- nosy: +marketdickinson versions: +Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 12 18:06:19 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 12 Jan 2008 17:06:19 -0000 Subject: [issue1472] Small bat files to build docs on Windows In-Reply-To: <1200076036.75.0.54037963714.issue1472@psf.upfronthosting.co.za> Message-ID: <4788F387.9060508@v.loewis.de> Martin v. L?wis added the comment: > Would all things in the tree ideally work > with the version that was built from checkout? It's more important that it works with many old versions, than with its own version. "python" should be on the path, and ideally, whatever you get there should work. The documentation, unfortunately, requires 2.5 as a minimum. It should stay that way for a long time, so that at some point, it works with whatever people typically have on their machines. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 18:07:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 17:07:13 -0000 Subject: [issue923643] long <-> byte-string conversion Message-ID: <1200157633.59.0.668868794271.issue923643@psf.upfronthosting.co.za> Christian Heimes added the comment: Here is another integer related optimization patch from Trev. I've no opinion on the matter but you might be interested in it as well. ---------- assignee: -> marketdickinson nosy: +marketdickinson, tiran versions: +Python 2.6 -Python 2.4 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 12 18:12:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 17:12:13 -0000 Subject: [issue1814] Victor Stinner's GMP patch for longs In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za> Message-ID: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za> New submission from Christian Heimes: A while ago Victor Stinner has spend several weeks in porting PyLongs to GMP: http://mail.python.org/pipermail/python-3000/2007-September/010718.html http://mail.python.org/pipermail/python-3000/2007-October/010755.html Although his patch didn't give the speedup he hoped for, the patch might be interesting someday in the future. He never submitted it to our bug tracker. I'm posting it to conserve it for the future. ---------- components: Interpreter Core files: py3k-long_gmp-v2.patch messages: 59828 nosy: marketdickinson, tim_one, tiran priority: normal severity: normal status: open title: Victor Stinner's GMP patch for longs type: rfe versions: Python 3.0 Added file: http://bugs.python.org/file9141/py3k-long_gmp-v2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 18:18:21 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 12 Jan 2008 17:18:21 -0000 Subject: [issue1222] locale.format bug if thousand separator is space (french separator as example) In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za> Message-ID: <1200158301.57.0.895382384068.issue1222@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Just tried on 2.5.1 and on trunk, I can't reproduce it. On both I get: >>> import locale >>> locale.setlocale(locale.LC_NUMERIC, "fr_FR.UTF-8") 'fr_FR.UTF-8' >>> locale.format("%9.2f", 12345.67, True) ' 12345,67' >>> locale.format("%.2f", 12345.67, True) '12345,67' >>> locale.localeconv()['thousands_sep'] '' Which means that there is no thousands separator for the French locale on my system (a Mandriva Linux box). ---------- nosy: +pitrou __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 18:18:55 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2008 17:18:55 -0000 Subject: [issue1811] True division of integers could be more accurate In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za> Message-ID: <1200158335.31.0.780225180403.issue1811@psf.upfronthosting.co.za> Mark Dickinson added the comment: It would be easy and safe to just use a/b = float(a)/float(b) if both a and b are less than 2**53 (assuming IEEE doubles). Then there wouldn't be any loss of speed for small integers. For large integers the algorithm I posted should run in time linear in the number of digits of max(a, b), at least in the worst case (though with appropriate optimizations it could be made much faster for 'random' inputs). The current algorithm has essentially O(1) runtime. To get proper timings I'd have to code this up properly. I'll do this, unless there's a consensus that it would be a waste of time :) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 18:35:34 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2008 17:35:34 -0000 Subject: [issue1779] int("- 1") is valud, but float("- 1") isn't. Which is right? In-Reply-To: <1199926803.21.0.243129638352.issue1779@psf.upfronthosting.co.za> Message-ID: <1200159334.46.0.302763607.issue1779@psf.upfronthosting.co.za> Mark Dickinson added the comment: For Python 3.0, this is a trivial fix: two lines need to be removed from PyLong_FromString in longobject.c, and then the tests in test_builtin need to be fixed up. (For Python 2.6, the fix would be a bit more involved: PyOS_strtol would also need fixing.) A good candidate for the bug day? ---------- keywords: +easy nosy: +marketdickinson __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 18:37:47 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 12 Jan 2008 17:37:47 -0000 Subject: [issue1616] compiler warnings (gcc 2.96) In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za> Message-ID: <1200159467.27.0.99011297873.issue1616@psf.upfronthosting.co.za> Guido van Rossum added the comment: With a newer compiler (GCC 4.0.1 on OSX 10.5.1) I still get some warnings: /Users/guido/p25/Modules/_ctypes/libffi/src/x86/ffi_darwin.c:220: warning: function declaration isn?t a prototype /Users/guido/p25/Modules/readline.c: In function ?flex_complete?: /Users/guido/p25/Modules/readline.c:681: warning: implicit declaration of function ?completion_matches? /Users/guido/p25/Modules/readline.c:681: warning: return makes pointer from integer without a cast This is with GNU readline 5.2. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 18:37:58 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 12 Jan 2008 17:37:58 -0000 Subject: [issue1616] compiler warnings (gcc 2.96) In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za> Message-ID: <1200159478.02.0.580925447128.issue1616@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- status: pending -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 18:43:27 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 12 Jan 2008 17:43:27 -0000 Subject: [issue1814] Victor Stinner's GMP patch for longs In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za> Message-ID: <1200159807.27.0.266049595093.issue1814@psf.upfronthosting.co.za> Guido van Rossum added the comment: Since this keeps coming up, I think it would make sense to turn this into an optional extension module. PS. The licensing concerns are another reason not to use this for the core long (or int in Py3k) type. ---------- keywords: +patch nosy: +gvanrossum priority: normal -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 19:32:34 2008 From: report at bugs.python.org (Peter Donis) Date: Sat, 12 Jan 2008 18:32:34 -0000 Subject: [issue1812] doctest _load_testfile function -- newline handling seems incorrect In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za> Message-ID: <1200162754.11.0.332499680933.issue1812@psf.upfronthosting.co.za> Peter Donis added the comment: I've uploaded a revised diff with two small improvements: (1) Removed a redundant os.isfile check in PackageLoaderTestImporter.get_data() in doctest_testfile.py. (The open() builtin already raises IOError if the file can't be opened.) (2) Added doctest.master = None in three places in doctest_testfile.py so the expected output is now nothing instead of three lines of *** DocTestRunner.merge: 'doctest_testfile.txt' in both testers; summing outcomes. Changed the expected output in test_doctest.py to correspond. Added file: http://bugs.python.org/file9142/doctest-fixes1.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 20:56:55 2008 From: report at bugs.python.org (Thomas Heller) Date: Sat, 12 Jan 2008 19:56:55 -0000 Subject: [issue1798] Add ctypes calling convention that allows safe access of errno In-Reply-To: <1200086872.52.0.872764863612.issue1798@psf.upfronthosting.co.za> Message-ID: <47891B83.9080306@ctypes.org> Thomas Heller added the comment: > But this thread-local attribute on the function seems bizarre to me. > I would prefer another way to get the errno. I can see two alternatives: > - the function returns a tuple (normalresult, errno) on each call. > - when errno is not zero, EnvironmentError (or WindowsError) is raised. I'd stronly prefer NOT to add errno to the function return value. Raising an Exception when errno or LastError != zero is wrong. There are functions that set the errno or LastError value even if they actually succeed. The recommended way to check for errors that I had in mind is in the 'errcheck' result checker: func = CDLL(..., errno=True) func.argtypes = [...] func.restype = ... def errcheck(result, func, args): if result == -1: # function failed raise EnvironmentError(func.errno) func.errcheck = errcheck Of course, an alternative to a thread local storage attribute would be to pass the error value to the errcheck function. I just felt it would be better not to change the signature, but maybe I was wrong. Anyway, this patch should be extended so that it is also possible to create a foreign function using the descibed calling convention from a prototype created by CFUNCTYPE or WINFUNCTYPE. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 21:14:28 2008 From: report at bugs.python.org (Daniel Eloff) Date: Sat, 12 Jan 2008 20:14:28 -0000 Subject: [issue1815] Distutils add ability to skip build [Feature Request] In-Reply-To: <1200168868.22.0.518070014613.issue1815@psf.upfronthosting.co.za> Message-ID: <1200168868.22.0.518070014613.issue1815@psf.upfronthosting.co.za> New submission from Daniel Eloff: There seems to be no way to skip the build step when running "setup.py install" The behavior in such a case should be to skip build and use the existing binaries as created in a separate build step or else print an error. That way you can do "setup.py build" followed by "setup.py install --skip-build" and you only have one build taking place. The purpose of this would be to allow build to take place on a separate computer to install. Currently I do this on Vista because MSVC 2003 is not recommended or supported, and distutils won't use the installed MSVC 2005. So I do the build on a (virtual) XP machine and then install by hand for lack of this option. I think Vista is a strong enough use case to justify adding this feature. ---------- components: Distutils messages: 59836 nosy: Eloff severity: normal status: open title: Distutils add ability to skip build [Feature Request] versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 21:43:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 20:43:03 -0000 Subject: [issue1815] Distutils add ability to skip build [Feature Request] In-Reply-To: <1200168868.22.0.518070014613.issue1815@psf.upfronthosting.co.za> Message-ID: <1200170583.1.0.980039428548.issue1815@psf.upfronthosting.co.za> Christian Heimes added the comment: Python 2.5's distutils has a --skip-build option for the install command. In which way doesn't it solve your use case? For Windows I recommend MinGW32 as compiler. It's sufficient for most users. ---------- nosy: +tiran priority: -> low type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 21:49:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 20:49:44 -0000 Subject: [issue1811] True division of integers could be more accurate In-Reply-To: <1200158335.31.0.780225180403.issue1811@psf.upfronthosting.co.za> Message-ID: <478927E5.3000503@cheimes.de> Christian Heimes added the comment: Mark Dickinson wrote: > To get proper timings I'd have to code this up properly. I'll do this, unless there's > a consensus that it would be a waste of time :) Why don't you ask Tim? He is the right person for the discussion. I'm only an interested amateur mathematician. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 22:05:35 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2008 21:05:35 -0000 Subject: [issue1811] True division of integers could be more accurate In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za> Message-ID: <1200171935.63.0.584216194739.issue1811@psf.upfronthosting.co.za> Mark Dickinson added the comment: Tim: is this worth fixing? ---------- nosy: +tim_one __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 22:35:55 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 12 Jan 2008 21:35:55 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za> Message-ID: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za> New submission from Christian Heimes: The output should be self explaining: ./python -tt -E -OO -Qnew -c "import sys; print sys.cmd_flags" ('Qnew', 'O', 'OO', 'E', 't', 'tt') I'll provide doc updates and a mini test if the patch wanted. ---------- components: Interpreter Core files: trunk_sys_cmd_flags.patch keywords: patch messages: 59840 nosy: tiran priority: normal severity: normal status: open title: sys.cmd_flags patch versions: Python 2.6 Added file: http://bugs.python.org/file9143/trunk_sys_cmd_flags.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 12 22:51:36 2008 From: report at bugs.python.org (Alan McIntyre) Date: Sat, 12 Jan 2008 21:51:36 -0000 Subject: [issue1710703] zipfile.ZipFile behavior inconsistent. Message-ID: <1200174696.22.0.88504144481.issue1710703@psf.upfronthosting.co.za> Alan McIntyre added the comment: Here's a quick patch that covers the issues mentioned in my post from 2007-05-09. Added file: http://bugs.python.org/file9144/empty-zipfile.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 12 23:25:38 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Sat, 12 Jan 2008 22:25:38 -0000 Subject: [issue1215] Python hang when catching a segfault In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> Message-ID: <1200176738.83.0.87840083912.issue1215@psf.upfronthosting.co.za> Ralf Schmitt added the comment: If you replace your call segfault.segfault() with os.kill(os.getpid(), signal.SIGSEGV) everything works as expected. The problem is that the signal is just caught in the c handler (and a flag is set) and then the program continues with the offending *c = 'a'; statement, which again ends with a SIGSEGV and the handler being called. The documentation explicitly states "Because the C signal handler always returns, it makes little sense to catch synchronous errors like SIGFPE or SIGSEGV." I think raising that InvalidArgument exception is most probably the right thing to do (or at least printing a warning). Those that really want to handle SIGSEGV should do it from C anyway. ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 00:12:59 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Sat, 12 Jan 2008 23:12:59 -0000 Subject: [issue919238] Recursive variable definition causes sysconfig infinite loop Message-ID: <1200179579.41.0.717332159525.issue919238@psf.upfronthosting.co.za> Ralf Schmitt added the comment: This is still applies for trunk. I've added the following lines to Makefile (in the top level directory). SELF=$(SELFA) SELFA=$(SELF) Running make then hangs. I'm attaching a patch, which fixes this issue (against trunk). Running make now prints: ~/python-trunk/ make ralf at rat64 ok sysconfig.py: warning: could not resolve names from makefile (recursive definition?): {'SELFA': '$(SELF)', 'SELF': '$(SELFA)'} running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers Failed to find the necessary bits to build these modules: _bsddb _tkinter bsddb185 dbm dl gdbm imageop sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. running build_scripts ---------- nosy: +schmir versions: +Python 2.4, Python 2.5, Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 13 00:13:50 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Sat, 12 Jan 2008 23:13:50 -0000 Subject: [issue919238] Recursive variable definition causes sysconfig infinite loop Message-ID: <1200179630.32.0.741339153084.issue919238@psf.upfronthosting.co.za> Changes by Ralf Schmitt: Added file: http://bugs.python.org/file9145/issue919238_sysconfig_recursive_definition.txt ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 13 00:20:24 2008 From: report at bugs.python.org (Adam Olsen) Date: Sat, 12 Jan 2008 23:20:24 -0000 Subject: [issue1215] Python hang when catching a segfault In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> Message-ID: <1200180024.28.0.414781712609.issue1215@psf.upfronthosting.co.za> Adam Olsen added the comment: The warning in the documentation should be strengthened. Python simply does not and cannot support synchronously-generated signals. It is possible to send a normally synchronous signal asynchronously, such as the os.kill() Ralf mentioned, so it's theoretically possible to use custom handlers for them. However, I can't think of any real use cases, and having such a handler would be asking for trouble if a real synchronously-generated signal was produced. I guess that's an argument for not allowing custom handlers. ;) Suggested documentation: "Because of the precarious nature of how synchronously-generated signals must be handled, the signal module does not allow installing handlers for them. This includes SIGSEGV, SIGFPE, SIGBUS, SIGILL, SIGABRT..." I haven't been able to find a canonical list if synchronously-generated signals. Furthermore, I've seen conflicting claims about SIGABRT. ---------- nosy: +Rhamphoryncus __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 00:33:04 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Jan 2008 23:33:04 -0000 Subject: [issue1811] True division of integers could be more accurate In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za> Message-ID: <1200180784.22.0.316282772972.issue1811@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- assignee: -> tim_one __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 00:33:05 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 12 Jan 2008 23:33:05 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za> Message-ID: <1200180785.88.0.545986698136.issue1816@psf.upfronthosting.co.za> Guido van Rossum added the comment: I like the idea of exposing Python's command line flags, but I think this API is a bit odd. I'd rather see it be a struct with members named after the various arguments and values that are ints or bools -- or simply a bunch of new flags directly in the sys module if making it a string is too much work. It also looks like the patch includes a few unrelated changes to install.py and site.py. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 01:03:06 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Sun, 13 Jan 2008 00:03:06 -0000 Subject: [issue919238] Recursive variable definition causes sysconfig infinite loop Message-ID: <1200182586.57.0.831570459109.issue919238@psf.upfronthosting.co.za> Changes by Ralf Schmitt: Added file: http://bugs.python.org/file9146/issue919238_sysconfig_recursive_definition.txt ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 13 01:17:58 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Sun, 13 Jan 2008 00:17:58 -0000 Subject: [issue1676] Fork/exec issues with Tk 8.5/Python 2.5.1 on OS X In-Reply-To: <1198200328.37.0.27301275997.issue1676@psf.upfronthosting.co.za> Message-ID: <1200183478.69.0.635005257104.issue1676@psf.upfronthosting.co.za> Changes by Ralf Schmitt: ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 02:05:30 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 13 Jan 2008 01:05:30 -0000 Subject: [issue1623] Implement PEP-3141 for Decimal In-Reply-To: <1197610504.39.0.97604614618.issue1623@psf.upfronthosting.co.za> Message-ID: <1200186330.41.0.420088071952.issue1623@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: The discussion on issue 1682 concluded that Decimal should not implement Real at all. ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 02:20:45 2008 From: report at bugs.python.org (Thomas Lee) Date: Sun, 13 Jan 2008 01:20:45 -0000 Subject: [issue1810] AST compile() patch In-Reply-To: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za> Message-ID: <1200187245.66.0.215401183765.issue1810@psf.upfronthosting.co.za> Thomas Lee added the comment: I knew it would be a simple one for somebody who knew what to look for :) Thanks Georg! r02 is the updated patch. Changing the title of the tracker issue to reflect that this *should* be a complete patch now. Any further recommendations? ---------- title: Partial AST compile() patch -> AST compile() patch Added file: http://bugs.python.org/file9147/ast-r02.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 02:58:57 2008 From: report at bugs.python.org (Alexandre Fiori) Date: Sun, 13 Jan 2008 01:58:57 -0000 Subject: [issue1817] module-cgi: handling GET and POST together In-Reply-To: <1200189536.91.0.809582793643.issue1817@psf.upfronthosting.co.za> Message-ID: <1200189536.91.0.809582793643.issue1817@psf.upfronthosting.co.za> New submission from Alexandre Fiori: It looks like module-cgi cannot handle GET and POST together when using FieldStorage. For instance, a
is available through cgi.FormContent but not cgi.FieldStorage when there are other in the html form. Very strange. ---------- messages: 59848 nosy: alef13 severity: normal status: open title: module-cgi: handling GET and POST together versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 05:14:22 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 13 Jan 2008 04:14:22 -0000 Subject: [issue1817] module-cgi: handling GET and POST together In-Reply-To: <1200189536.91.0.809582793643.issue1817@psf.upfronthosting.co.za> Message-ID: <1200197662.85.0.737875073367.issue1817@psf.upfronthosting.co.za> Guido van Rossum added the comment: Well, what are you waiting for? Submit a patch! ---------- keywords: +easy nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 06:13:37 2008 From: report at bugs.python.org (Alexandre Fiori) Date: Sun, 13 Jan 2008 05:13:37 -0000 Subject: [issue1817] module-cgi: handling GET and POST together In-Reply-To: <1200189536.91.0.809582793643.issue1817@psf.upfronthosting.co.za> Message-ID: <1200201217.31.0.259035287992.issue1817@psf.upfronthosting.co.za> Alexandre Fiori added the comment: Here it is, babe. I've made appropriate changes to make it read QUERY_STRING when it's available within POST method. It's currently being parsed by parse_qsl() in read_urlencoded() as it should be in regular GET or POST. I didn't touch CONTENT_LENGTH since it has the size of the POST data without QUERY_STRING's size. That would affect read() of such POST data. It's working. Thanks for the incentive, it's my first patch for python. Added file: http://bugs.python.org/file9148/cgi.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 10:14:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 13 Jan 2008 09:14:56 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za> Message-ID: <1200215696.28.0.405159323117.issue1816@psf.upfronthosting.co.za> Christian Heimes added the comment: The new patch is using a struct sequence (like the result of os.stat): >>> import sys >>> sys.flags >>> dir(sys.flags) ['__add__', '__class__', '__contains__', '__delattr__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__', '__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmul__', '__setattr__', '__str__', 'debug', 'division_new', 'division_warning', 'dont_write_bytecode', 'ingnore_environment', 'inspect', 'interactive', 'n_fields', 'n_sequence_fields', 'n_unnamed_fields', 'no_site', 'optimize', 'py3k_warning', 'tabcheck', 'unicode', 'verbose'] >>> sys.flags.debug 0 Please ignore the other files. They are part of my second PEP. Added file: http://bugs.python.org/file9149/trunk_sys_flags.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 12:32:21 2008 From: report at bugs.python.org (Ka-Ping Yee) Date: Sun, 13 Jan 2008 11:32:21 -0000 Subject: [issue1550] help('modules') broken by several 3rd party libraries (svn patch attached) In-Reply-To: <1196699649.3.0.798271270482.issue1550@psf.upfronthosting.co.za> Message-ID: <1200223941.01.0.331518314963.issue1550@psf.upfronthosting.co.za> Ka-Ping Yee added the comment: Committed the patch in revision 59939. I'm not clear how it was determined that importing every module was necessary in order to list the modules or scan their synopsis lines (this seems to have happened in revision 45510). This can probably be made more efficient in the future. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 14:08:48 2008 From: report at bugs.python.org (Andrew Dalke) Date: Sun, 13 Jan 2008 13:08:48 -0000 Subject: [issue1367711] Remove usage of UserDict from os.py Message-ID: <1200229728.71.0.130711771557.issue1367711@psf.upfronthosting.co.za> Andrew Dalke added the comment: Ahh, so the bug here that the environ dict should use neither UserDict nor dict, it should implement the core {get,set,del}item and keys and use DictMixin. Martin mentioned that the patch doesn't support setdefault. He didn't note though that the current code also doesn't support the dictionary interface consistently. This shows a problem with popitem. >>> import os >>> os.environ["USER"] 'dalke' >>> os.environ["USER"] = "nobody" >>> os.system("echo $USER") nobody 0 >>> del os.environ["USER"] >>> os.system("echo $USER") 0 >>> os.environ["USER"] = "dalke" >>> while os.environ: print os.environ.popitem() ... ('GROUP', 'staff') ('XDG_DATA_HOME', '/Users/dalke/.local/share') ('TERM_PROGRAM_VERSION', '133') ('CVS_RSH', 'ssh') ('LOGNAME', 'dalke') ('USER', 'dalke') ... removed for conciseness ... ('QTDIR', '/usr/local/qt') >>> os.system("echo $USER") dalke 0 >>> Not enough people know about DictMixin. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 13 16:04:46 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 13 Jan 2008 15:04:46 -0000 Subject: [issue1700288] Armin's method cache optimization updated for Python 2.6 Message-ID: <1200236686.11.0.386227586966.issue1700288@psf.upfronthosting.co.za> Georg Brandl added the comment: Backed out again in r59940 -- test_ctypes fails in test_incomplete.py. Armin reports that with his original patch on 2.4, this test passes. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 13 16:21:21 2008 From: report at bugs.python.org (Kevin Jacobs) Date: Sun, 13 Jan 2008 15:21:21 -0000 Subject: [issue1700288] Armin's method cache optimization updated for Python 2.6 Message-ID: <1200237681.57.0.16758676881.issue1700288@psf.upfronthosting.co.za> Kevin Jacobs added the comment: All tests passed when I first ported Armin's patch to 2.6. I'll have a chance to look into this later in the week. If anyone gets to it first, please summarize your findings here to avoid duplication of effort. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 13 17:32:10 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 13 Jan 2008 16:32:10 -0000 Subject: [issue1472] Small bat files to build docs on Windows In-Reply-To: <1195529295.02.0.66501222215.issue1472@psf.upfronthosting.co.za> Message-ID: <1200241929.96.0.71740176563.issue1472@psf.upfronthosting.co.za> Georg Brandl added the comment: FTR, I'm currently removing all 2.5isms from Sphinx. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 18:01:56 2008 From: report at bugs.python.org (Kevin Jacobs) Date: Sun, 13 Jan 2008 17:01:56 -0000 Subject: [issue1700288] Armin's method cache optimization updated for Python 2.6 Message-ID: <1200243716.32.0.265798193631.issue1700288@psf.upfronthosting.co.za> Kevin Jacobs added the comment: Couldn't resist looking into this more and I must admit that I am a bit stumped. If instead of returning a value from the cache fast path in _PyType_Lookup, I modified the code to store the value and assert that it matches with the non-cached result from traversing the mro. That assertion never fails. However, test_incomplete works with this change that ideally should not alter the semantics of _PyType_Lookup. More so, if I selectively don't cache the name "next" (with the caching fast path reenabled), test_incomplete works. For test_incomplete, _PyType_Lookup on "next" always return NULL from both the cached and non-cached paths. I'm beginning to suspect there is some black magic going on. None of the relevant reference counts drop to zero, the same return value (NULL) is generated, but the slow patch seems to be doing something with a side effect that makes it work. Wish I had more time to debug this, but I'm already overdrawn until Wednesday... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 13 18:27:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 13 Jan 2008 17:27:32 -0000 Subject: [issue1814] Victor Stinner's GMP patch for longs In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za> Message-ID: <1200245252.81.0.768659808628.issue1814@psf.upfronthosting.co.za> Christian Heimes added the comment: Why was the mpz module removed from Python 2.4 in the first place? 2.3 has it. I see three way to implement the option: * Let somebody implement a mpz type as a 3rd party extension. * Let somebody implement a mpt type and ship it with the Python core * Let somebody write a patch that replaces the built-in long type implementation with a GMP based implementation (./configure --with-gmp-integer) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 18:35:25 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 13 Jan 2008 17:35:25 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za> Message-ID: <1200245725.62.0.586109246834.issue1816@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can't you use a namedtuple? Then printing it would show the names of the flags... __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 18:36:55 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 13 Jan 2008 17:36:55 -0000 Subject: [issue1814] Victor Stinner's GMP patch for longs In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za> Message-ID: <1200245815.4.0.298559775355.issue1814@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't recall, but I suppose it had stopped working and nobody could be found who wanted to maintain it. Possibly the Python-unfriendly license was also a reason. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 18:45:11 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 13 Jan 2008 17:45:11 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <1200245725.62.0.586109246834.issue1816@psf.upfronthosting.co.za> Message-ID: <478A4E24.5050704@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Can't you use a namedtuple? Then printing it would show the names of > the flags... ... and increase the startup costs of Python by loading several additional modules. The collections module imports _collections, operator and keyword. I'd rather see a better repr function for the sequence types. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 19:29:23 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 13 Jan 2008 18:29:23 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za> Message-ID: <1200248963.02.0.0524270822319.issue1816@psf.upfronthosting.co.za> Guido van Rossum added the comment: > I'd rather see a better repr function for the > sequence types. Agreed. It's kind of unfortunate that we have two implementations for the same concept, one in C and one in Python. __________________________________ Tracker __________________________________ From brett at python.org Sun Jan 13 21:19:11 2008 From: brett at python.org (Brett Cannon) Date: Sun, 13 Jan 2008 12:19:11 -0800 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <478A4E24.5050704@cheimes.de> References: <1200245725.62.0.586109246834.issue1816@psf.upfronthosting.co.za> <478A4E24.5050704@cheimes.de> Message-ID: On Jan 13, 2008 9:45 AM, Christian Heimes wrote: > > Christian Heimes added the comment: > > Guido van Rossum wrote: > > Can't you use a namedtuple? Then printing it would show the names of > > the flags... > > ... and increase the startup costs of Python by loading several > additional modules. The collections module imports _collections, > operator and keyword. I'd rather see a better repr function for the > sequence types. Can we make it a function so that it is lazy? That way you can still use namedtuple but it is only imported when the function is called instead of during sys' initialization. From report at bugs.python.org Sun Jan 13 21:19:15 2008 From: report at bugs.python.org (Brett Cannon) Date: Sun, 13 Jan 2008 20:19:15 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <478A4E24.5050704@cheimes.de> Message-ID: Brett Cannon added the comment: On Jan 13, 2008 9:45 AM, Christian Heimes wrote: > > Christian Heimes added the comment: > > Guido van Rossum wrote: > > Can't you use a namedtuple? Then printing it would show the names of > > the flags... > > ... and increase the startup costs of Python by loading several > additional modules. The collections module imports _collections, > operator and keyword. I'd rather see a better repr function for the > sequence types. Can we make it a function so that it is lazy? That way you can still use namedtuple but it is only imported when the function is called instead of during sys' initialization. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 21:37:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 13 Jan 2008 20:37:57 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za> Message-ID: <1200256677.19.0.561884596242.issue1816@psf.upfronthosting.co.za> Christian Heimes added the comment: I've coded sys.flags for my per-user site-packages PEP. I could make it a function but the function would be called by site.py on every startup. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 23:11:06 2008 From: report at bugs.python.org (Achim Gaedke) Date: Sun, 13 Jan 2008 22:11:06 -0000 Subject: [issue1778] SyntaxError.offset sometimes wrong In-Reply-To: <1199920786.95.0.62807405199.issue1778@psf.upfronthosting.co.za> Message-ID: <1200262266.71.0.959627719031.issue1778@psf.upfronthosting.co.za> Achim Gaedke added the comment: sometimes offset is None... Example: def blub(bla, blub=None, blabla): bla causes: non-default argument follows default argument Added file: http://bugs.python.org/file9150/compile_test.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 23:27:16 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 13 Jan 2008 22:27:16 -0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Here's a proof-of-concept patch. If approved, will change from generator form to match the other readers and will add a test suite. The idea corresponds to what is currently done by the dict reader but returns a space and time efficient named tuple instead of a dict. Field order is preserved and named attribute access is supported. A writer is not needed because named tuples can be feed into the existing writer just like regular tuples. ---------- assignee: barry components: Library (Lib) files: ntreader.diff messages: 59866 nosy: barry, rhettinger severity: normal status: open title: Add named tuple reader to CSV module versions: Python 2.6 Added file: http://bugs.python.org/file9151/ntreader.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 23:30:37 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 13 Jan 2008 22:30:37 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1200263437.73.0.369561245554.issue1771@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Let's do this. It is a nice simplification and makes the sort tools easier to learn and use. ---------- assignee: -> rhettinger resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 23:32:30 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 Jan 2008 22:32:30 -0000 Subject: [issue923643] long <-> byte-string conversion Message-ID: <1200263550.24.0.973842334217.issue923643@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Unless I'm mistaken, the patch provides only half of the solution: the stringToLong part, but not longToString. I agree this feature is interesting, not for optimization but becomes it avoids using clunky ways (long -> hex -> bin) to implement something simple. However, perhaps making it part of either the binascii or the struct module would allow more formatting choices (e.g. big-endian or little-endian, fixed-length or not). For example in cryptography you would want a byte string of a fixed size even if your 512-bit number happens to have its 8 most significant bits set to zero. ---------- nosy: +pitrou ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 13 23:41:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 13 Jan 2008 22:41:21 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za> Message-ID: <1200264081.76.0.669683012812.issue1816@psf.upfronthosting.co.za> Christian Heimes added the comment: Does anybody see a problem with this repr slot implementation for structseq? It gives this output: >>> os.stat(".") static PyObject * structseq_repr(PyStructSequence *obj) { PyObject *tup, *val, *repr; PyTypeObject *typ = Py_TYPE(obj); int i, len; char buf[250+5]; /* "...>\0" */ char *cname, *crepr; char *pbuf = buf; char *endbuf = &buf[250]; *pbuf++ = '<'; strncpy(pbuf, typ->tp_name, 50); pbuf += strlen(typ->tp_name) > 50 ? 50 : strlen(typ->tp_name); *pbuf++ = ' '; if ((tup = make_tuple(obj)) == NULL) { return NULL; } for (i=0; i < VISIBLE_SIZE(obj); i++) { cname = typ->tp_members[i].name; val = PyTuple_GetItem(tup, i); if (cname == NULL || val == NULL) { return NULL; } repr = PyObject_Repr(val); if (repr == NULL) { Py_DECREF(tup); return NULL; } crepr = PyString_AsString(repr); if (crepr == NULL) { Py_DECREF(tup); Py_DECREF(repr); return NULL; } len = strlen(cname) + strlen(crepr) + 3; if ((pbuf+len) < endbuf) { strcpy(pbuf, cname); pbuf += strlen(cname); *pbuf++ = '='; strcpy(pbuf, crepr); pbuf += strlen(crepr); *pbuf++ = ','; *pbuf++ = ' '; Py_DECREF(repr); } else { strcpy(pbuf, "..."); pbuf += 5; Py_DECREF(repr); break; } } Py_DECREF(tup); pbuf-=2; *pbuf++ = '>'; *pbuf = '\0'; repr = PyString_FromString(buf); return repr; } __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 13 23:57:32 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 13 Jan 2008 22:57:32 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200265052.18.0.767384810556.issue1682@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: _binary_float_to_ratio: Oops, fixed. Rational() now equals 0, but I'd like to postpone Rational('3/2') until there's a demonstrated need. I don't think it's as common a use as int('3'), and there's more than one possible format, so some real world experience will help (that is, quite possibly not in 2.6/3.0). I'm also postponing Rational(instance_of_numbers_Rational). +/-inf and nan are gone, and hash is fixed, at least until the next bug. :) Good idea about using tuple. Parentheses in str() help with reading things like "%s**2"%Rational(3,2), which would otherwise format as "3/2**2". I don't feel strongly about this. Equality and the comparisons now work for complex, but their implementations make me uncomfortable. In particular, two instances of different Real types may compare unequal to the nearest float, but equal to each other and have similar but inconsistent problems with <=. I can trade off between false ==s and false !=s, but I don't see a way to make everything correct. We could do better by making the intermediate representation Rational instead of float, but comparisons are inherently doomed to run up against the fact that equality is uncomputable on the computable reals, so it's probably not worthwhile to spend too much time on this. I've added a test that float(Rational(long('2'*400+'7'), long('3'*400+'1'))) returns 2.0/3. This works without any explicit scaling on my part because long.__truediv__ already handles it. If there's something else I'm doing wrong around here, I'd appreciate a failing test case. The open issues I know of are: * Is it a good idea to have both numbers.Rational and rational.Rational? Should this class have a different name? * trim and approximate: Let's postpone them to a separate patch (I do think at least one is worth including in 2.6+3.0). So that you don't waste time on them, we already have implementations in the sandbox and (probably) a good-enough explanation at http://en.wikipedia.org/wiki/Continued_fraction#Best_rational_approximations. Thanks for the offer to help out with them. :) * Should Rational.from_float() exist and with the current name? If there's any disagreement, I propose to rename it to Rational._from_float() to discourage use until there's more consensus. * Rational.from_decimal(): punted to a future patch. I favor this for 2.6+3.0. * Rational('3/2') (see above) I think this is close enough to correct to submit and fix up the remaining problems in subsequent patches. If you agree, I'll do so. Added file: http://bugs.python.org/file9152/rational.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 00:12:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 13 Jan 2008 23:12:04 -0000 Subject: [issue1799] Per user site-packages and setup.py install --user patch In-Reply-To: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za> Message-ID: <1200265924.85.0.293035139345.issue1799@psf.upfronthosting.co.za> Christian Heimes added the comment: The new patch adds the -s option, checks for getuid() == geteuid() and adds sys.flags (see #1816). Added file: http://bugs.python.org/file9153/trunk_usersite3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 00:23:49 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 Jan 2008 23:23:49 -0000 Subject: [issue1479611] speed up function calls Message-ID: <1200266629.76.0.419496031485.issue1479611@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch applicable for SVN trunk. However, as Bob I have mixed results on this. For example, functions with variable parameter count have become slower: # With patch $ ./python -m timeit -s "def f(*x): pass" 'for x in xrange(10000): f(1)' 100 loops, best of 3: 4.92 msec per loop $ ./python -m timeit -s "def f(*x): pass" 'for x in xrange(10000): f()' 100 loops, best of 3: 4.07 msec per loop $ ./python -m timeit -s "def f(*x): pass" 'for x in xrange(10000): f(1,2)' 100 loops, best of 3: 5.04 msec per loop # Without patch $ ./python-orig -m timeit -s "def f(*x): pass" 'for x in xrange(10000): f(1)' 100 loops, best of 3: 4.22 msec per loop $ ./python-orig -m timeit -s "def f(*x): pass" 'for x in xrange(10000): f()' 100 loops, best of 3: 3.5 msec per loop $ ./python-orig -m timeit -s "def f(*x): pass" 'for x in xrange(10000): f(1,2)' 100 loops, best of 3: 4.46 msec per loop ---------- nosy: +pitrou Added file: http://bugs.python.org/file9154/funcall.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 14 00:27:14 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 13 Jan 2008 23:27:14 -0000 Subject: [issue1743] IDLE fails to launch In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za> Message-ID: <1200266834.46.0.271868531366.issue1743@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: 1. Could you look at the properties of the .idlerc\recent-files.lst that you saved and compare them to the new file which worked? In particular, what about access permissions? 2. I agree that IDLE should have a better error response if opening a user config file fails. ---------- priority: low -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 00:43:33 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 13 Jan 2008 23:43:33 -0000 Subject: [issue1019] Cleanup pass on _curses and _curses_panel In-Reply-To: <1188041116.84.0.34357084027.issue1019@psf.upfronthosting.co.za> Message-ID: <1200267813.68.0.314390158017.issue1019@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: akuchling -> __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 01:01:42 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 14 Jan 2008 00:01:42 -0000 Subject: [issue1700288] Armin's method cache optimization updated for Python 2.6 Message-ID: <1200268902.74.0.748767279197.issue1700288@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: After some debug work, I found an explanation: - The attribute "name" is the name of a type slot. So it becomes cached during the type construction. - in function ctypes/_ctypes.c::StructUnionType_new(), the type's __dict__ is replaced by a "stgdict". - this "stgdict" is then modified with PyDict_ functions, without any call to _PyType_Lookup() - the method cache becomes out of sync ==> boom. I have come with a patch which corrects the problem, and all ctypes tests pass: Index: Modules/_ctypes/stgdict.c =================================================================== --- Modules/_ctypes/stgdict.c (revision 59939) +++ Modules/_ctypes/stgdict.c (working copy) @@ -470,7 +470,7 @@ Py_DECREF(pair); return -1; } - if (-1 == PyDict_SetItem(realdict, name, prop)) { + if (-1 == PyObject_SetAttr(type, name, prop)) { Py_DECREF(prop); Py_DECREF(pair); return -1; Index: Modules/_ctypes/_ctypes.c =================================================================== --- Modules/_ctypes/_ctypes.c (revision 59939) +++ Modules/_ctypes/_ctypes.c (working copy) @@ -410,7 +410,7 @@ StructType_setattro(PyObject *self, PyObject *key, PyObject *value) { /* XXX Should we disallow deleting _fields_? */ - if (-1 == PyObject_GenericSetAttr(self, key, value)) + if (-1 == Py_TYPE(self)->tp_base->tp_setattro(self, key, value)) return -1; if (value && PyString_Check(key) && I think that these changes are sensible: The first one deal with the type's attribute instead of updating its __dict__, and the second properly delegates "tp_setattro" to the base class ('type' in this case). ---------- nosy: +amaury.forgeotdarc _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 14 01:11:11 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 00:11:11 -0000 Subject: [issue1700288] Armin's method cache optimization updated for Python 2.6 Message-ID: <1200269471.3.0.867876841971.issue1700288@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Nice analysis. Please apply. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 14 01:14:47 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 14 Jan 2008 00:14:47 -0000 Subject: [issue1700288] Armin's method cache optimization updated for Python 2.6 Message-ID: <1200269687.04.0.921207304644.issue1700288@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: OK, I apply first my 2 lines, then the original patch. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 14 01:22:27 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 00:22:27 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1200270147.76.0.289260968971.issue1771@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Patch attached for the C files making them much cleaner and a bit faster. Still needs the related tests to be deleted and the docs updated. Added file: http://bugs.python.org/file9155/nocmp.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 01:28:35 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Mon, 14 Jan 2008 00:28:35 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1200270515.95.0.264001321515.issue1794@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: ---------- nosy: +kbk __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 01:33:31 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Mon, 14 Jan 2008 00:33:31 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables In-Reply-To: <1191982010.97.0.724994014869.issue1252@psf.upfronthosting.co.za> Message-ID: <1200270811.78.0.334469976363.issue1252@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 01:48:21 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Jan 2008 00:48:21 -0000 Subject: [issue1819] Speed hack for function calls with named parameters In-Reply-To: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za> Message-ID: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za> New submission from Antoine Pitrou: This is a patch for SVN trunk which substantially speeds up function calls with named parameters. It does so by taking into account that parameter names should be interned, so before doing full compares we do a first quick loop to compare pointers. On a microbenchmark the speedup is quite distinctive: # With patch $ ./python -m timeit -s "def f(a,b,c,d,e): pass" "f(1,2,3,4,e=5)" 1000000 loops, best of 3: 0.515 usec per loop $ ./python -m timeit -s "def f(a,b,c,d,e): pass" "f(a=1,b=2,c=3,d=4,e=5)" 1000000 loops, best of 3: 0.652 usec per loop # Without patch $ ./python-orig -m timeit -s "def f(a,b,c,d,e): pass" "f(1,2,3,4,e=5)" 1000000 loops, best of 3: 0.664 usec per loop $ ./python-orig -m timeit -s "def f(a,b,c,d,e): pass" "f(a=1,b=2,c=3,d=4,e=5)" 1000000 loops, best of 3: 1.07 usec per loop ---------- components: Interpreter Core files: namedparam.patch messages: 59878 nosy: pitrou severity: normal status: open title: Speed hack for function calls with named parameters versions: Python 2.6 Added file: http://bugs.python.org/file9156/namedparam.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 01:49:02 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Jan 2008 00:49:02 -0000 Subject: [issue1819] Speed hack for function calls with named parameters In-Reply-To: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za> Message-ID: <1200271742.49.0.713356825324.issue1819@psf.upfronthosting.co.za> Changes by Antoine Pitrou: ---------- type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 01:54:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Jan 2008 00:54:45 -0000 Subject: [issue1819] Speed hack for function calls with named parameters In-Reply-To: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za> Message-ID: <1200272085.29.0.905676614704.issue1819@psf.upfronthosting.co.za> Christian Heimes added the comment: Nice! Is this somehow related to #1479611? The formatting of the code looks kinda strange. Have you mixed tabs and spaces? ---------- assignee: -> gvanrossum keywords: +patch nosy: +gvanrossum, tiran priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 02:01:49 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Jan 2008 01:01:49 -0000 Subject: [issue1819] Speed hack for function calls with named parameters In-Reply-To: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za> Message-ID: <1200272509.8.0.565153953858.issue1819@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sorry, my editor indents with spaces by default. Attaching a fixed patch with tabs. No, it is independent from #1479611 (and much simpler). Added file: http://bugs.python.org/file9157/namedparam.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 02:11:46 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 14 Jan 2008 01:11:46 -0000 Subject: [issue1700288] Armin's method cache optimization updated for Python 2.6 Message-ID: <1200273106.91.0.822694766548.issue1700288@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: For the record: It is very wrong to call self->ob_type->tp_base's slot: slots are often copied from their base class, and you get infinite recursion. Calling StructType.tp_base->tp_setattro is much better. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 14 02:25:40 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Jan 2008 01:25:40 -0000 Subject: [issue1819] Speed hack for function calls with named parameters In-Reply-To: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za> Message-ID: <1200273939.95.0.463250016139.issue1819@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Another quick test: # With patch $ ./python -m timeit -s "d=dict(a=1,b=2,c=3,d=4,e=5);f = lambda a,b,c,d,e:0" "f(**d)" 1000000 loops, best of 3: 0.727 usec per loop $ ./python -m timeit -s "d=dict(b=2,c=3,d=4,e=5);f = lambda a,b,c,d,e:0" "f(a=1,**d)" 1000000 loops, best of 3: 1.16 usec per loop $ ./python -m timeit -s "d=dict(b=2,c=3,d=4,e=5); f=lambda **kw:0" "f(**d)" 1000000 loops, best of 3: 0.917 usec per loop # Without patch $ ./python-orig -m timeit -s "d=dict(a=1,b=2,c=3,d=4,e=5);f = lambda a,b,c,d,e:0" "f(**d)" 1000000 loops, best of 3: 1.24 usec per loop $ ./python-orig -m timeit -s "d=dict(b=2,c=3,d=4,e=5);f = lambda a,b,c,d,e:0" "f(a=1,**d)" 1000000 loops, best of 3: 1.62 usec per loop $ ./python-orig -m timeit -s "d=dict(b=2,c=3,d=4,e=5); f=lambda **kw:0" "f(**d)" 1000000 loops, best of 3: 0.904 usec per loop __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 02:40:04 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 14 Jan 2008 01:40:04 -0000 Subject: [issue1799] Per user site-packages and setup.py install --user patch In-Reply-To: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za> Message-ID: <1200274804.31.0.956234176048.issue1799@psf.upfronthosting.co.za> Gregory P. Smith added the comment: nice. ping a mac developer for what to do with the darwin stuff that you commented out. It'd also be nice to have unit tests for the new behavior. Though i don't think we have many (any?) of that type of regression test right now. Such a test would need to setup a test user site package, os.system another instance python with and without -s to confirm if it saw the test site package that was just created or not followed by cleaning it all up. ---------- nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 02:45:49 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 14 Jan 2008 01:45:49 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200275149.2.0.619514227841.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: The latest version of rational.py looks good to me---nice work! (I haven't looked properly at numbers.py or test_rational.py, yet. I do plan to, eventually.) I do think it's important to be able to create Rational instances from strings: e.g., for easy reading from and writing to files. But maybe I'm alone in this opinion. You say there's more than one possible format---what other formats were you considering? And since you pointed it out, I think Rational(Rational(a, b)) should work too. There's also the not-entirely-insignificant matter of documentation :) Other than that, I don't see why this shouldn't go in. Other comments: I have a weak preference for no parentheses on the str() of a Rational, but it's no big deal either way. I agree that equality and comparisons are messy. This seems almost inevitable: one obvious cause is that the existing int <-> float comparisons already break the `numeric tower' model (push both operands to the highest common type before operating). So I'm not sure there can be an easy and elegant solution here :( I like the name Rational for this class. Maybe change the name of numbers.Rational instead? Postponing trim, approximate, from_decimal sounds fine to me. Finally: the very first line of rational.py is, I think, no longer accurate. Please add your name so everyone knows who to blame/credit/assign bug reports to :) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 03:33:56 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Jan 2008 02:33:56 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1200278036.32.0.832928343147.issue1771@psf.upfronthosting.co.za> Guido van Rossum added the comment: Cool! Doesn't it feel good to rip out stuff? :-) I do hope that you'll make sure all tests pass (-uall) before submitting this. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 04:07:31 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 14 Jan 2008 03:07:31 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200280051.86.0.0741183390165.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: Just had a quick look at numbers.py. Only two comments: 1. I think there's a typo in the docstring for Inexact: one of those == should be a != 2. Not that it really matters now, but note that at least for Decimal, x-y is not the same as x+(-y) (I'm looking at Complex.__sub__), and +x is not a no-op (Real.real, Real.conjugate). In both cases signs of zeros can be problematic: >>> x = Decimal('-0') >>> y = Decimal('0') >>> x-y Decimal("-0") >>> x+(-y) Decimal("0") >>> x Decimal("-0") >>> +x Decimal("0") Of course the first point wouldn't matter anyway since Decimal already implements __sub__; the second means that if Decimal were to join Real, something would need to be done to avoid Decimal("-0").real becoming Decimal("0"). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 04:15:49 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Jan 2008 03:15:49 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za> Message-ID: <1200280549.24.0.179048088138.issue1816@psf.upfronthosting.co.za> Guido van Rossum added the comment: Nice -- perhaps you can make it look like a function call, posix.stat_result(st_mode=..., ...)? (Then someone else might finally create a constructor with such a signature. :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 05:20:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Jan 2008 04:20:28 -0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> New submission from Christian Heimes: Raymond Hettinger wrote: Here's a couple more if you want to proceed down that path: 1. Have structseq subclass from PyTupleObject so that isinstance(s, tuple) returns True. This makes the object usable whenever tuples are needed. 2. Add _fields, _asdict, and _replace to match the API in collections.namedtuple(). The _fields tuple should only include the visible positional fields while _asdict() and _replace() should include all of the fields whether visible or accessible only by attribute access. 3. Change the constructor to accept keyword args so that eval(repr(s)) == s works. NOTE: I've marked the task as easy but it's not a task for a total newbie. It's a feasible yet challenging task for somebody who likes to get into CPython core programming. Basic C knowledge is required! ---------- components: Interpreter Core keywords: easy messages: 59888 nosy: rhettinger, tiran priority: low severity: normal status: open title: Enhance Object/structseq.c to match namedtuple and tuple api type: rfe versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 05:41:42 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Jan 2008 04:41:42 -0000 Subject: [issue1816] sys.cmd_flags patch In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za> Message-ID: <1200285702.34.0.501228464299.issue1816@psf.upfronthosting.co.za> Christian Heimes added the comment: Committed in r59947, r59948 and r59949 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 05:48:20 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Jan 2008 04:48:20 -0000 Subject: [issue1799] Per user site-packages and setup.py install --user patch In-Reply-To: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za> Message-ID: <1200286100.21.0.780071218625.issue1799@psf.upfronthosting.co.za> Changes by Christian Heimes: Added file: http://bugs.python.org/file9158/trunk_usersite4.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 05:48:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Jan 2008 04:48:26 -0000 Subject: [issue1799] Per user site-packages and setup.py install --user patch In-Reply-To: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za> Message-ID: <1200286106.78.0.629104792905.issue1799@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file9131/trunk_usersite.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 05:48:35 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Jan 2008 04:48:35 -0000 Subject: [issue1799] Per user site-packages and setup.py install --user patch In-Reply-To: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za> Message-ID: <1200286115.12.0.220808025593.issue1799@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file9153/trunk_usersite3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 07:16:49 2008 From: report at bugs.python.org (surekap) Date: Mon, 14 Jan 2008 06:16:49 -0000 Subject: [issue779460] plistlib should be moved out of plat-mac Message-ID: <1200291409.66.0.58310883215.issue779460@psf.upfronthosting.co.za> surekap added the comment: Request we reopen this issue since it was marked duplicate of #1565129 and both were closed but the problem was not resolved. plistlib.py did not make it into Python 2.5. ---------- nosy: +surekap ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 14 08:03:22 2008 From: report at bugs.python.org (Leif Walsh) Date: Mon, 14 Jan 2008 07:03:22 -0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1200294202.65.0.939203103796.issue1820@psf.upfronthosting.co.za> Leif Walsh added the comment: Here is a patch for #1. I ran make test, and nothing was broken that seemed to be my fault, so I assume it's okay. Yes, it's small, it's my first one here. I'll get to the other two tomorrow. ---------- nosy: +adlaiff6 Added file: http://bugs.python.org/file9159/structseq_subclasses_tuple.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 09:39:41 2008 From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=) Date: Mon, 14 Jan 2008 08:39:41 -0000 Subject: [issue1782] PyModule_AddIntConstant and PyModule_AddStringConstant can leak In-Reply-To: <1199976472.88.0.939409341911.issue1782@psf.upfronthosting.co.za> Message-ID: <1200299981.12.0.392505031468.issue1782@psf.upfronthosting.co.za> Hrvoje Nik?i? added the comment: Here is a patch, as per description above. Added file: http://bugs.python.org/file9160/addpatch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 10:55:00 2008 From: report at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Mon, 14 Jan 2008 09:55:00 -0000 Subject: [issue1821] configure.ac change for FreeBSD In-Reply-To: <1200304500.14.0.254653989015.issue1821@psf.upfronthosting.co.za> Message-ID: <1200304500.14.0.254653989015.issue1821@psf.upfronthosting.co.za> New submission from Jeroen Ruigrok van der Werven: FreeBSD has in its ports currently a change for Modules/_ctypes/libffi/ configure.ac that adds amd64-*-freebsd* next to x86_64. I have attached said patch (but updated to be a diff to trunk) and I hope it can be changed in trunk to minimize patches in the ports tree. ---------- components: Build files: patch-Modules-_ctypes-libffi-configure.diff messages: 59893 nosy: asmodai severity: minor status: open title: configure.ac change for FreeBSD type: rfe versions: Python 2.5 Added file: http://bugs.python.org/file9161/patch-Modules-_ctypes-libffi-configure.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 11:37:00 2008 From: report at bugs.python.org (Thomas Heller) Date: Mon, 14 Jan 2008 10:37:00 -0000 Subject: [issue1821] configure.ac change for FreeBSD In-Reply-To: <1200304500.14.0.254653989015.issue1821@psf.upfronthosting.co.za> Message-ID: <1200307020.96.0.426815166648.issue1821@psf.upfronthosting.co.za> Thomas Heller added the comment: Thanks. Committed in trunk as rev. 59952. ---------- assignee: -> theller nosy: +theller resolution: -> fixed status: open -> closed versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 11:54:57 2008 From: report at bugs.python.org (Jonathan Share) Date: Mon, 14 Jan 2008 10:54:57 -0000 Subject: [issue1822] email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added. In-Reply-To: <1200308097.55.0.0363931421733.issue1822@psf.upfronthosting.co.za> Message-ID: <1200308097.55.0.0363931421733.issue1822@psf.upfronthosting.co.za> New submission from Jonathan Share: Steps to reproduce ================== >>> from email.mime.multipart import MIMEMultipart >>> foo = MIMEMultipart() >>> foo.is_multipart() False Expected Result =============== True should be returned from MIMEMultipart.is_multipart() Notes ===== Looking at the implementation of is_multipart() in email.Message it would appear that if self._payload was initialised to an empty list in the constructor of MIMEMultipart when _subparts is None, this would be a sufficient fix for this issue. However, from an outsider looking into this code for the first time, this doesn't look like the best architecture, shouldn't the issue of whether a message has multiple parts, and logic specific to this be handled through inheritance. With the current implementation the superclass makes assumptions about how a subclass is implemented, this just feels wrong. Have I missed something, is there a good reason for things being as they are today? Feel free to take the discussion to the python-dev list, I have just subscribed, and I am interested in fixing this issue myself in the next bug day if someone can answer my questions above. ---------- components: Library (Lib) messages: 59895 nosy: Sharebear severity: normal status: open title: email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added. type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 12:17:14 2008 From: report at bugs.python.org (Jonathan Share) Date: Mon, 14 Jan 2008 11:17:14 -0000 Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za> Message-ID: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za> New submission from Jonathan Share: Steps to Reproduce ================== >>> from email.mime.multipart import MIMEMultipart >>> from email.mime.text import MIMEText >>> multipart = MIMEMultipart() >>> multipart.set_charset('UTF-8') >>> text = MIMEText("sample text") >>> multipart.attach(text) >>> print multipart.as_string() MIME-Version: 1.0 Content-Type: multipart/mixed; charset="utf-8"; boundary="===============0973828728==" Content-Transfer-Encoding: base64 --===============0973828728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit sample text --===============0973828728==-- >>> multipart = MIMEMultipart() >>> multipart.attach(text) >>> multipart.set_charset('UTF-8') Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ email/message.py", line 262, in set_charset self._payload = charset.body_encode(self._payload) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ email/charset.py", line 384, in body_encode return email.base64mime.body_encode(s) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ email/base64mime.py", line 148, in encode enc = b2a_base64(s[i:i + max_unencoded]) TypeError: b2a_base64() argument 1 must be string or read-only buffer, not list Explanation =========== The first example above demonstrates that if you call set_charset('UTF- 8') on a MIMEMultipart instance before adding child parts then it is possible to generate a multipart/* message with an illegal Content- Transfer-Encoding as specified by RFC 2045[1] "If an entity is of type "multipart" the Content-Transfer-Encoding is not permitted to have any value other than "7bit", "8bit" or "binary"." In the second example, I demonstrate that if you try and call set_charset after adding child parts, the code exceptions. The user should at least be provided with a more targeted exception. Notes ===== Where should this be fixed? The smallest fix would be to add a check to set_charset to see if it is dealing with with a multipart message but as I express in issue1822 I feel the better design would be to move this subtype specific logic into the appropriate subclass. Again, this is something I'm willing to work on in next saturday's bug day if I can get some feedback on my architectural concerns. [1] http://tools.ietf.org/html/rfc2045#section-6.4 ---------- components: Library (Lib) messages: 59896 nosy: Sharebear severity: normal status: open title: Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 14:32:03 2008 From: report at bugs.python.org (Thomas Lee) Date: Mon, 14 Jan 2008 13:32:03 -0000 Subject: [issue1625] bz2.BZ2File doesn't support multiple streams In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za> Message-ID: <1200317523.22.0.627667283673.issue1625@psf.upfronthosting.co.za> Thomas Lee added the comment: If you're referring to an 'append' mode for bz2file objects, it may be a limitation of the underlying library: my version of bzlib.h only provides BZ2_bzWriteOpen and BZ2_bzReadOpen - it's not immediately clear how you would open a BZ2File in append mode looking at this API. It may be possible to implement r/w/a using the lower-level bzCompress/bzDecompress functions, but I doubt that's going to happen unless somebody (such as yourself? :)) cares deeply about this. ---------- nosy: +thomas.lee __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 14:37:34 2008 From: report at bugs.python.org (Thomas Lee) Date: Mon, 14 Jan 2008 13:37:34 -0000 Subject: [issue1772] popen fails when there are two or more pathnames/parameters with spaces In-Reply-To: <1199859779.21.0.234395665559.issue1772@psf.upfronthosting.co.za> Message-ID: <1200317854.5.0.309955005487.issue1772@psf.upfronthosting.co.za> Thomas Lee added the comment: Do you have a code sample that reproduces this issue? Which popen module and/or function are you using to execute this command? ---------- nosy: +thomas.lee __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 16:27:06 2008 From: report at bugs.python.org (Eric Sammons) Date: Mon, 14 Jan 2008 15:27:06 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za> Message-ID: <1200324426.14.0.125200959263.issue1327@psf.upfronthosting.co.za> Eric Sammons added the comment: Please find the attached ceval.c. This file was generated from oprofile and gives clear indicators where the simple program below gets hung up. You will find in the oprofile output, from ceval.c, that PyEval_Frame has a total of 1649 26.2789. This indicates with a high degree of probabilty that the changes made in this portion of the code are promblamatic. Now I will be the first to admit that I am by no means a C programmer; however, I can tell you that the code has changed a great deal with regards to xmlrpc and it has impacted performance to the point where it seems to be unusable with current releases of Python where expected output is > 300 records. Please check it out for yourself, using a different xmlrpc server - I currently have access to one only where the number of records is greater than 300. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 17:00:26 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 14 Jan 2008 16:00:26 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za> Message-ID: <1200326426.2.0.520547216522.issue1327@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I don't think ceval is the issue here. > the code has changed a great deal with regards to xmlrpc I am not sure to understand what you mean: xmlrpc is mostly written in python code. ceval.c is the place where the interpreter executes python code. PyEval_EvalFrame is the loop that reads and dispatches each python instruction. Of course this function is time-critical, but the problem probably is that too many python code is executed. I suggest you to use the python-level profiler: http://docs.python.org/lib/profile-instant.html This may reveal some interesting things in the xmlrpclib module. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 17:05:14 2008 From: report at bugs.python.org (Facundo Batista) Date: Mon, 14 Jan 2008 16:05:14 -0000 Subject: [issue1819] Speed hack for function calls with named parameters In-Reply-To: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za> Message-ID: <1200326714.12.0.846417110296.issue1819@psf.upfronthosting.co.za> Changes by Facundo Batista: ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 17:11:03 2008 From: report at bugs.python.org (Jim Wilson) Date: Mon, 14 Jan 2008 16:11:03 -0000 Subject: [issue1824] UUIDCreate()->UuidCreate() in msilib docs. In-Reply-To: <1200327062.94.0.635681629699.issue1824@psf.upfronthosting.co.za> Message-ID: <1200327062.94.0.635681629699.issue1824@psf.upfronthosting.co.za> New submission from Jim Wilson: At http://docs.python.org/lib/module-msilib.html, UUIDCreate() is misspelled. ---------- components: Documentation messages: 59901 nosy: Jimbo severity: minor status: open title: UUIDCreate()->UuidCreate() in msilib docs. type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 17:28:16 2008 From: report at bugs.python.org (Rich) Date: Mon, 14 Jan 2008 16:28:16 -0000 Subject: [issue1743] IDLE fails to launch In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za> Message-ID: <1200328096.25.0.0232167479803.issue1743@psf.upfronthosting.co.za> Rich added the comment: Aha! There is no difference in Permissions, but the working recent- files file isn't "hidden" but the one generated originally by IDLE was. If I make the one I made "hidden" then IDLE stops working again. The .idlerc folder has been hidden all along though - that doesn't affect it. If anyone's changing the way IDLE writes these files, would it be worth me saying that aesthetically, I'm not a fan of it putting them in a hidden folder in my top level User folder. What about putting them down inside Users/AppData like other applications do? Just a thought. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 17:45:08 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 14 Jan 2008 16:45:08 -0000 Subject: [issue1725737] Distutils default exclude doesn't match top level .svn Message-ID: <1200329108.56.0.272905142923.issue1725737@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I suggest this bug be closed as invalid. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 14 17:49:03 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 14 Jan 2008 16:49:03 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py In-Reply-To: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za> Message-ID: <1200329343.74.0.343539007964.issue1294@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: bugday task? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 17:59:47 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 14 Jan 2008 16:59:47 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za> Message-ID: <1200329987.3.0.0835328771363.issue1327@psf.upfronthosting.co.za> Skip Montanaro added the comment: Do you have an example which doesn't require a login? Failing that, can you tell us how to get the requisite login? Skip ---------- nosy: +skip.montanaro __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 19:19:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Jan 2008 18:19:34 -0000 Subject: [issue1713041] fix for 1712742: corrects pprint's handling of 'depth' Message-ID: <1200334774.45.0.0990253621098.issue1713041@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 14 19:20:38 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Jan 2008 18:20:38 -0000 Subject: [issue1824] UUIDCreate()->UuidCreate() in msilib docs. In-Reply-To: <1200327062.94.0.635681629699.issue1824@psf.upfronthosting.co.za> Message-ID: <1200334838.16.0.756712777449.issue1824@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 19:43:47 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Jan 2008 18:43:47 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py In-Reply-To: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za> Message-ID: <1200336227.73.0.648897583261.issue1294@psf.upfronthosting.co.za> Guido van Rossum added the comment: To mark things for the bugday, set the 'easy' keyword. However, this particular one is IMO too subtle for a bugday, witness the discussion here. Perhaps a bugday could come up with an ultimate patch, but I'd be hesitant to submit it without having reviewed it personally. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 19:53:43 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 14 Jan 2008 18:53:43 -0000 Subject: [issue1824] UUIDCreate()->UuidCreate() in msilib docs. In-Reply-To: <1200327062.94.0.635681629699.issue1824@psf.upfronthosting.co.za> Message-ID: <1200336823.21.0.249188263688.issue1824@psf.upfronthosting.co.za> Georg Brandl added the comment: Already fixed in SVN. ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 20:10:06 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 14 Jan 2008 19:10:06 -0000 Subject: [issue1215] Python hang when catching a segfault In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> Message-ID: <1200337806.74.0.197735022078.issue1215@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Should I work on a patch, which makes signal.signal raise an Exception for SIGSEGV, SIGBUS, SIGFPE,...? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 20:12:40 2008 From: report at bugs.python.org (Jim Wilson) Date: Mon, 14 Jan 2008 19:12:40 -0000 Subject: [issue1825] msilib.add_data() takes exactly three parameters In-Reply-To: <1200337960.21.0.113421612542.issue1825@psf.upfronthosting.co.za> Message-ID: <1200337960.21.0.113421612542.issue1825@psf.upfronthosting.co.za> New submission from Jim Wilson: At: http://docs.python.org/lib/module-msilib.html, add_data(...) is documented to take two parameters, but invoking it with two draws a complaint that three are needed. Examination of bdist_msi.py leads me to believe the missing (middle) parameter is "table", but I can barely distinguish a database from a hole in the ground. ---------- components: Documentation messages: 59909 nosy: Jimbo severity: minor status: open title: msilib.add_data() takes exactly three parameters type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 20:13:09 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Jan 2008 19:13:09 -0000 Subject: [issue1215] Python hang when catching a segfault In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> Message-ID: <1200337989.58.0.761885896392.issue1215@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm not sure what the point of that would be. Somebody might want to send these asynchronously (using kill) which we might legitimately want to catch. Also you don't know which other synchronous signals a platform might define. I think at best a doc update on the relative uselessness of handlers for synchronous signals (with examples) is all we need. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 20:22:21 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 14 Jan 2008 19:22:21 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: operator.attrgetter() is neutered because it only accepts a single attribute name, but it would really be much more useful if it accepted, and followed a dotted attribute path, e.g.: sorted(seq, key=operator.attrgetter('person.displayname')) Of course attrgetter() would raise AttributeError if the entire path could not be traversed. ---------- components: Library (Lib) keywords: easy messages: 59911 nosy: barry severity: normal status: open title: operator.attrgetter() should accept dotted attribute paths type: rfe versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 20:30:53 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 14 Jan 2008 19:30:53 -0000 Subject: [issue1215] Python hang when catching a segfault In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> Message-ID: <1200339053.35.0.539461294365.issue1215@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Those who want to legitimately catch SIGSEGV will end up with an uninterruptible python process using 100 % CPU on a real segmentation fault. But, then I can live with the current behaviour. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 20:32:46 2008 From: report at bugs.python.org (Adam Olsen) Date: Mon, 14 Jan 2008 19:32:46 -0000 Subject: [issue1215] Python hang when catching a segfault In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> Message-ID: <1200339166.41.0.384410481712.issue1215@psf.upfronthosting.co.za> Adam Olsen added the comment: In essence, it's a weakness of the POSIX API that it doesn't distinguish synchronous from asynchronous signals. The consequences of either approach seem minor though. I cannot imagine a sane use case for catching SIGSEGV, but documentation changes should be sufficient anyway. Suggested wording, if you take the documentation-only approach: "Because of the precarious nature of how synchronously-generated signals must be handled, it is impossible to handle them correctly from python. You should never install handlers for synchronously-generated signals, such as SIGSEGV and SIGFPE." __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 20:35:51 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Jan 2008 19:35:51 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200339351.32.0.757627592106.issue1826@psf.upfronthosting.co.za> Guido van Rossum added the comment: How about a slight change to the proposed API, and make it a varargs function? E.g. operator.attrgetter('person', 'displayname') This would avoid the need to parse the argument. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 20:40:32 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 14 Jan 2008 19:40:32 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200339632.27.0.828007138101.issue1826@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Unfortunately, that already has different, existing (and IMHO less useful) semantics. :( __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 20:41:56 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Jan 2008 19:41:56 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200339716.79.0.74483292384.issue1826@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fair enough. Fine with me then. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 21:35:31 2008 From: report at bugs.python.org (Matthias Kievernagel) Date: Mon, 14 Jan 2008 20:35:31 -0000 Subject: [issue429031] Text widget, bindtags and Tabs Message-ID: <1200342931.16.0.427327372322.issue429031@psf.upfronthosting.co.za> Changes by Matthias Kievernagel: ---------- nosy: +mkiever ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 14 21:42:56 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 20:42:56 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200343376.12.0.662947449489.issue1826@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Mind if I take a look at the patch before it goes in? ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 21:45:44 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 14 Jan 2008 20:45:44 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200343544.34.0.883614278395.issue1826@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I don't even mind if you *write* the patch :) I actually haven't had time yet to hack it up, but I just reached my threshold of tolerance so I had to at least report the bug. I think it's always a good idea to review patches before they go in anyway, so if I work one up, I'll attach it here. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 21:47:28 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 14 Jan 2008 20:47:28 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200343648.35.0.113867209684.issue1826@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Hey Guido, can I borrow the keys to the time machine to get this into Python 2.5.0? :) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 22:19:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Jan 2008 21:19:52 -0000 Subject: [issue1827] svnversion_init() doesn't support svn urls in sandbox/trunk In-Reply-To: <1200345592.67.0.60555355752.issue1827@psf.upfronthosting.co.za> Message-ID: <1200345592.67.0.60555355752.issue1827@psf.upfronthosting.co.za> New submission from Christian Heimes: Python fails to start if headurl points to a svn url under sandbox/. Python/sysmodule.c:svnversion_init() should support those urls or at least fail silently. static const char headurl[] = "$HeadURL: svn+ssh://pythondev at svn.python.org/sandbox/trunk/pep370/Python/sysmodule.c $" ---------- components: Build, Interpreter Core messages: 59920 nosy: tiran priority: normal severity: normal status: open title: svnversion_init() doesn't support svn urls in sandbox/trunk versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 22:35:37 2008 From: report at bugs.python.org (Thomas Heller) Date: Mon, 14 Jan 2008 21:35:37 -0000 Subject: [issue1796] ctypes should allow a tuple when an Array is expected In-Reply-To: <1200079028.65.0.512467714236.issue1796@psf.upfronthosting.co.za> Message-ID: <1200346537.32.0.872415375699.issue1796@psf.upfronthosting.co.za> Thomas Heller added the comment: Lenard Lindstrom pointed out in a post to the ctypes-users list that pointer instances must not be accepted. Uploaded new patch ctypes-array-2.patch. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 22:36:05 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 14 Jan 2008 21:36:05 -0000 Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za> Message-ID: <1200346565.78.0.958354048879.issue1823@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'd like to question whether anything needs to be fixed at all, i.e. whether it is the responsibility of the email package to reject all kinds of non-sensical data. Garbage in, garbage out. Barry, can you take a look? ---------- assignee: -> barry nosy: +barry, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 22:36:23 2008 From: report at bugs.python.org (Thomas Heller) Date: Mon, 14 Jan 2008 21:36:23 -0000 Subject: [issue1796] ctypes should allow a tuple when an Array is expected In-Reply-To: <1200079028.65.0.512467714236.issue1796@psf.upfronthosting.co.za> Message-ID: <1200346583.33.0.203126543783.issue1796@psf.upfronthosting.co.za> Changes by Thomas Heller: Added file: http://bugs.python.org/file9162/ctypes-array-2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 22:36:29 2008 From: report at bugs.python.org (Thomas Heller) Date: Mon, 14 Jan 2008 21:36:29 -0000 Subject: [issue1796] ctypes should allow a tuple when an Array is expected In-Reply-To: <1200079028.65.0.512467714236.issue1796@psf.upfronthosting.co.za> Message-ID: <1200346589.32.0.568559124747.issue1796@psf.upfronthosting.co.za> Changes by Thomas Heller: Removed file: http://bugs.python.org/file9127/ctypes-arrays.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 22:41:54 2008 From: report at bugs.python.org (Thomas Heller) Date: Mon, 14 Jan 2008 21:41:54 -0000 Subject: [issue1796] ctypes should allow a tuple when an Array is expected In-Reply-To: <1200079028.65.0.512467714236.issue1796@psf.upfronthosting.co.za> Message-ID: <1200346914.75.0.586309109955.issue1796@psf.upfronthosting.co.za> Changes by Thomas Heller: Removed file: http://bugs.python.org/file9162/ctypes-array-2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 22:42:42 2008 From: report at bugs.python.org (Thomas Heller) Date: Mon, 14 Jan 2008 21:42:42 -0000 Subject: [issue1796] ctypes should allow a tuple when an Array is expected In-Reply-To: <1200079028.65.0.512467714236.issue1796@psf.upfronthosting.co.za> Message-ID: <1200346962.02.0.701623360428.issue1796@psf.upfronthosting.co.za> Thomas Heller added the comment: Corrected the patch to NOT accept None. Added file: http://bugs.python.org/file9163/ctypes-array-3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 22:51:06 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 14 Jan 2008 21:51:06 -0000 Subject: [issue1743] IDLE fails to launch In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za> Message-ID: <1200347466.06.0.611435354213.issue1743@psf.upfronthosting.co.za> Martin v. L?wis added the comment: We should clearly separate issues. Changing the organization of files is entirely independent from fixing the bug reported here, and the issues must not at all be mixed. I'm puzzled as to why making the file hidden should have any effect, but at least that's something that we can try to reproduce. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 22:53:32 2008 From: report at bugs.python.org (Stephan Hoermann) Date: Mon, 14 Jan 2008 21:53:32 -0000 Subject: [issue1772] popen fails when there are two or more pathnames/parameters with spaces In-Reply-To: <1199859779.21.0.234395665559.issue1772@psf.upfronthosting.co.za> Message-ID: <1200347612.08.0.127700588894.issue1772@psf.upfronthosting.co.za> Stephan Hoermann added the comment: I have attached some code that demonstrates the bug. You need to run it on Windows and you need to place some bat file (it doesn't need to do anything just exist) at C:\Program Files\test.bat (or change the reference in the code, but it does need to include spacing). The first popen call works the second popen call will fail, because there are 2 pathnames in the code with spaces. I am using the popen4 module in os but I also tested popen2 and popen3 and they do the same thing. Added file: http://bugs.python.org/file9164/popen_bug.py __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 22:54:48 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 14 Jan 2008 21:54:48 -0000 Subject: [issue1825] msilib.add_data() takes exactly three parameters In-Reply-To: <1200337960.21.0.113421612542.issue1825@psf.upfronthosting.co.za> Message-ID: <1200347688.56.0.69894250092.issue1825@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for pointing that out. The table argument must be one of the predefined tables in the MSI schema, e.g. Feature, File, Component, Dialog, Control, InstallExecuteSequence, etc. The values are the values added to that table ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 23:03:31 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 14 Jan 2008 22:03:31 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200348211.4.0.37217980444.issue1826@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What's wrong with sorted(seq, key=lambda v:v.person.displayname) ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 23:10:37 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 14 Jan 2008 22:10:37 -0000 Subject: [issue1827] svnversion_init() doesn't support svn urls in sandbox/trunk In-Reply-To: <1200345592.67.0.60555355752.issue1827@psf.upfronthosting.co.za> Message-ID: <1200348637.72.0.584181626012.issue1827@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I fail to see why it is a bug that such URLs are not supported - why can't you develop pep370 in a regular branch? As an RFE, it would certainly possible to support such a case. If either /python/ isn't found, or isn't followed by tags/branches/trunk, I'd set shortbranch to "foreign". ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 23:16:15 2008 From: report at bugs.python.org (Matthias Kievernagel) Date: Mon, 14 Jan 2008 22:16:15 -0000 Subject: [issue429031] Text widget, bindtags and Tabs Message-ID: <1200348975.84.0.419525686744.issue429031@psf.upfronthosting.co.za> Matthias Kievernagel added the comment: skip was right. An equivalent tcl program shows the same behaviour. Tested with tcl/tk 8.4.6 Corrected python scripts (the original attached files were broken) and equivalent tcl scripts attached. Matthias Kievernagel Added file: http://bugs.python.org/file9165/429031-tabs-ok.py ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 14 23:16:45 2008 From: report at bugs.python.org (Matthias Kievernagel) Date: Mon, 14 Jan 2008 22:16:45 -0000 Subject: [issue429031] Text widget, bindtags and Tabs Message-ID: <1200349005.37.0.805053601337.issue429031@psf.upfronthosting.co.za> Changes by Matthias Kievernagel: Added file: http://bugs.python.org/file9166/429031-tabs-nok.py ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 14 23:17:13 2008 From: report at bugs.python.org (Matthias Kievernagel) Date: Mon, 14 Jan 2008 22:17:13 -0000 Subject: [issue429031] Text widget, bindtags and Tabs Message-ID: <1200349033.87.0.480024941382.issue429031@psf.upfronthosting.co.za> Changes by Matthias Kievernagel: Added file: http://bugs.python.org/file9167/429031-tabs-ok.tcl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 14 23:17:30 2008 From: report at bugs.python.org (Matthias Kievernagel) Date: Mon, 14 Jan 2008 22:17:30 -0000 Subject: [issue429031] Text widget, bindtags and Tabs Message-ID: <1200349050.41.0.829040689113.issue429031@psf.upfronthosting.co.za> Changes by Matthias Kievernagel: Added file: http://bugs.python.org/file9168/429031-tabs-nok.tcl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 14 23:25:45 2008 From: report at bugs.python.org (Scott Dial) Date: Mon, 14 Jan 2008 22:25:45 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200349544.99.0.637247462419.issue1826@psf.upfronthosting.co.za> Scott Dial added the comment: I want to clarify that the proposed change would break: operator.attrgetter(foo)(bar) == getattr(bar, foo) Which is the documented intent of the operator module: "This module exports a set of functions implemented in C corresponding to the intrinsic operators of Python." Unless, you are proposing getattr grow this functionality as well. IOW, should PyObject_GetAttr* perform this recursion? If so, should PyObject_HasAttr*, PyObject_DelAttr*, PyObject_SetAttr* do this as well? At the moment, it is possible to have foo's (as in above) that contain dots despite the inability to spell that in python's dereferencing syntax. However, I don't know that anybody does that. ---------- nosy: +scottdial __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 14 23:31:02 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 22:31:02 -0000 Subject: [issue1764638] add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP Message-ID: <1200349862.55.0.223497143248.issue1764638@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 15 00:05:02 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 23:05:02 -0000 Subject: [issue1698398] wrong % of params for format string in ZipFile.printdir() Message-ID: <1200351902.83.0.670165403462.issue1698398@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Fixed in revision 59959 ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 15 00:05:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 23:05:13 -0000 Subject: [issue1698915] ZipFile.printdir fix (2.5) Message-ID: <1200351913.29.0.295319447415.issue1698915@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Fixed in revision 59959 ---------- nosy: +rhettinger _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 15 00:05:32 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 23:05:32 -0000 Subject: [issue1698917] ZipFile.printdir fix (2.6) Message-ID: <1200351932.62.0.63705376837.issue1698917@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Fixed in revision 59959 ---------- nosy: +rhettinger resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 15 00:05:37 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 14 Jan 2008 23:05:37 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200351937.45.0.674353438374.issue1826@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I'm not /personally/ concerned with the breakage because practicality beats purity, and I don't want to use lambda because it's slower. I've never used operator.attrgetter() outside the specific use case of sorted() and list.sort() so I'd like to make it able to be used in all sorting-by-attribute-chasing use cases. Other options: have sorted() and list.sort() grow another keyword argument for the attribute-path; add another method called attrchaser() in some module that adds the requested functionality. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 00:08:05 2008 From: report at bugs.python.org (Alan McIntyre) Date: Mon, 14 Jan 2008 23:08:05 -0000 Subject: [issue1698917] ZipFile.printdir fix (2.6) Message-ID: <1200352085.55.0.775316567592.issue1698917@psf.upfronthosting.co.za> Alan McIntyre added the comment: I think you applied the wrong patch; the referenced revision doesn't include the tests from zipfile-printdir-2.diff. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 15 00:12:23 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 23:12:23 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200352343.69.0.290481254859.issue1826@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think Barry's proposal is fine. If we need to update the docs, then so be it. His proposal adds useful functionality while keeping readability and clarity. FWIW, the getattr() explanation in the docs already needs to be expanded to cover the multi-argument form of itemgetter. ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 00:24:39 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 23:24:39 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1200353078.98.0.0523145585117.issue1771@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Yes, it does feel great. The code is cleaner and faster. The API is simple and matches all the other key= functions in min/max/nsmallest/nlargest/groupby. After more thought, I would like to make one more change and require the arguments to be keywords such as sort(key=str.lower) but not sort(str.lower). The issue is that the cmp= interface has been around so long that it is ingrained into our thinking and in our code. Having to write-out the keyword makes the intent explicit and will avoid accidently passing in a cmp= function when a key= function was intended. In Py3.1, the restriction could be relaxed and l.sort(f) could be accepted for l.sort(key=f). For the 2-to-3 tool, I wrote a converter that automatically transitions code currently using a custom compare function: 2.6 code: s.sort(cmp=lambda p, q: cmp(p.lower(), q.lower())) 3.0 code: s.sort(key=CmpToKey(lambda p, q: cmp(p.lower(), q.lower()))) Ideally, the automatcic conversion would be accompanied by a suggestion to manually rewrite to something like: 3.0 code: s.sort(key=str.lower) --- converter code --- def CmpToKey(mycmp): 'Convert a cmp= function into a key= function' class K(object): def __init__(self, obj, *args): self.obj = obj def __cmp__(self, other): return mycmp(self.obj, other.obj) return K __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 00:27:52 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 23:27:52 -0000 Subject: [issue1045] Performance regression in 2.5 In-Reply-To: <1188313584.39.0.0655511033178.issue1045@psf.upfronthosting.co.za> Message-ID: <1200353272.39.0.229096918243.issue1045@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 00:33:43 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2008 23:33:43 -0000 Subject: [issue1746088] long.__str__ is quadratic time Message-ID: <1200353623.37.0.410785166515.issue1746088@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would be happy with a patch that does divide-and-conquer. That code would be much easier to get correct than the FFT algorithm and it would still give nice Big-O results. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 15 00:35:46 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Jan 2008 23:35:46 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1200353746.5.0.976471555499.issue1771@psf.upfronthosting.co.za> Guido van Rossum added the comment: > After more thought, I would like to make one more change and require the > arguments to be keywords such as sort(key=str.lower) but not > sort(str.lower). Works for me. (To be honest I thought key was already required to be a keyword. :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 00:51:07 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 14 Jan 2008 23:51:07 -0000 Subject: [issue1725737] Distutils default exclude doesn't match top level .svn Message-ID: <1200354667.73.0.588929976528.issue1725737@psf.upfronthosting.co.za> Changes by Ralf Schmitt: ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 15 00:59:41 2008 From: report at bugs.python.org (Scott Dial) Date: Mon, 14 Jan 2008 23:59:41 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200355181.94.0.788473284615.issue1826@psf.upfronthosting.co.za> Scott Dial added the comment: The attached patch provides for the functionality requested. I've updated the docstring of attrgetter related to this new feature and have updated test_operator accordingly. Added file: http://bugs.python.org/file9169/getattrchaser.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 01:03:57 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 15 Jan 2008 00:03:57 -0000 Subject: [issue1698917] ZipFile.printdir fix (2.6) Message-ID: <1200355437.34.0.747491048203.issue1698917@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It was the right solution (a simplified version of the original patch). Will also add more tests when I get a chance. BTW, thanks for reporting this bug. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 15 01:33:03 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 15 Jan 2008 00:33:03 -0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1200357183.69.0.890398175569.issue1820@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- assignee: -> rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:02:30 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 15 Jan 2008 01:02:30 -0000 Subject: [issue1828] Renaming platform path modules In-Reply-To: <1200358950.65.0.433797418679.issue1828@psf.upfronthosting.co.za> Message-ID: <1200358950.65.0.433797418679.issue1828@psf.upfronthosting.co.za> New submission from Benjamin Peterson: Currently, all the platform-specific path modules (ntpath, macpath, etc) have normal module names. Since they are implementation details, they should have a "_" prepended to their names. I doubt this would break much code: I've never written witnessed any code outside of the os module that uses the modules. ---------- components: Library (Lib) messages: 59942 nosy: gutworth severity: normal status: open title: Renaming platform path modules versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:02:50 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 15 Jan 2008 01:02:50 -0000 Subject: [issue1829] Renaming platform path modules In-Reply-To: <1200358970.58.0.364951248106.issue1829@psf.upfronthosting.co.za> Message-ID: <1200358970.58.0.364951248106.issue1829@psf.upfronthosting.co.za> New submission from Benjamin Peterson: Currently, all the platform-specific path modules (ntpath, macpath, etc) have normal module names. Since they are implementation details, they should have a "_" prepended to their names as is the custom for private objects. I doubt this would break much code: I've never written witnessed any code outside of the os module that uses the modules. ---------- components: Library (Lib) messages: 59943 nosy: gutworth severity: normal status: open title: Renaming platform path modules versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:03:51 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 15 Jan 2008 01:03:51 -0000 Subject: [issue1829] Renaming platform path modules In-Reply-To: <1200358970.58.0.364951248106.issue1829@psf.upfronthosting.co.za> Message-ID: <1200359031.91.0.80951423125.issue1829@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Sorry for the double. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:06:55 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 15 Jan 2008 01:06:55 -0000 Subject: [issue1829] Renaming platform path modules In-Reply-To: <1200358970.58.0.364951248106.issue1829@psf.upfronthosting.co.za> Message-ID: <1200359215.8.0.681894045823.issue1829@psf.upfronthosting.co.za> Christian Heimes added the comment: Duplicate of #1828 ---------- nosy: +tiran resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:12:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 15 Jan 2008 01:12:32 -0000 Subject: [issue1828] Renaming platform path modules In-Reply-To: <1200358950.65.0.433797418679.issue1828@psf.upfronthosting.co.za> Message-ID: <1200359552.39.0.431360689064.issue1828@psf.upfronthosting.co.za> Christian Heimes added the comment: Brett, it sounds like a good idea for the 3.0 stdlib reorg. ---------- nosy: +brett.cannon, tiran priority: -> low type: -> rfe versions: -Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:14:08 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Jan 2008 01:14:08 -0000 Subject: [issue1828] Renaming platform path modules In-Reply-To: <1200359552.39.0.431360689064.issue1828@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Jan 14, 2008 5:12 PM, Christian Heimes wrote: > > Christian Heimes added the comment: > > Brett, it sounds like a good idea for the 3.0 stdlib reorg. > Yep, it does. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:16:17 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Jan 2008 01:16:17 -0000 Subject: [issue1828] Renaming platform path modules In-Reply-To: <1200358950.65.0.433797418679.issue1828@psf.upfronthosting.co.za> Message-ID: <1200359777.97.0.234969292039.issue1828@psf.upfronthosting.co.za> Guido van Rossum added the comment: > Since they are implementation details, they > should have a "_" prepended to their names. No, they are not, and they should not. There are legitimate use cases for importing these directly. E.g. I could be on a Windows box but have a desire to manipulate posix paths. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:21:35 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 15 Jan 2008 01:21:35 -0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1200360095.5.0.583493046863.issue1820@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the patch. I removed the whitespace changes and added some tests to make sure structseq now works with the % formatting operator and isinstance(t,tuple). Am getting a sporadic segfault in test_zipimport when running "make test", so holding-off on applying: test_zipimport ~/py26/Lib/test/test_zipimport.py:91: ImportWarning: Not importing directory '/home/rhettinger/py26/Modules/zlib': missing __init__.py ["__dummy__"]) make: *** [test] Segmentation fault Added file: http://bugs.python.org/file9170/structseq.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:25:04 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 15 Jan 2008 01:25:04 -0000 Subject: [issue1828] Renaming platform path modules In-Reply-To: <1200358950.65.0.433797418679.issue1828@psf.upfronthosting.co.za> Message-ID: <1200360304.8.0.293277589094.issue1828@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Well, yes but I think that it's rare enough that in the name of keeping the stdlib clean, it's reasonable to say: import _posixpath and posixpath This also occurs when somone wants to modify __builtin__. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:43:22 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Jan 2008 01:43:22 -0000 Subject: [issue1786] pdb should set stdin+stdout around exec call In-Reply-To: <1200013506.35.0.644025895195.issue1786@psf.upfronthosting.co.za> Message-ID: <1200361402.94.0.106948831399.issue1786@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's an improved patch -- the recursive debugger invocation should pass the I/O settings on. ---------- assignee: -> gvanrossum keywords: +easy Added file: http://bugs.python.org/file9171/pdb.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:44:16 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Jan 2008 01:44:16 -0000 Subject: [issue1828] Renaming platform path modules In-Reply-To: <1200358950.65.0.433797418679.issue1828@psf.upfronthosting.co.za> Message-ID: <1200361456.18.0.131934610865.issue1828@psf.upfronthosting.co.za> Guido van Rossum added the comment: And guess what, in 3.0 __builtin__ is renamed to builtin. ---------- resolution: -> rejected __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:44:21 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Jan 2008 01:44:21 -0000 Subject: [issue1828] Renaming platform path modules In-Reply-To: <1200358950.65.0.433797418679.issue1828@psf.upfronthosting.co.za> Message-ID: <1200361461.44.0.536265385151.issue1828@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 02:46:01 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 15 Jan 2008 01:46:01 -0000 Subject: [issue1828] Renaming platform path modules In-Reply-To: <1200361456.18.0.131934610865.issue1828@psf.upfronthosting.co.za> Message-ID: <1afaf6160801141745m1429f5cas8620e4ae7af730f8@mail.gmail.com> Benjamin Peterson added the comment: On Jan 14, 2008 7:44 PM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > And guess what, in 3.0 __builtin__ is renamed to builtin. point taken > > > ---------- > resolution: -> rejected > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9172/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080115/7f7f9bf0/attachment.txt From report at bugs.python.org Tue Jan 15 02:56:47 2008 From: report at bugs.python.org (Santiago Gala) Date: Tue, 15 Jan 2008 01:56:47 -0000 Subject: [issue1542677] IDLE shell doesn't accept non ascii char input Message-ID: <1200362207.85.0.640372925318.issue1542677@psf.upfronthosting.co.za> Santiago Gala added the comment: works in python 3ka2 (svn as of today): >>> print("?") ? >>> print(b"?") SyntaxError: bytes can only contain ASCII literal characters. (, line 1) as it should, so the problem appears in 2.* only. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 15 03:01:06 2008 From: report at bugs.python.org (Leif Walsh) Date: Tue, 15 Jan 2008 02:01:06 -0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1200362466.68.0.468665965339.issue1820@psf.upfronthosting.co.za> Leif Walsh added the comment: I just svn upped (it updated zipimport) and applied your patch, and './python Lib/test/regrtest.py test_zipimport.py' says it's okay, so I would go ahead and commit it. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 03:05:39 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 15 Jan 2008 02:05:39 -0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1200362739.69.0.93442574111.issue1820@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Run, "make test" a few times to make sure it doesn't bomb. The problem may be due to needing a deferred_type instead of assigning &PyTupleObject directly. Will look it more later. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 04:03:58 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 15 Jan 2008 03:03:58 -0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1200366238.82.0.327775573561.issue1820@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It worked fine on a fresh check-out. Committed in revision 59967. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 05:08:33 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Jan 2008 04:08:33 -0000 Subject: [issue1828] Renaming platform path modules In-Reply-To: <1200358950.65.0.433797418679.issue1828@psf.upfronthosting.co.za> Message-ID: <1200370113.81.0.512035240316.issue1828@psf.upfronthosting.co.za> Changes by Guido van Rossum: Removed file: http://bugs.python.org/file9172/unnamed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 08:39:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 15 Jan 2008 07:39:39 -0000 Subject: [issue1326] "internal" zipimport.zipimporter feature untested In-Reply-To: <1193317680.83.0.000309828654595.issue1326@psf.upfronthosting.co.za> Message-ID: <1200382779.88.0.716814166687.issue1326@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 08:48:00 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 15 Jan 2008 07:48:00 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200383280.0.0.401227199549.issue1682@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Thanks! I've added some minimal documentation and construction from other Rationals. The other formats for string parsing center around where whitespace is allowed, and whether you can put parens around the whole fraction. Parens would, of course, go away if str() no longer produces them. So they're not significantly different. I guess my objection to construction from strings is mostly that I'm ambivalent, and especially for a core library, that means no. If there's support from another core developer or two, I'd have no objections. Inexact is saying that one thing could be ==3 and the other ==0, so I think it's correct. Negative zeros are a problem. :) I think the default implementations are still fine, but you're right that classes like Decimal will need to think about it, and the numbers module should mention the issue. It's not related to the Rational implementation though, so in another patch. I've submitted this round as r59974. Onto the next patch! :) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 08:55:10 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 15 Jan 2008 07:55:10 -0000 Subject: [issue1725737] Distutils default exclude doesn't match top level .svn Message-ID: <1200383710.01.0.715378687858.issue1725737@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I can easily reproduce it using python 2.5. I'll test with trunk. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 15 10:10:54 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Jan 2008 09:10:54 -0000 Subject: [issue1326] "internal" zipimport.zipimporter feature untested In-Reply-To: <1193317680.83.0.000309828654595.issue1326@psf.upfronthosting.co.za> Message-ID: <1200388254.91.0.983968334664.issue1326@psf.upfronthosting.co.za> Brett Cannon added the comment: And if you want more ideas for tests, I implemented my own tests for my pure Python implementation of zipimport. They can be found in the sandbox at import_in_py/zipimport_/tests.py . ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 12:50:29 2008 From: report at bugs.python.org (Peter Harris) Date: Tue, 15 Jan 2008 11:50:29 -0000 Subject: [issue1830] pygettext.py syntax error In-Reply-To: <1200397829.12.0.24320735319.issue1830@psf.upfronthosting.co.za> Message-ID: <1200397829.12.0.24320735319.issue1830@psf.upfronthosting.co.za> New submission from Peter Harris: Tools/i18n/pygettext.py contains a syntax error. On line 665, there is an old u'' string for testing unicode on pre-3.0 python. It should be OK to remove it. ---------- components: Demos and Tools messages: 59961 nosy: scav severity: normal status: open title: pygettext.py syntax error type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 13:08:16 2008 From: report at bugs.python.org (Peter Harris) Date: Tue, 15 Jan 2008 12:08:16 -0000 Subject: [issue1830] pygettext.py py3k errors In-Reply-To: <1200397829.12.0.24320735319.issue1830@psf.upfronthosting.co.za> Message-ID: <1200398896.2.0.334562322532.issue1830@psf.upfronthosting.co.za> Peter Harris added the comment: Also, a couple of instances of assuming dict.keys() is a list, and trying to use .sort() on them. Patch attached for both issues. ---------- title: pygettext.py syntax error -> pygettext.py py3k errors Added file: http://bugs.python.org/file9173/pygettext.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 13:42:08 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 15 Jan 2008 12:42:08 -0000 Subject: [issue1793] ctypes.util.find_msvcrt() function In-Reply-To: <1200063578.88.0.774833430715.issue1793@psf.upfronthosting.co.za> Message-ID: <1200400928.25.0.569411323032.issue1793@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I found the code I wrote some time ago for the same purpose: (in pypy, which uses ctypes a lot) import sys if sys.platform == 'win32': # Parses sys.version and deduces the version of the compiler import distutils.msvccompiler version = distutils.msvccompiler.get_build_version() if version is None: # This logic works with official builds of Python. if sys.version_info < (2, 4): clibname = 'msvcrt' else: clibname = 'msvcr71' else: if version <= 6: clibname = 'msvcrt' else: clibname = 'msvcr%d' % (version * 10) # If python was built with in debug mode import imp if imp.get_suffixes()[0][0] == '_d.pyd': clibname += 'd' standard_c_lib = ctypes.cdll.LoadLibrary(clibname+'.dll') This code works on all pythons I have on my machine: official builds, custom builds (relase/debug) with several MS compilers... I did not test it with other compiled vendors (mingw32...). But to me this seems more robust than a text search in the executable. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 14:47:10 2008 From: report at bugs.python.org (Armin Rigo) Date: Tue, 15 Jan 2008 13:47:10 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> New submission from Armin Rigo: The constructor of ctypes structures should probably not silently accept the bogus arguments shown in the attached example. ---------- components: Extension Modules files: bogus_args.py messages: 59964 nosy: arigo, cfbolz, fijal severity: normal status: open title: ctypes.Structure constructor arguments versions: Python 2.6 Added file: http://bugs.python.org/file9174/bogus_args.py __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 14:48:03 2008 From: report at bugs.python.org (Armin Rigo) Date: Tue, 15 Jan 2008 13:48:03 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200404883.14.0.39031647058.issue1831@psf.upfronthosting.co.za> Changes by Armin Rigo: ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 14:54:18 2008 From: report at bugs.python.org (Scott Dial) Date: Tue, 15 Jan 2008 13:54:18 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200405258.37.0.123834748178.issue1826@psf.upfronthosting.co.za> Scott Dial added the comment: Mea culpa, the original patch I attached here has an obvious duplication of code in test_operator.py. I've attached an updated patch to make life easier on the commiter. Added file: http://bugs.python.org/file9175/getattrchaser.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 15:05:51 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 15 Jan 2008 14:05:51 -0000 Subject: [issue1296] optparse's OptionGroup not described In-Reply-To: <1192722391.31.0.57718526952.issue1296@psf.upfronthosting.co.za> Message-ID: <1200405951.43.0.74660196459.issue1296@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 15:53:59 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 15 Jan 2008 14:53:59 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200408839.41.0.540695712422.issue1831@psf.upfronthosting.co.za> Thomas Heller added the comment: Do you have any idea how this could be implemented? ---------- nosy: +theller __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 15:58:29 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 15 Jan 2008 14:58:29 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200409109.52.0.722513927459.issue1831@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: What about PyArg_ParseTupleAndKeywords()? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 16:03:46 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 15 Jan 2008 15:03:46 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200409109.52.0.722513927459.issue1831@psf.upfronthosting.co.za> Message-ID: <478CCB4A.8090606@ctypes.org> Thomas Heller added the comment: This would require to build the 'char *format' string at runtime, the 'char *keywords[]' array too, and pass a variable number of arguments into the call. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 16:12:34 2008 From: report at bugs.python.org (Armin Rigo) Date: Tue, 15 Jan 2008 15:12:34 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200409954.85.0.177101156964.issue1831@psf.upfronthosting.co.za> Armin Rigo added the comment: The pure Python implementation we just wrote in PyPy is: for name, arg in zip(names, args): if name in kwds: raise TypeError("duplicate value for argument %r" % ( name,)) self.__setattr__(name, arg) for name, arg in kwds.items(): self.__setattr__(name, arg) It's the same logic as in _ctypes.c:Struct_init(), where you can add the C equivalent of "if name in kwds" after getting the name. ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 16:15:36 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 15 Jan 2008 15:15:36 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py In-Reply-To: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za> Message-ID: <1200410136.22.0.0934847755489.issue1294@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Ok. BTW, can I get tracker permissions? I will try to check old bugs to update their information and if required, close them. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 16:21:48 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 15 Jan 2008 15:21:48 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200410508.1.0.608273482255.issue1831@psf.upfronthosting.co.za> Thomas Heller added the comment: Yes, I came up with a similar solution in the meantime; see the attached patch. Added file: http://bugs.python.org/file9176/ctypes-struct.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 16:22:28 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 15 Jan 2008 15:22:28 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200410548.32.0.645301375859.issue1831@psf.upfronthosting.co.za> Changes by Thomas Heller: Removed file: http://bugs.python.org/file9176/ctypes-struct.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 16:23:25 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 15 Jan 2008 15:23:25 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200410605.23.0.995624448977.issue1831@psf.upfronthosting.co.za> Thomas Heller added the comment: Oops, uploaded the wrong file. Added file: http://bugs.python.org/file9177/ctypes-struct.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 17:55:02 2008 From: report at bugs.python.org (Armin Rigo) Date: Tue, 15 Jan 2008 16:55:02 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200416102.4.0.856920036803.issue1831@psf.upfronthosting.co.za> Armin Rigo added the comment: The patch is missing Py_DECREF(name). Also, I'd raise TypeError instead of ValueError, just like function calls do in a similar situation. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 18:21:11 2008 From: report at bugs.python.org (Jacques Lemire) Date: Tue, 15 Jan 2008 17:21:11 -0000 Subject: [issue1835] Update version number in __init__.py In-Reply-To: <1200417671.24.0.488273286588.issue1835@psf.upfronthosting.co.za> Message-ID: <1200417671.24.0.488273286588.issue1835@psf.upfronthosting.co.za> New submission from Jacques Lemire: In the distutils directory the file __init__.py is not updated to 3.0. ---------- components: Distutils messages: 59974 nosy: jlp severity: minor status: open title: Update version number in __init__.py type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 18:41:49 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Jan 2008 17:41:49 -0000 Subject: [issue1830] pygettext.py py3k errors In-Reply-To: <1200397829.12.0.24320735319.issue1830@psf.upfronthosting.co.za> Message-ID: <1200418909.0.0.476570593727.issue1830@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! Committed revision 59979. ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 18:44:38 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Jan 2008 17:44:38 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py In-Reply-To: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za> Message-ID: <1200419078.13.0.626444689012.issue1294@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've added developer status to your username. Let me know if it doesn't work. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 18:46:54 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Jan 2008 17:46:54 -0000 Subject: [issue1835] Update version number in __init__.py In-Reply-To: <1200417671.24.0.488273286588.issue1835@psf.upfronthosting.co.za> Message-ID: <1200419214.19.0.742656863369.issue1835@psf.upfronthosting.co.za> Guido van Rossum added the comment: The comment indicates it's not automatic that the version number follows the Python release number. Assigning to MAL who wants to coordinated this according to that same comment. ---------- assignee: -> lemburg keywords: +easy nosy: +gvanrossum, lemburg priority: -> low versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 18:51:11 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 15 Jan 2008 17:51:11 -0000 Subject: [issue1835] Update version number in __init__.py In-Reply-To: <1200417671.24.0.488273286588.issue1835@psf.upfronthosting.co.za> Message-ID: <1200419471.25.0.00463306604046.issue1835@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The version number should only be bumped for major enhancements to distutils or backwards incompatible changes. Have there been any such changes ? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 19:00:26 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Jan 2008 18:00:26 -0000 Subject: [issue1786] pdb should set stdin+stdout around exec call In-Reply-To: <1200013506.35.0.644025895195.issue1786@psf.upfronthosting.co.za> Message-ID: <1200420026.04.0.0399566810535.issue1786@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 59984 (2.6). Decided not to backport this to 2.5. ---------- resolution: -> fixed status: open -> closed versions: -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 19:23:54 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 15 Jan 2008 18:23:54 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py In-Reply-To: <1200419078.13.0.626444689012.issue1294@psf.upfronthosting.co.za> Message-ID: <2c51ecee0801151023x69663f16pe0bae5eb600294af@mail.gmail.com> Raghuram Devarakonda added the comment: > I've added developer status to your username. Let me know if it doesn't > work. It does. Thanks. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 19:30:47 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 15 Jan 2008 18:30:47 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200421847.13.0.803555543269.issue1831@psf.upfronthosting.co.za> Thomas Heller added the comment: Ok, added the missing Py_DECREF, changed to TypeError, and added a test. Added file: http://bugs.python.org/file9178/ctypes-struct.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 19:31:53 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 15 Jan 2008 18:31:53 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200421913.99.0.352943911055.issue1831@psf.upfronthosting.co.za> Changes by Thomas Heller: Removed file: http://bugs.python.org/file9177/ctypes-struct.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 19:46:59 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 15 Jan 2008 18:46:59 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200422819.96.0.425002173726.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Inexact is saying that one thing could be ==3 and the other ==0, so I > think it's correct. You're right, of course :) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 22:01:30 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 15 Jan 2008 21:01:30 -0000 Subject: [issue1781] ConfigParser: add_section('DEFAULT') causes duplicate sections. In-Reply-To: <1199932970.3.0.196882211496.issue1781@psf.upfronthosting.co.za> Message-ID: <1200430890.93.0.0296757100638.issue1781@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: ---------- keywords: +easy, patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 15 22:30:09 2008 From: report at bugs.python.org (Kathryn M Kowalski) Date: Tue, 15 Jan 2008 21:30:09 -0000 Subject: [issue1836] 'weekly' rotating logging file rotation incorrect In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> Message-ID: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> New submission from Kathryn M Kowalski: Log file did not 'rotate' on day requested. Fixed code in Lib/logging/handlers.py class TimedRotatingFileHandler Compare excerpt of my fix below to the original # Case 2) The day to rollover is further in the interval (i.e., today is # day 2 (Wednesday) and rollover is on day 6 (Sunday). Days to # next rollover is simply 6 - 2, or 4. # Case 3) The day to rollover is behind us in the interval (i.e., today # is day 5 (Saturday) and rollover is on day 3 (Thursday). # Days to rollover is 6 - 5 + 3 + 1, or 5. In this case, it's the # number of days left in the current week (1) plus the number # of days in the next week until the rollover day (4). if when.startswith('W'): day = t[6] # 0 is Monday if self.dayOfWeek > day: daysToWait = (self.dayOfWeek - day) self.rolloverAt = self.rolloverAt + (daysToWait * (60 * 60 * 24)) if self.dayOfWeek < day: daysToWait = (6 - day) + self.dayOfWeek + 1 ---------- components: Library (Lib) messages: 59983 nosy: kmk severity: normal status: open title: 'weekly' rotating logging file rotation incorrect type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 00:46:10 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 15 Jan 2008 23:46:10 -0000 Subject: [issue1837] Add Queue.LifoQueue and Queue.PriorityQueue In-Reply-To: <1200440770.17.0.987165250317.issue1837@psf.upfronthosting.co.za> Message-ID: <1200440770.17.0.987165250317.issue1837@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Rather than just documenting that this can be done, it is better to simply provide working implementations that show exactly how to subclass the Queue module. This also lets users easily select or switch between the most appropriate structure. Since API is the same, the learning curve is near zero. If accepted, will add a full set of tests. ---------- assignee: gvanrossum components: Library (Lib) files: more_queues.diff keywords: patch messages: 59984 nosy: gvanrossum, rhettinger severity: normal status: open title: Add Queue.LifoQueue and Queue.PriorityQueue type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9179/more_queues.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 00:55:47 2008 From: report at bugs.python.org (Alexandre Fiori) Date: Tue, 15 Jan 2008 23:55:47 -0000 Subject: [issue1817] module-cgi: handling GET and POST together In-Reply-To: <1200189536.91.0.809582793643.issue1817@psf.upfronthosting.co.za> Message-ID: <1200441347.26.0.402069820562.issue1817@psf.upfronthosting.co.za> Alexandre Fiori added the comment: Now I added support for parsing query string within multipart/*. The only issue now is that it mixes FieldStorage with MiniFieldStorage. However, I don't think it's a problem. Added file: http://bugs.python.org/file9180/cgy.py.patch-1 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 01:05:03 2008 From: report at bugs.python.org (Fredrik Lundh) Date: Wed, 16 Jan 2008 00:05:03 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za> Message-ID: <1200441903.31.0.586391820932.issue1327@psf.upfronthosting.co.za> Fredrik Lundh added the comment: Can you switch on verbose mode in xmlrpclib, so you can see *where* the transfer hangs? Arguing that a hanging Python program must be caused by a bug in the code that *executes* the Python program isn't that meaningful, really. After all, that code is used to run *all* Python programs, so I think we'd noticed if it had a tendency to hang unexpectedly... __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 01:12:47 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Jan 2008 00:12:47 -0000 Subject: [issue1837] Add Queue.LifoQueue and Queue.PriorityQueue In-Reply-To: <1200440770.17.0.987165250317.issue1837@psf.upfronthosting.co.za> Message-ID: <1200442367.85.0.818182131118.issue1837@psf.upfronthosting.co.za> Changes by Raymond Hettinger: Removed file: http://bugs.python.org/file9179/more_queues.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 01:13:45 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Jan 2008 00:13:45 -0000 Subject: [issue1837] Add Queue.LifoQueue and Queue.PriorityQueue In-Reply-To: <1200440770.17.0.987165250317.issue1837@psf.upfronthosting.co.za> Message-ID: <1200442425.92.0.78491801078.issue1837@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Updated patch to include tests. Added file: http://bugs.python.org/file9181/more_queues.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 01:22:48 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 16 Jan 2008 00:22:48 -0000 Subject: [issue1811] True division of integers could be more accurate In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za> Message-ID: <1200442968.61.0.287071852398.issue1811@psf.upfronthosting.co.za> Mark Dickinson added the comment: A related problem is that float(n) isn't always correctly rounded for an integer n. A contrived example: >>> n = 2**68 + 2**16 - 1 >>> float(n) 2.9514790517935283e+20 Here the difference between float(n) and the true value of n is around 0.99998 ulps; a correctly rounded float() would have error at most 0.5 ulps. I don't regard this as terribly serious: from looking at the code, I *think* it's always true that the error is strictly less than 1 ulp, which is just enough to guarantee that float(n) == n whenever n is exactly representable as a float. In contrast, the division of two integers can produce results that are up to 3.5 ulps out from the true value. This is, in my opinion, a worryingly large error for a simple calculation. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 03:22:54 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 16 Jan 2008 02:22:54 -0000 Subject: [issue1339] smtplib starttls() should ehlo() if it needs to In-Reply-To: <1193441174.56.0.280335873353.issue1339@psf.upfronthosting.co.za> Message-ID: <1200450174.72.0.182918788581.issue1339@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 03:28:45 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 16 Jan 2008 02:28:45 -0000 Subject: [issue1202] zlib.crc32() and adler32() return value In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> Message-ID: <1200450525.76.0.771565575043.issue1202@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 03:32:48 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 16 Jan 2008 02:32:48 -0000 Subject: [issue1189216] zipfile module and 2G boundary Message-ID: <1200450768.74.0.0759103087105.issue1189216@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 16 03:36:00 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 16 Jan 2008 02:36:00 -0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za> Message-ID: <1200450960.13.0.0500003213266.issue1622@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 03:36:40 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 16 Jan 2008 02:36:40 -0000 Subject: [issue1746] ZIP files with archive comments longer than 4k not recognized as valid by zipfile module In-Reply-To: <1199659217.24.0.18704559865.issue1746@psf.upfronthosting.co.za> Message-ID: <1200451000.14.0.579300504557.issue1746@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 03:38:02 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 16 Jan 2008 02:38:02 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files In-Reply-To: <1196429217.61.0.167287216759.issue1526@psf.upfronthosting.co.za> Message-ID: <1200451082.44.0.222089321157.issue1526@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 03:47:25 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 16 Jan 2008 02:47:25 -0000 Subject: [issue1731] Random errors on interpreter shutdown In-Reply-To: <1199402921.07.0.182156121035.issue1731@psf.upfronthosting.co.za> Message-ID: <1200451645.55.0.627485875545.issue1731@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 04:13:37 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 16 Jan 2008 03:13:37 -0000 Subject: [issue1799] Per user site-packages and setup.py install --user patch In-Reply-To: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za> Message-ID: <1200453217.99.0.72925656783.issue1799@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 06:30:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 16 Jan 2008 05:30:34 -0000 Subject: [issue1799] Per user site-packages and setup.py install --user patch In-Reply-To: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za> Message-ID: <1200461434.47.0.2430203859.issue1799@psf.upfronthosting.co.za> Christian Heimes added the comment: Future patches will be applied to the branch directly: http://svn.python.org/view/sandbox/trunk/pep370 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 08:10:54 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 16 Jan 2008 07:10:54 -0000 Subject: [issue1747858] chown broken on 64bit Message-ID: <1200467454.71.0.99430249334.issue1747858@psf.upfronthosting.co.za> Sean Reifschneider added the comment: It seems like the problem here is that chown is defined to take -1 for the arguments, where the underlying platform may define chown taking unsigned uid/gid. I think in the short term we will need to apply a patch like one of the ones included here, but in the long term maybe something like "chown(path, uid = None, gid = None)"? With "chown(path, gid = 69)". Does it make sense to use None instead of -1 in the long term? ---------- keywords: +64bit, patch nosy: +jafo type: -> behavior _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 16 08:30:32 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 16 Jan 2008 07:30:32 -0000 Subject: [issue1747858] chown broken on 64bit Message-ID: <1200468632.71.0.24123352928.issue1747858@psf.upfronthosting.co.za> Changes by Sean Reifschneider: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 16 08:40:55 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 16 Jan 2008 07:40:55 -0000 Subject: [issue1747858] chown broken on 64bit Message-ID: <1200469255.14.0.995476762746.issue1747858@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I believe that patch would break on a system where uid_t is a 64-bit value, yet unsigned int is 32 bits. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 16 09:37:16 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 16 Jan 2008 08:37:16 -0000 Subject: [issue1747858] chown broken on 64bit Message-ID: <1200472636.8.0.696157658658.issue1747858@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I've reviewed the chown system call under Linux and I think the included patch will resolve the problem. With that patch on a Fedora 8 64-bit system I'm getting: >>> os.stat('/tmp/foo') posix.stat_result(st_mode=33188, st_ino=5111823, st_dev=64769L, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=1200469633, st_mtime=1200469633, st_ctime=1200469657) >>> os.chown('/tmp/foo', 4294967294, -1) >>> os.stat('/tmp/foo') posix.stat_result(st_mode=33188, st_ino=5111823, st_dev=64769L, st_nlink=1, st_uid=4294967294, st_gid=0, st_size=0, st_atime=1200469633, st_mtime=1200469633, st_ctime=1200469683) >>> However, it's unclear to me whether there are any platforms that might define uid_t as signed, and if so whether this code would do the right thing on those platforms. I don't know of a way to do it in C off hand, but perhaps we could check the exact type of the uid_t and gid_t types and see if they're signed or unsigned and use that combined with sizeof(uid_t) to use exactly the correct ParseTuple format string. I've attached a patch that dynamically tries to figure out the size to use. Does this seem overly-heavy? If it seems appropriate, the same would need to be applied to the other chown functions. Added file: http://bugs.python.org/file9182/posixmodule-chown-dynamic.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 16 10:38:45 2008 From: report at bugs.python.org (Maciek Fijalkowski) Date: Wed, 16 Jan 2008 09:38:45 -0000 Subject: [issue1838] Ctypes C-level infinite recursion In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za> Message-ID: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za> New submission from Maciek Fijalkowski: Code in example abuses the fact that _as_parameter_ is passed recursively. Not sure if this is for fixing or not. ---------- components: Extension Modules files: crash.py messages: 59993 nosy: arigo, fijal severity: normal status: open title: Ctypes C-level infinite recursion type: crash versions: Python 2.6 Added file: http://bugs.python.org/file9183/crash.py __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 10:55:48 2008 From: report at bugs.python.org (mephinet) Date: Wed, 16 Jan 2008 09:55:48 -0000 Subject: [issue1545837] array.array borks on deepcopy Message-ID: <1200477348.02.0.735706546508.issue1545837@psf.upfronthosting.co.za> Changes by mephinet: ---------- nosy: +mephinet _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 16 11:48:46 2008 From: report at bugs.python.org (Peter Harris) Date: Wed, 16 Jan 2008 10:48:46 -0000 Subject: [issue1840] Tools/i18n/msgfmt.py fixes for Python 3.0 In-Reply-To: <1200480526.71.0.697758724205.issue1840@psf.upfronthosting.co.za> Message-ID: <1200480526.71.0.697758724205.issue1840@psf.upfronthosting.co.za> New submission from Peter Harris: Python 3.0: Use bytes instead of str to construct the binary file, don't try to .sort a dict's keys(). This patch is a tentative fix - in one place I've had to provide an encoding from str to bytes and I've guessed UTF-8, which may be OK for most .po files, but possibly not all. ---------- components: Demos and Tools files: msgfmt.diff messages: 59994 nosy: scav severity: normal status: open title: Tools/i18n/msgfmt.py fixes for Python 3.0 type: crash versions: Python 3.0 Added file: http://bugs.python.org/file9185/msgfmt.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 13:56:55 2008 From: report at bugs.python.org (Andrew Ferguson) Date: Wed, 16 Jan 2008 12:56:55 -0000 Subject: [issue1747858] chown broken on 64bit Message-ID: <1200488215.71.0.651619236187.issue1747858@psf.upfronthosting.co.za> Andrew Ferguson added the comment: The idea of dynamic typing it seems quite heavy to me, but I'm not a Python hacker, so I don't know what's the norm. Notice that os.stat() does "PyInt_FromLong((long)st->st_uid)" on the stat structure's st_uid field. On my platform (OS X 10.4), st_uid is defined as a uid_t type. So maybe os.stat() has the answer: ignore the signed vs. unsigned int problem and just use a long. The actual chown() call in posix_chown() casts the uid variable to a (uid_t) anyway. GCC doesn't seem to complain when we cast a long to an unsigned int, even. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 16 15:47:18 2008 From: report at bugs.python.org (raA) Date: Wed, 16 Jan 2008 14:47:18 -0000 Subject: [issue1775] filehandle.write() does not return None (Python 3.0a2) In-Reply-To: <1199883149.22.0.23332594805.issue1775@psf.upfronthosting.co.za> Message-ID: <1200494838.67.0.027314630874.issue1775@psf.upfronthosting.co.za> Changes by raA: __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 16:03:53 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 16 Jan 2008 15:03:53 -0000 Subject: [issue1838] Ctypes C-level infinite recursion In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za> Message-ID: <1200495833.88.0.743238536913.issue1838@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've got a hunch that any crashes you cause with ctypes are your own fault. :-) ---------- nosy: +gvanrossum priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 16:06:09 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 16 Jan 2008 15:06:09 -0000 Subject: [issue1840] Tools/i18n/msgfmt.py fixes for Python 3.0 In-Reply-To: <1200480526.71.0.697758724205.issue1840@psf.upfronthosting.co.za> Message-ID: <1200495969.68.0.979091420407.issue1840@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> loewis keywords: +patch nosy: +loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 16:41:02 2008 From: report at bugs.python.org (Armin Rigo) Date: Wed, 16 Jan 2008 15:41:02 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200498062.41.0.491839800726.issue1831@psf.upfronthosting.co.za> Armin Rigo added the comment: For the "too many arguments" case... Clearly (IMHO) it should also be a TypeError. I have no clue about backward compatibility issues though. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 17:45:42 2008 From: report at bugs.python.org (Jim Wilson) Date: Wed, 16 Jan 2008 16:45:42 -0000 Subject: [issue1854] Broken link in msilib docs In-Reply-To: <1200501942.7.0.0578865641851.issue1854@psf.upfronthosting.co.za> Message-ID: <1200501942.7.0.0578865641851.issue1854@psf.upfronthosting.co.za> New submission from Jim Wilson: at http://docs.python.org/lib/database-objects.html, under "See Also:", the link, MSIOpenView leads nowhere. From earlier reading, I suspect it should be "MSIDatabaseOpenView" (or perhaps "MSIDatabaseOpenViewPaddedOutEvenMoreToMakeYourEyesGlazeOver"). ---------- components: Documentation messages: 59998 nosy: Jimbo severity: minor status: open title: Broken link in msilib docs type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 17:58:33 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 16 Jan 2008 16:58:33 -0000 Subject: [issue1854] Broken link in msilib docs In-Reply-To: <1200501942.7.0.0578865641851.issue1854@psf.upfronthosting.co.za> Message-ID: <1200502713.86.0.72630256961.issue1854@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r59999 and r60000. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 18:10:07 2008 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 16 Jan 2008 17:10:07 -0000 Subject: [issue1836] 'weekly' rotating logging file rotation incorrect In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> Message-ID: <1200503407.76.0.452226709564.issue1836@psf.upfronthosting.co.za> Vinay Sajip added the comment: Please can you post the data which caused the failure? Is 'the original' the current trunk revision, or a Python release version? There was a patch to this code not long ago, so I'd like to know which code you had originally. Thanks. ---------- assignee: -> vsajip nosy: +vsajip __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 20:39:05 2008 From: report at bugs.python.org (Thomas Heller) Date: Wed, 16 Jan 2008 19:39:05 -0000 Subject: [issue1831] ctypes.Structure constructor arguments In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za> Message-ID: <1200512345.55.0.250686817279.issue1831@psf.upfronthosting.co.za> Thomas Heller added the comment: Committed as rev. 60003 in trunk. I'll also change the "too many arguments..." exception to a TypeError. Thanks. ---------- assignee: -> theller resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 21:06:23 2008 From: report at bugs.python.org (Thomas Heller) Date: Wed, 16 Jan 2008 20:06:23 -0000 Subject: [issue1796] ctypes should allow a tuple when an Array is expected In-Reply-To: <1200079028.65.0.512467714236.issue1796@psf.upfronthosting.co.za> Message-ID: <1200513983.77.0.891299585649.issue1796@psf.upfronthosting.co.za> Thomas Heller added the comment: Lenard Lindstrom convinced me that tuples should not be allowed when an array is expected. ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 21:09:09 2008 From: report at bugs.python.org (Thomas Heller) Date: Wed, 16 Jan 2008 20:09:09 -0000 Subject: [issue1292] libffi needs an update to support mips64, arm and armeabi on linux In-Reply-To: <1192699386.49.0.555660775493.issue1292@psf.upfronthosting.co.za> Message-ID: <1200514149.95.0.453857875932.issue1292@psf.upfronthosting.co.za> Thomas Heller added the comment: Matthias, can this issue be set to 'fixed' and 'closed' now? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 21:13:21 2008 From: report at bugs.python.org (Jim Wilson) Date: Wed, 16 Jan 2008 20:13:21 -0000 Subject: [issue1855] Codepage unset in msilib.init_database() In-Reply-To: <1200514401.27.0.0393918828447.issue1855@psf.upfronthosting.co.za> Message-ID: <1200514401.27.0.0393918828447.issue1855@psf.upfronthosting.co.za> New submission from Jim Wilson: At http://msdn2.microsoft.com/en-us/library/aa367864(VS.85,printer).aspx, Satanic Verses sayeth: "The Codepage Summary property must be set before any string properties are set in the summary information.", but so far as I can tell, PID_CODEPAGE is never used in msilib.__init__.py, etal. Confirming evidence: msilib's GetProperty(msilib.PID_CODEPAGE) raises "Not Implemented" on Python2.5.1's own .msi file. ---------- components: Distutils messages: 60006 nosy: Jimbo severity: normal status: open title: Codepage unset in msilib.init_database() versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 21:18:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 16 Jan 2008 20:18:15 -0000 Subject: [issue1855] Codepage unset in msilib.init_database() In-Reply-To: <1200514401.27.0.0393918828447.issue1855@psf.upfronthosting.co.za> Message-ID: <1200514695.59.0.883815118955.issue1855@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> loewis components: +Windows -Distutils nosy: +loewis priority: -> normal type: -> resource usage __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 21:50:59 2008 From: report at bugs.python.org (Thomas Heller) Date: Wed, 16 Jan 2008 20:50:59 -0000 Subject: [issue1793] ctypes.util.find_msvcrt() function In-Reply-To: <1200400928.25.0.569411323032.issue1793@psf.upfronthosting.co.za> Message-ID: <478E6E2A.4080705@ctypes.org> Thomas Heller added the comment: Amaury Forgeot d'Arc schrieb: > This code works on all pythons I have on my machine: official builds, > custom builds (relase/debug) with several MS compilers... > I did not test it with other compiled vendors (mingw32...). What I do not like about your code is that it imports distutils. On the other hand, the code in distutils.msvccompiler.get_build_version is so small and simple that it could easily be duplicated in ctypes.util; it could even be simplified more because ctypes doesn't work in Python < 2.3. What do you think? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 16 21:54:24 2008 From: report at bugs.python.org (Thomas Heller) Date: Wed, 16 Jan 2008 20:54:24 -0000 Subject: [issue1252550] modulefinder misses modules Message-ID: <1200516864.3.0.209209221876.issue1252550@psf.upfronthosting.co.za> Changes by Thomas Heller: ---------- resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 16 22:23:40 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 16 Jan 2008 21:23:40 -0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1200518620.28.0.740678001283.issue1731717@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: +gregory.p.smith _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 00:42:47 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Jan 2008 23:42:47 -0000 Subject: [issue1837] Add Queue.LifoQueue and Queue.PriorityQueue In-Reply-To: <1200440770.17.0.987165250317.issue1837@psf.upfronthosting.co.za> Message-ID: <1200526967.11.0.0811057517943.issue1837@psf.upfronthosting.co.za> Raymond Hettinger added the comment: See rev 60020. ---------- assignee: gvanrossum -> rhettinger status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 00:43:54 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 16 Jan 2008 23:43:54 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za> Message-ID: <1200527034.98.0.05197788795.issue1336@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 00:50:20 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 16 Jan 2008 23:50:20 -0000 Subject: [issue1568] PATCH: Armin's attribute lookup caching for 3.0 In-Reply-To: <1197034097.09.0.871896219058.issue1568@psf.upfronthosting.co.za> Message-ID: <1200527420.82.0.00937239809078.issue1568@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I tried patch python30-attrcache-1.diff (after reverting the changes made to the 2.6 branch). But test_descr fails. The cache update does not handle the case when an attribute is unmasked, as shown in the following code: class A: pass class B(A): pass b=B() A.x = 1 assert b.x == A.x B.x = 2 assert b.x == B.x del B.x b.x # <== AttributeError: 'B' object has no attribute 'x' (b.x should be A.x, of course) In debug build, a C assert() stops the program assert(ep->value == _PyType_LookupInternal(type, name)); which suggest that the cache is out of sync. Then I enabled #define ATTRCACHE_SETATTR_INVALIDATES to try the other possibility suggested by Neil. This version seems to work correctly. I'm currently running the test suite... Question: why is this patch different from the 2.6 version? Does it take advantage of some 3.0 feature? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 01:22:51 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 00:22:51 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za> Message-ID: <1200529371.88.0.161827319601.issue1336@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The uploaded file appears to be derives from Python 2.4.1 (tags/r241). i've uploaded an actual diff between the two. regardless, Thomas's point about disabling it -before- the fork() is true. Added file: http://bugs.python.org/file9186/diff-against-subprocess-2.4.1.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 01:51:03 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 00:51:03 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za> Message-ID: <1200531062.99.0.0479641618359.issue1336@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I've just attached a diff against trunk that I believe fixes this (based off of jba's patch). Unit tests pass but that doesn't say a whole lot given that this is a hard to reproduce timing/scheduling related bug. Would someone please code review it? ---------- assignee: -> gregory.p.smith Added file: http://bugs.python.org/file9187/diff-subprocess-trunk-1336-01.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 02:35:08 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 01:35:08 -0000 Subject: [issue1736792] dict reentrant/threading bug Message-ID: <1200533708.26.0.202603432972.issue1736792@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: +gregory.p.smith _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 02:37:26 2008 From: report at bugs.python.org (Bill Fenner) Date: Thu, 17 Jan 2008 01:37:26 -0000 Subject: [issue1339] smtplib starttls() should ehlo() if it needs to In-Reply-To: <1193441174.56.0.280335873353.issue1339@psf.upfronthosting.co.za> Message-ID: <1200533846.45.0.917887760612.issue1339@psf.upfronthosting.co.za> Bill Fenner added the comment: jamesh, I attached the patch for that to the already-existing bug, filed in 2003: http://bugs.python.org/issue829951 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 02:42:07 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 01:42:07 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200534127.96.0.464612282941.issue1703448@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: +gregory.p.smith _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 02:47:57 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 01:47:57 -0000 Subject: [issue1596321] KeyError at exit after 'import threading' in other thread Message-ID: <1200534477.12.0.32696927125.issue1596321@psf.upfronthosting.co.za> Gregory P. Smith added the comment: threadingbug.py doesn't fail for me on trunk (linux), anyone else? the output I get is always: Main thread ID: -134346528 Secondary thread ID: -135349328 Exception KeyError: KeyError(-134346528,) in ignored ---------- nosy: +gregory.p.smith _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 02:48:44 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 01:48:44 -0000 Subject: [issue1404925] subprocess.Popen inside thread locks the thread in some case Message-ID: <1200534524.9.0.644394735268.issue1404925@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: +gregory.p.smith _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 02:50:09 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 01:50:09 -0000 Subject: [issue595601] file (& socket) I/O are not thread safe Message-ID: <1200534609.09.0.792776374023.issue595601@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: +gregory.p.smith ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 17 03:01:18 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 02:01:18 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> New submission from Gregory P. Smith: This probably applies to 3.0 as well but i have not tested it there. Here are some sample failures: =========== A ============== Exception in thread Thread-0000000001 (most likely raised during interpreter shutdown):Exception in thread Thread-0000000003 (most likely raised during interpreter shutdown): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xe4cf1bb0 (LWP 22281)] 0x080c0824 in PyEval_EvalFrameEx (f=0x820d59c, throwflag=0) at Python/ceval.c:2633 2633 if (tstate->frame->f_exc_type != NULL) ============================ =========== B ============== Exception in thread Thread-0000000001 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/home/gps/oss/python/trunk/Lib/threading.py", line 486, in __bootstrap_inner File "thread_exit.py", line 24, in run : 'NoneType' object has no attribute 'add' Program received signal SIGINT, Interrupt. [Switching to Thread 0xf7fe08e0 (LWP 21703)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4dac1af0 in sem_wait at GLIBC_2.0 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xf7fe08c0 in ?? () #3 0x080ec9d5 in PyThread_acquire_lock (lock=0x0, waitflag=1) at Python/thread_pthread.h:349 #4 0x080be6d5 in PyEval_RestoreThread (tstate=0x8168050) at Python/ceval.c:314 #5 0x0806caf5 in file_dealloc (f=0xf7f29d58) at Objects/fileobject.c:396 #6 0x0810be36 in frame_dealloc (f=0x8201f04) at Objects/frameobject.c:416 #7 0x080e28d2 in PyThreadState_Clear (tstate=0x8184068) at Python/pystate.c:217 #8 0x080e2994 in PyInterpreterState_Clear (interp=0x8168008) at Python/pystate.c:105 #9 0x080e473b in Py_Finalize () at Python/pythonrun.c:444 #10 0x080e428e in handle_system_exit () at Python/pythonrun.c:1641 #11 0x080e447a in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:1087 #12 0x080e510d in PyRun_SimpleFileExFlags (fp=0x817bd98, filename=0xffffd73c "thread_exit.py", closeit=1, flags=0xffffd518) at Python/pythonrun.c:996 #13 0x0805753b in Py_Main (argc=1, argv=0xffffd5b4) at Modules/main.c:574 #14 0x4d95cea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #15 0x080566c1 in _start () at ../sysdeps/i386/elf/start.S:119 (gdb) bt #0 0x080c0824 in PyEval_EvalFrameEx (f=0x820d59c, throwflag=0) at Python/ceval.c:2633 #1 0x080c451c in PyEval_EvalFrameEx (f=0x820d40c, throwflag=0) at Python/ceval.c:3690 #2 0x080c451c in PyEval_EvalFrameEx (f=0x820d13c, throwflag=0) at Python/ceval.c:3690 #3 0x080c5fd4 in PyEval_EvalCodeEx (co=0xf7f22d58, globals=0xf7f962d4, locals=0x0, args=0xf7f46e18, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2876 #4 0x0810d4d6 in function_call (func=0xf7f41454, arg=0xf7f46e0c, kw=0x0) at Objects/funcobject.c:524 #5 0x0805b0b4 in PyObject_Call (func=0xf7f41454, arg=0x0, kw=0x0) at Objects/abstract.c:1872 #6 0x08061008 in instancemethod_call (func=0xf7f41454, arg=0xf7f46e0c, kw=0x0) at Objects/classobject.c:2509 #7 0x0805b0b4 in PyObject_Call (func=0xf7f3fdec, arg=0x0, kw=0x0) at Objects/abstract.c:1872 #8 0x080be8f9 in PyEval_CallObjectWithKeywords (func=0x0, arg=0xf7fa002c, kw=0x0) at Python/ceval.c:3473 #9 0x080efb4d in t_bootstrap (boot_raw=0x820c910) at ./Modules/threadmodule.c:422 #10 0x4dabd341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #11 0x4da114ee in clone () from /lib/tls/i686/cmov/libc.so.6 ============================ And as with all problems of this sort... sometimes the program exits normally without any problems. I ran python trunk:60012 under gdb above. But these problems occur on older versions such as 2.4. ---------- components: Interpreter Core files: thread_exit.py messages: 60014 nosy: gregory.p.smith severity: normal status: open title: shutdown (exit) can hang or segfault with daemon threads running type: crash versions: Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9188/thread_exit.py __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 03:02:32 2008 From: report at bugs.python.org (Neil Toronto) Date: Thu, 17 Jan 2008 02:02:32 -0000 Subject: [issue1568] PATCH: Armin's attribute lookup caching for 3.0 In-Reply-To: <1197034097.09.0.871896219058.issue1568@psf.upfronthosting.co.za> Message-ID: <1200535352.8.0.747175781594.issue1568@psf.upfronthosting.co.za> Neil Toronto added the comment: Well horse pucky. I plum forgot about deletes. I've attached an update that properly clears the cache entry for the deleted attribute for all non-shadowing subclasses. (It was a small change.) Undef'ing ATTRCACHE_SETATTR_INVALIDATES should work now. Re: different from 2.6: It takes advantage of the lack of "classic" classes. That makes some things a lot easier. Also, I was looking into updating cache entries to see if it would be faster than invalidating all the entries for a type, among other improvements. FWIW, updating cache entries is a little faster on my box. Also: This may have the same problem with test_ctypes' test_incomplete.py as #1700288 did, though I haven't seen any ctypes tests fail. Added file: http://bugs.python.org/file9189/python30-attrcache-2.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 03:06:04 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 02:06:04 -0000 Subject: [issue1339] smtplib starttls() should ehlo() if it needs to In-Reply-To: <1193441174.56.0.280335873353.issue1339@psf.upfronthosting.co.za> Message-ID: <1200535564.96.0.839018994157.issue1339@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 03:06:51 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 02:06:51 -0000 Subject: [issue829951] Fixes smtplib starttls HELO errors Message-ID: <1200535611.68.0.514638019555.issue829951@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: +gregory.p.smith ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 17 03:07:47 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 02:07:47 -0000 Subject: [issue829951] Fixes smtplib starttls HELO errors Message-ID: <1200535667.68.0.987781948896.issue829951@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- assignee: -> gregory.p.smith ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 17 03:08:30 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 02:08:30 -0000 Subject: [issue1339] smtplib starttls() should ehlo() if it needs to In-Reply-To: <1193441174.56.0.280335873353.issue1339@psf.upfronthosting.co.za> Message-ID: <1200535710.06.0.769900769221.issue1339@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- assignee: -> gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 05:25:35 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 17 Jan 2008 04:25:35 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200543934.95.0.377825073627.issue1856@psf.upfronthosting.co.za> Guido van Rossum added the comment: So can we definitely rule out that this could be caused by the recent changes to threading.py (r57216)? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 07:37:56 2008 From: report at bugs.python.org (anatoly techtonik) Date: Thu, 17 Jan 2008 06:37:56 -0000 Subject: [issue1694155] Python 2.5 installer ended prematurely Message-ID: <1200551876.18.0.251081808298.issue1694155@psf.upfronthosting.co.za> anatoly techtonik added the comment: The similar issue is just reported - http://img106.imageshack.us/img106/6892/pythonjo4.png ---------- nosy: +techtonik _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 08:06:06 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 07:06:06 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200553566.88.0.932550048159.issue1856@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Yes i believe it is unrelated to any recent change. I can reproduce both behaviors on my OS X 10.4 dual core mac using Python 2.5.1. Python 2.3 on the mac appears to get stuck in a loop when run stand alone but gets a memory access fault when run under gdb. python 2.4.4 seems to hang most of the time. (all behaviors are possible i expect, i just ran it by hand under several versions a few times) The systems i ran it on when reporting the bug was SMP. As with many threading bugs it might be easier to reproduce on SMP systems but i haven't checked. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 08:09:52 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Thu, 17 Jan 2008 07:09:52 -0000 Subject: [issue1779871] Make python build with gcc-4.2 on OS X 10.4.9 Message-ID: <1200553792.14.0.828970257022.issue1779871@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Sorry for taking so long to get to this. gcc 4.2.1 still produces the following errors with this patch: gcc -c -fno-strict-aliasing -mno-fused-madd -no-cpp-precomp -g -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/opt/local/include -DPy_BUILD_CORE -o Objects/boolobject.o Objects/boolobject.c gcc: unrecognized option '-no-cpp-precomp' cc1: error: unrecognized command line option "-mno-fused-madd" make: *** [Objects/boolobject.o] Error 1 I see you dropped the test for -mno-fused-madd. Since gcc-4.2 doesn't support it, I meant I didn't mind if you dropped the flag entirely. It looks like -no-cpp-precomp stuck around because it doesn't actually cause the compile to fail, just to produce a warning message. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 08:44:25 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 07:44:25 -0000 Subject: [issue829951] Fixes smtplib starttls HELO errors Message-ID: <1200555865.55.0.000316283024386.issue829951@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Fixed in trunk (2.6) r60015. ---------- resolution: -> accepted status: open -> closed versions: +Python 2.5, Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 17 08:55:20 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 07:55:20 -0000 Subject: [issue829951] Fixes smtplib starttls HELO errors Message-ID: <1200556520.45.0.177155857053.issue829951@psf.upfronthosting.co.za> Gregory P. Smith added the comment: and in r60017 on release25-maint for inclusion in 2.5.2. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 17 09:37:36 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 08:37:36 -0000 Subject: [issue1339] smtplib starttls() should ehlo() if it needs to In-Reply-To: <1193441174.56.0.280335873353.issue1339@psf.upfronthosting.co.za> Message-ID: <1200559056.33.0.20170044669.issue1339@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Accepted and applied, with appropriate documentation updates. In svn trunk r60020 for 2.6. ---------- resolution: -> accepted status: open -> closed versions: +Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 12:14:21 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 17 Jan 2008 11:14:21 -0000 Subject: [issue1793] ctypes.util.find_msvcrt() function In-Reply-To: <1200063578.88.0.774833430715.issue1793@psf.upfronthosting.co.za> Message-ID: <1200568461.88.0.733672741047.issue1793@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Fine with me. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 12:30:58 2008 From: report at bugs.python.org (=?utf-8?q?Ren=C3=A9_Stadler?=) Date: Thu, 17 Jan 2008 11:30:58 -0000 Subject: [issue1857] subprocess.Popen.poll/__del__ API breakage In-Reply-To: <1200569458.8.0.233156398307.issue1857@psf.upfronthosting.co.za> Message-ID: <1200569458.8.0.233156398307.issue1857@psf.upfronthosting.co.za> New submission from Ren? Stadler: The commit to r45234 has added an internally used keyword attribute named _deadstate to subprocess.Popen.poll, which is called by the __del__ method of this class. If you derived your own class from subprocess.Popen that overrides .poll() without taking kwargs, the __del__ method will trigger a TypeError about the unexpected keyword argument. Attached is a very simple test program that triggers the problem. It runs just fine with Python 2.4 however. ---------- components: Library (Lib) files: subprocessapi.py messages: 60024 nosy: rene.st severity: major status: open title: subprocess.Popen.poll/__del__ API breakage versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9190/subprocessapi.py __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 13:33:54 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Thu, 17 Jan 2008 12:33:54 -0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> New submission from Tarek Ziad?: explained here: http://wiki.python.org/moin/EnhancedPyPI The patch also adds unit tests for command/register.py and command/upload.py ---------- components: Distutils files: patch.diff messages: 60025 nosy: tarek severity: normal status: open title: Make .pypirc handle multiple servers versions: Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9191/patch.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 13:40:27 2008 From: report at bugs.python.org (Tom Parker) Date: Thu, 17 Jan 2008 12:40:27 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> New submission from Tom Parker: If a piece of text given to textwrap contains one or more "\n", textwrap does not break at that point. I would have expected "\n" characters to cause forced breaks. ---------- components: Library (Lib) messages: 60026 nosy: palfrey severity: minor status: open title: textwrap doesn't linebreak on "\n" type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 13:47:05 2008 From: report at bugs.python.org (Tom Parker) Date: Thu, 17 Jan 2008 12:47:05 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200574025.23.0.692500064604.issue1859@psf.upfronthosting.co.za> Tom Parker added the comment: Attaching a patch that corrects the issue (against python 2.4) Added file: http://bugs.python.org/file9192/textwrap-fix.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 14:27:58 2008 From: report at bugs.python.org (=?utf-8?q?=CE=A7=CF=81=CE=AE=CF=83=CF=84=CE=BF=CF=82_=CE=93=CE=B5=CF=89=CF=81=CE=B3=CE=AF=CE=BF=CF=85_(Christos_Georgiou)?=) Date: Thu, 17 Jan 2008 13:27:58 -0000 Subject: [issue1860] traceback.print_last fails In-Reply-To: <1200576477.85.0.583100874485.issue1860@psf.upfronthosting.co.za> Message-ID: <1200576477.85.0.583100874485.issue1860@psf.upfronthosting.co.za> New submission from ??????? ???????? (Christos Georgiou): traceback.print_last() depends on the existence of sys.last_type, sys.last_value, sys.last_traceback, which don't always exist when called. See attached example file. I will shortly send the patch for Lib/traceback.py ---------- components: Library (Lib) files: test_tb_print_last.py messages: 60028 nosy: tzot severity: normal status: open title: traceback.print_last fails type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9193/test_tb_print_last.py __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 14:43:04 2008 From: report at bugs.python.org (=?utf-8?q?=CE=A7=CF=81=CE=AE=CF=83=CF=84=CE=BF=CF=82_=CE=93=CE=B5=CF=89=CF=81=CE=B3=CE=AF=CE=BF=CF=85_(Christos_Georgiou)?=) Date: Thu, 17 Jan 2008 13:43:04 -0000 Subject: [issue1860] traceback.print_last fails In-Reply-To: <1200576477.85.0.583100874485.issue1860@psf.upfronthosting.co.za> Message-ID: <1200577384.18.0.749197529213.issue1860@psf.upfronthosting.co.za> ??????? ???????? (Christos Georgiou) added the comment: I haven't submitted a patch since the transition from sf.net to bugs.python.org; I assume that I don't have to open a new patch for this, but if I have to, please let me know and I will gladly do it. The unified diff is attached; the test example I issued works with the patched version. Added file: http://bugs.python.org/file9194/traceback_patch.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 14:59:35 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 17 Jan 2008 13:59:35 -0000 Subject: [issue1860] traceback.print_last fails In-Reply-To: <1200576477.85.0.583100874485.issue1860@psf.upfronthosting.co.za> Message-ID: <1200578375.75.0.806297720527.issue1860@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > traceback.print_last() depends on the existence of sys.last_type Yes, that is exactly as documented: >>> help(traceback.print_last) Help on function print_last in module traceback: print_last(limit=None, file=None) This is a shorthand for 'print_exception(sys.last_type, sys.last_value, sys.last_traceback, limit, file)'. Furthermore, in the doc: http://docs.python.org/dev/library/sys.html#sys.last_type "... they are set when an exception is not handled ..." In your script, you *are* handling the exception. Your script really should use traceback.print_exc() instead. BTW, your patch basically makes print_last() identical to print_exc()... ---------- nosy: +amaury.forgeotdarc resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 16:00:40 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Thu, 17 Jan 2008 15:00:40 -0000 Subject: [issue215555] Parser crashes for deeply nested list displays Message-ID: <1200582040.66.0.540749774783.issue215555@psf.upfronthosting.co.za> Changes by Ralf Schmitt: ---------- nosy: +schmir ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 17 16:25:55 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 17 Jan 2008 15:25:55 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200583554.97.0.855938305846.issue1859@psf.upfronthosting.co.za> Mark Dickinson added the comment: Could you give an example showing the unexpected behaviour, and describing what behaviour you'd expect, please? As far as I can tell, the patch has no effect on textwrap.wrap or textwrap.fill, since any newlines have already been converted to spaces by the time the _wrap_chunks method is called. Thanks. ---------- nosy: +marketdickinson __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 16:52:11 2008 From: report at bugs.python.org (Tom Parker) Date: Thu, 17 Jan 2008 15:52:11 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200585131.12.0.855686505935.issue1859@psf.upfronthosting.co.za> Tom Parker added the comment: If replace_whitespace in textwrap is set to False (True is default) then there are newlines. Yes, if you haven't set this then the patch does nothing (but that sounds sane to me) The exact text was "RadioTest TOSSIM stress tester by Tom Parker \nKeeps running TOSSIM with random seeds until something fails", which with a width of 78 gets broken both before and after the "Keeps". __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 17:38:35 2008 From: report at bugs.python.org (Patrick Bureau) Date: Thu, 17 Jan 2008 16:38:35 -0000 Subject: [issue1861] sched scheduler.queue class member is unordered In-Reply-To: <1200587915.01.0.288464638328.issue1861@psf.upfronthosting.co.za> Message-ID: <1200587915.01.0.288464638328.issue1861@psf.upfronthosting.co.za> New submission from Patrick Bureau: In Python 2.4, retrieving sched's scheduler.queue class member would return a time ordered list of events as expected. Since Python 2.5, the same operation retrieves a list of unordered scheduled events. This makes it difficult to know which events are really next in queue, especially if scheduled at the same time. ---------- components: Library (Lib) messages: 60033 nosy: pbureau severity: minor status: open title: sched scheduler.queue class member is unordered type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 17:56:24 2008 From: report at bugs.python.org (Rich) Date: Thu, 17 Jan 2008 16:56:24 -0000 Subject: [issue1862] Error on "Save As" in IDLE (Vista 32-bit) In-Reply-To: <1200588984.34.0.741777378011.issue1862@psf.upfronthosting.co.za> Message-ID: <1200588984.34.0.741777378011.issue1862@psf.upfronthosting.co.za> New submission from Rich: Issue 1743 might be related to this. Using "Save As..." in IDLE does work, but if breakpoints.lst is hidden (which it is when Python generates it) it also generates this error in the Shell: Exception in Tkinter callback Traceback (most recent call last): File "C:\Program Files\Python25\lib\lib-tk\Tkinter.py", line 1403, in __call__ return self.func(*args) File "C:\Program Files\Python25\lib\idlelib\IOBinding.py", line 357, in save_as self.editwin.store_file_breaks() File "C:\Program Files\Python25\lib\idlelib\PyShell.py", line 209, in store_file_breaks new_file = open(self.breakpointPath,"w") IOError: [Errno 13] Permission denied: 'C:\\Users\\Rich\\.idlerc\\breakpoints.lst' The error is not generated if I manually unhide the breakpoints file. The issue is unaffected by the hidden (or not) status of the .idlerc folder. ---------- components: IDLE messages: 60034 nosy: Piffen, kbk, loewis, richjtd, tiran severity: normal status: open title: Error on "Save As" in IDLE (Vista 32-bit) versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 18:13:26 2008 From: report at bugs.python.org (Christian Walther) Date: Thu, 17 Jan 2008 17:13:26 -0000 Subject: [issue1596321] KeyError at exit after 'import threading' in other thread Message-ID: <1200590006.89.0.44638569541.issue1596321@psf.upfronthosting.co.za> Christian Walther added the comment: I'm not sure what you mean by "doesn't fail" - from the output you quote, I'd say that it does fail. It's in fact the same output as I get right now with Python 2.5.1 on Mac OS X. Would you classify that KeyError as expected behavior? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 18:29:45 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 17 Jan 2008 17:29:45 -0000 Subject: [issue1861] sched scheduler.queue class member is unordered In-Reply-To: <1200587915.01.0.288464638328.issue1861@psf.upfronthosting.co.za> Message-ID: <1200590985.95.0.0283581361007.issue1861@psf.upfronthosting.co.za> Guido van Rossum added the comment: Raymond touched it last. :-) Perhaps r38041 is to blame? ---------- assignee: -> rhettinger nosy: +gvanrossum, rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 18:31:52 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 17 Jan 2008 17:31:52 -0000 Subject: [issue1861] sched scheduler.queue class member is unordered In-Reply-To: <1200587915.01.0.288464638328.issue1861@psf.upfronthosting.co.za> Message-ID: <1200591112.59.0.376589976751.issue1861@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looking at that change more, the queue is now maintained as a heapq. Perhaps the queue member is for internal use only? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 18:51:46 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 17 Jan 2008 17:51:46 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200592306.81.0.253518614313.issue1859@psf.upfronthosting.co.za> Guido van Rossum added the comment: The original behavior is intentional. Please don't attempt to "fix" it. ---------- nosy: +gvanrossum resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:03:33 2008 From: report at bugs.python.org (Tom Parker) Date: Thu, 17 Jan 2008 18:03:33 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200593013.03.0.393388312548.issue1859@psf.upfronthosting.co.za> Tom Parker added the comment: Is there any other way to do what I was trying to do then (both dynamic wrapping for long segments + some static breaks)? Right now, the only option I can think of is writing a textwrap.TextWrapper subclass that implements my patch, and copying 70-ish lines of code to make a 2 line change seems like overkill to me. Could this be added as a new option to TextWrapper? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:14:06 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 17 Jan 2008 18:14:06 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200593646.61.0.815728976487.issue1859@psf.upfronthosting.co.za> Guido van Rossum added the comment: Use .splitlines() to break the input into lines, wrap each "line" separately, and join again? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:14:07 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 18:14:07 -0000 Subject: [issue1596321] KeyError at exit after 'import threading' in other thread Message-ID: <1200593647.2.0.709806723564.issue1596321@psf.upfronthosting.co.za> Gregory P. Smith added the comment: gah, sorry i misread the report. you are correct. ---------- versions: +Python 2.4, Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 19:16:29 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 17 Jan 2008 18:16:29 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200593789.68.0.00908105313308.issue1859@psf.upfronthosting.co.za> Mark Dickinson added the comment: For what it's worth, I think there is a legitimate complaint here, though it was initially unclear to me exactly what that complaint was. Consider the following: >>> from textwrap import * >>> T = TextWrapper(replace_whitespace=False, width=14) >>> for line in T.wrap('one two\nthree four'): print line ... one two three four The surprise (if I understand correctly) is not the first line break, but the second, between "three" and "four": it shouldn't be necessary, since "three four" fits quite happily on a line of length 14. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:23:20 2008 From: report at bugs.python.org (Tom Parker) Date: Thu, 17 Jan 2008 18:23:20 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200594200.72.0.772855119794.issue1859@psf.upfronthosting.co.za> Tom Parker added the comment: @Guido: Thanks for the suggestion, it fixes my immediate problem! @Mark: Yup, that was exactly my issue. It took a while to figure out why the heck it was ignoring my linebreaks, and then once I'd found replace_whitespace it appeared to be doing the "wrong" thing to me. I'm still for the changing of the behaviour to what I expected, but I can live with this otherwise. Documenting that this is the behaviour in the textwrap docs, and suggesting workarounds for those who want the other choice might be a good idea tho. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:24:04 2008 From: report at bugs.python.org (Patrick Bureau) Date: Thu, 17 Jan 2008 18:24:04 -0000 Subject: [issue1861] sched scheduler.queue class member is unordered In-Reply-To: <1200587915.01.0.288464638328.issue1861@psf.upfronthosting.co.za> Message-ID: <1200594244.85.0.127357509676.issue1861@psf.upfronthosting.co.za> Patrick Bureau added the comment: Indeed, the queue is not directly exposed by a method, but the information is nonetheless interesting for monitoring the content. If it's not a bug, then maybe this could be changed to a feature request for a new method to retrieve the queue's events. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:26:07 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 17 Jan 2008 18:26:07 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200594367.06.0.812367858281.issue1859@psf.upfronthosting.co.za> Guido van Rossum added the comment: Mark, it looks like the replace_whitespace flag shouldn't be used with input containing newlines. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:26:56 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 17 Jan 2008 18:26:56 -0000 Subject: [issue1861] sched scheduler.queue class member is unordered In-Reply-To: <1200587915.01.0.288464638328.issue1861@psf.upfronthosting.co.za> Message-ID: <1200594416.12.0.683813316994.issue1861@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sure. ---------- priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:39:17 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 17 Jan 2008 18:39:17 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200595157.33.0.543792436408.issue1859@psf.upfronthosting.co.za> Mark Dickinson added the comment: Is it worth double checking with Greg Ward that this behaviour really is intentional? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:40:35 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 17 Jan 2008 18:40:35 -0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1200595235.31.0.911293848897.issue1859@psf.upfronthosting.co.za> Guido van Rossum added the comment: Good luck reaching him. I'm pretty sure that the default behavior intentional *reflows* all input text. Perhaps you can derive clues from reading the docs (which I haven't)? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:41:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Jan 2008 18:41:13 -0000 Subject: [issue1861] sched scheduler.queue class member is unordered In-Reply-To: <1200587915.01.0.288464638328.issue1861@psf.upfronthosting.co.za> Message-ID: <1200595273.27.0.606943066813.issue1861@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Will add a method that returns an ordered list of events. ---------- type: behavior -> rfe versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 19:54:47 2008 From: report at bugs.python.org (Adam Olsen) Date: Thu, 17 Jan 2008 18:54:47 -0000 Subject: [issue1596321] KeyError at exit after 'import threading' in other thread Message-ID: <1200596087.48.0.0708968821558.issue1596321@psf.upfronthosting.co.za> Adam Olsen added the comment: Is the bug avoided if you import threading first and use it instead of thread? I'd like to see thread removed in 3.0 (renamed to _thread or the like.) ---------- nosy: +Rhamphoryncus _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 20:32:27 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Jan 2008 19:32:27 -0000 Subject: [issue1861] sched scheduler.queue class member is unordered In-Reply-To: <1200587915.01.0.288464638328.issue1861@psf.upfronthosting.co.za> Message-ID: <1200598347.96.0.896975319827.issue1861@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Checked-in in rev 60024. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 21:04:13 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 17 Jan 2008 20:04:13 -0000 Subject: [issue1596321] KeyError at exit after 'import threading' in other thread Message-ID: <1200600253.88.0.576014803008.issue1596321@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: If a python daemon thread is still running when the interpreter exits, it is likely to fail in random ways. Here is another example, which does not use imports. I run the script many times, with latest version in trunk, on Windows XP, debug build. In the majority of runs, I get an error message: """ Exception in thread Thread-1 (most likely raised during interpreter shutdown): """ Other tests seem to show that all modules are emptied by the cleanup process, but the thread insists to get "time.sleep". And more interestingly, about every 50 runs, the process segfaults... I suspect that this is a problem similar to http://bugs.python.org/issue1856 ---------- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file9195/thread_crash.py _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 21:12:01 2008 From: report at bugs.python.org (Kathryn M Kowalski) Date: Thu, 17 Jan 2008 20:12:01 -0000 Subject: [issue1836] 'weekly' rotating logging file rotation incorrect In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> Message-ID: <1200600721.48.0.795822217035.issue1836@psf.upfronthosting.co.za> Kathryn M Kowalski added the comment: downloaded from ActiveState aug 2007 Python 2.5.1.1 # Case 2) The day to rollover is further in the interval (i.e., today is # day 2 (Wednesday) and rollover is on day 6 (Sunday). Days to # next rollover is simply 6 - 2 - 1, or 3. # Case 3) The day to rollover is behind us in the interval (i.e., today # is day 5 (Saturday) and rollover is on day 3 (Thursday). # Days to rollover is 6 - 5 + 3, or 4. In this case, it's the # number of days left in the current week (1) plus the number # of days in the next week until the rollover day (3). if when.startswith('W'): day = t[6] # 0 is Monday if day > self.dayOfWeek: daysToWait = (day - self.dayOfWeek) - 1 self.rolloverAt = self.rolloverAt + (daysToWait * (60 * 60 * 24)) if day < self.dayOfWeek: daysToWait = (6 - self.dayOfWeek) + day __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 21:23:25 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 17 Jan 2008 20:23:25 -0000 Subject: [issue1693149] trace.py --ignore-module should accept module name list. Message-ID: <1200601405.94.0.963535242458.issue1693149@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: Removed file: http://bugs.python.org/file7923/trace_patch.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 21:24:30 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Jan 2008 20:24:30 -0000 Subject: [issue1401] urllib2 302 POST In-Reply-To: <1194471779.09.0.301126280852.issue1401@psf.upfronthosting.co.za> Message-ID: <1200601470.27.0.984419701637.issue1401@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi, Sending a 302 in response to a POST is a very common practice so that the browser is redirected to a "normal", non state-changing page after the POST request has been processed. It is useful in that it allows the user to reload the resulting page (fetched with GET) without it popping up a warning dialog, and without re-submitting the request if the user validates the dialog. So, a 302 response after a POST should generate a GET to the new URL. And, of course, without a Content-Length (there's no content in a GET so it can't have a length, does it?). ---------- nosy: +pitrou __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 21:26:27 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 17 Jan 2008 20:26:27 -0000 Subject: [issue1693149] patch to make 'trace.py --ignore-module' accept module name list. Message-ID: <1200601587.18.0.816912143859.issue1693149@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: The patch trace.diff contains the code and doc change. ---------- keywords: +easy severity: normal -> title: trace.py --ignore-module should accept module name list. -> patch to make 'trace.py --ignore-module' accept module name list. type: -> rfe Added file: http://bugs.python.org/file9196/trace.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 21:44:19 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 17 Jan 2008 20:44:19 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200602659.39.0.80643492676.issue1856@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I uploaded a script for a similar issue: http://bugs.python.org/issue1596321 (thread_crash.py) which sometimes segfaults on Windows XP (trunk version, debug build), with the same call stacks as printed by Gregory, on both threads. I explain it this way: On interpreter shutdown, the main thread clears the other's thread TreadState. There you find the instruction: Py_CLEAR(tstate->frame); But this can call arbitrary python code on deallocation of locals, and release the GIL (file.close() in our case). The other thread can then continue to run. If it is given enough processor time before the whole process shutdowns, it will reach this line in ceval.c (line 2633) if (tstate->frame->f_exc_type != NULL) since tstate->frame has been cleared by the main thread ==> boom. There can be several ways to solve this problem: - While clearing a thread state, prevent the "owner" thread to gain focus. Only the main thread can "Py_END_ALLOW_THREADS". The daemon thread is blocked forever, and will die there. - Be smarter when clearing tstate->frame: first call frame_clear(), which will free local variables, but let the frame in a valid state. Only after that, call Py_CLEAR(tstate->frame), when we are sure that no more thread switch can occur. Of course there are many other fields in a frame; we have to inspect them carefully. The first solution seems a more robust approach. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 21:47:06 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 17 Jan 2008 20:47:06 -0000 Subject: [issue1862] Error on "Save As" in IDLE (Vista 32-bit) In-Reply-To: <1200588984.34.0.741777378011.issue1862@psf.upfronthosting.co.za> Message-ID: <1200602826.92.0.485453445525.issue1862@psf.upfronthosting.co.za> Christian Heimes added the comment: It's a duplicate of an already known problem. It seems that files on Vista inherit the flags of their parent folder. Can you test it on your box and see under which circumstances a file has the hidden flag set and how it affects read and write attempts on Vista? ---------- assignee: -> kbk priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 21:48:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 17 Jan 2008 20:48:10 -0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1200602890.19.0.729819886207.issue1858@psf.upfronthosting.co.za> Christian Heimes added the comment: I've changed the target version to 2.6+. We can't add new features to 2.5 and earlier. ---------- keywords: +easy, patch nosy: +tiran priority: -> normal type: -> rfe versions: +Python 3.0 -Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 21:56:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 17 Jan 2008 20:56:45 -0000 Subject: [issue1857] subprocess.Popen.poll/__del__ API breakage In-Reply-To: <1200569458.8.0.233156398307.issue1857@psf.upfronthosting.co.za> Message-ID: <1200603405.07.0.0424806489541.issue1857@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal type: -> resource usage __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 22:00:50 2008 From: report at bugs.python.org (Adam Olsen) Date: Thu, 17 Jan 2008 21:00:50 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200603650.4.0.557134682777.issue1856@psf.upfronthosting.co.za> Adam Olsen added the comment: I think non-main threads should kill themselves off if they grab the interpreter lock and the interpreter is tearing down. They're about to get killed off anyway, when the process exits. PyGILState_Ensure would still be broken. It touches various things that get torn down (autoInterpreterState, autoTLSkey, and the HEAD_LOCK macros) before it grabs the GIL. Reordering should be possible of course. ---------- nosy: +Rhamphoryncus __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 22:03:58 2008 From: report at bugs.python.org (Willard) Date: Thu, 17 Jan 2008 21:03:58 -0000 Subject: [issue1863] NameError with genexp in class scope In-Reply-To: <1200603837.96.0.69062914341.issue1863@psf.upfronthosting.co.za> Message-ID: <1200603837.96.0.69062914341.issue1863@psf.upfronthosting.co.za> New submission from Willard: The following code does not work like expected, it triggers a NameError. class C: a = 42 list(a for _ in 'x') >>> NameError: global name 'a' is not defined This issue was discussed on comp.lang.python in the thread "Is this a bug, or is it me?". ---------- components: Interpreter Core messages: 60060 nosy: cptnwillard severity: minor status: open title: NameError with genexp in class scope type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 22:15:33 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 17 Jan 2008 21:15:33 -0000 Subject: [issue1857] subprocess.Popen.poll/__del__ API breakage In-Reply-To: <1200569458.8.0.233156398307.issue1857@psf.upfronthosting.co.za> Message-ID: <1200604533.24.0.129274815787.issue1857@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Does the attached patch correct your problem? ---------- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file9197/subprocess_poll.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 22:29:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Jan 2008 21:29:42 -0000 Subject: [issue1764286] inspect.getsource does not work with decorated functions Message-ID: <1200605382.59.0.305482053953.issue1764286@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Rather than devising something specific to the co_firstlineno attribute, why not have functools.update_wrapper add a "wrapped_func" attribute pointing to the original function object? That way, each function inspecting the decorated function would have the opportunity to walk the decoration chain if it wants. ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 22:32:19 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Jan 2008 21:32:19 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200605539.87.0.325468843583.issue1856@psf.upfronthosting.co.za> Gregory P. Smith added the comment: agreed, during shutdown the other threads should be stopped. anything to do this complicates acquiring and releasing the GIL by adding another check to see if we're shutting down. brainstorm: I haven't looked at the existing BEGIN_ALLOW_THREADS and END_ALLOW_THREADS implementations but would it be possible to modify them on the fly from the thread doing the shutdown (main or not) while it holds the GIL such that all future calls to BEGIN_ALLOW_THREADS do not actually release the GIL and END_ALLOW_THREADS always blocks. That should bring other threads to a halt pretty quickly and prevent destructors from releasing the GIL (file.close, etc). __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 22:33:25 2008 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 17 Jan 2008 21:33:25 -0000 Subject: [issue1836] 'weekly' rotating logging file rotation incorrect In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> Message-ID: <1200605605.1.0.345211950507.issue1836@psf.upfronthosting.co.za> Vinay Sajip added the comment: There's already been a change to this code, since 2.5.1.1. Here's the code in trunk: if when.startswith('W'): day = t[6] # 0 is Monday if day != self.dayOfWeek: if day < self.dayOfWeek: daysToWait = self.dayOfWeek - day - 1 else: daysToWait = 6 - day + self.dayOfWeek self.rolloverAt = self.rolloverAt + (daysToWait * (60 * 60 * 24)) Does it work for you? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 22:40:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Jan 2008 21:40:35 -0000 Subject: [issue1023290] proposed struct module format code addition Message-ID: <1200606035.53.0.382984094146.issue1023290@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FWIW, an use case of this I have encountered is to generate a string of random bytes from the long object returned by random.getrandbits(). ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 23:06:44 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 17 Jan 2008 22:06:44 -0000 Subject: [issue1863] NameError with genexp in class scope In-Reply-To: <1200603837.96.0.69062914341.issue1863@psf.upfronthosting.co.za> Message-ID: <1200607604.17.0.212567222271.issue1863@psf.upfronthosting.co.za> Guido van Rossum added the comment: It's a weakness, not a bug. Just use a different variable name besides 'a'. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 23:13:53 2008 From: report at bugs.python.org (Jaroslav Pachola) Date: Thu, 17 Jan 2008 22:13:53 -0000 Subject: [issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__ Message-ID: <1200608033.29.0.584638219556.issue1692335@psf.upfronthosting.co.za> Jaroslav Pachola added the comment: While zseil's patch for Python 2.5 works for me (on the current 2.5.1 download), svn version of Python 2.6 rejects the 2.6 patch. Attaching fixed 2.6 patch (2 rejects, 1 fuzz fixed, patch works without complains for me). I would be very glad if someone could review the patches and maybe commit them. ---------- nosy: +jarpa Added file: http://bugs.python.org/file9198/exception_pickling_26.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 17 23:32:04 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Jan 2008 22:32:04 -0000 Subject: [issue1863] NameError with genexp in class scope In-Reply-To: <1200603837.96.0.69062914341.issue1863@psf.upfronthosting.co.za> Message-ID: <1200609124.66.0.707883252517.issue1863@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't follow what you mean. Can you post a working version of the code fragment? ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 23:35:36 2008 From: report at bugs.python.org (Adam Olsen) Date: Thu, 17 Jan 2008 22:35:36 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200609336.15.0.105322116384.issue1856@psf.upfronthosting.co.za> Adam Olsen added the comment: I'm not sure I understand you, Gregory. Are arguing in favour of adding extra logic to the GIL code, or against it? I'm attaching a patch that has non-main thread exit, and it seems to fix the test case. It doesn't fix the PyGILState_Ensure problems though. Also note that PyThread_exit_thread() was completely broken, becoming a no-op once threading was initialized, and even before then it would exit the process rather than just the thread. I've fixed it for pthreads, but not for any of the other platforms. Added file: http://bugs.python.org/file9199/python-trunk-issue1856-threadexit.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 23:39:22 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 17 Jan 2008 22:39:22 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200609562.44.0.212428579795.issue1856@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > PyGILState_Ensure would still be broken. > It touches various things that get torn down (autoInterpreterState, > autoTLSkey, and the HEAD_LOCK macros) before it grabs the GIL. > Reordering should be possible of course. Adam, did you notice the change on revision 59231 ? the PyGILState_Ensure stuff should now remain valid during the PyInterpreterState_Clear() call. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 17 23:54:41 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 17 Jan 2008 22:54:41 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200610481.14.0.261553012689.issue1856@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Adam, your patch cover one case of the thread releasing the GIL (Py_ALLOW_THREADS), but there are more calls to PyThread_acquire_lock (the checkinterval for example). I have a competing patch: it makes the main thread never release the GIL after some point. Other threads stay blocked and don't clean themselves: the OS will take care of them. Both approaches correct the initial problem, though. A remaining question is where exactly in Py_Finalize() we should ban other threads. I think that this point should be as late as possible, to allow some object/resources to be cleaned properly. Added file: http://bugs.python.org/file9200/thread_noswap.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 00:04:42 2008 From: report at bugs.python.org (Adam Olsen) Date: Thu, 17 Jan 2008 23:04:42 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200611082.32.0.993893085682.issue1856@psf.upfronthosting.co.za> Adam Olsen added the comment: > Adam, did you notice the change on revision 59231 ? the > PyGILState_Ensure stuff should now remain valid during the > PyInterpreterState_Clear() call. That doesn't matter. PyGILState_Ensure needs to remain valid *forever*. Only once the process is completely gone can we be sure it won't be called. Note that PyGILState_Ensure has two behaviours: it can be called when your thread is already running python code and has a tstate, or it can be called when you have none. revision 59231 fixed the former, but only when Py_Finalize hasn't finished. It doesn't fix it for any daemon threads, or for dummy threads (created outside of python's control). ... You're right, I did forget the 3 other places that acquire the interpreter_lock. The more I think about it the more I think our two approaches are equivalent, but conditionalizing the release means we don't need to touch the broken PyThread_exit_thread functions. I think the banning should be as early as possible, right after call_sys_exitfunc() has finished. You can't do anything sane once the interpreter is half-gone (despite the precedent of trying anyway.) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 00:23:39 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 17 Jan 2008 23:23:39 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200612219.88.0.401834234216.issue1856@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > That doesn't matter. PyGILState_Ensure needs to remain valid > *forever*. Only once the process is completely gone can we be sure > it won't be called. We could apply the same idea: when exiting, PyGILState_Ensure() blocks forever, except for the main thread of course. Note that all this state must be restartable: after Py_Finalize(), it should be possible to call Py_Initialize() again. This seems to raise the score of the "exit_thread" approach. I don't know if multiple interpreters are well supported, though. Is there somewhere a list of use cases, or a test script that can exercise this? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 00:34:33 2008 From: report at bugs.python.org (Adam Olsen) Date: Thu, 17 Jan 2008 23:34:33 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200612873.13.0.811978012363.issue1856@psf.upfronthosting.co.za> Adam Olsen added the comment: PyGILState_Ensure WOULD block forever if it acquired the GIL before doing anything else. The only way to make Py_Initialize callable after Py_Finalize is to make various bits of the finalization into no-ops. For instance, it's currently impossible to unload C extension modules, so they must be left around permanently. I'm not convinced it works currently, or that there's use cases for it. Note that unloading python.so between Py_Finalize and Py_Initialize would definitely break things, as you'd lose all the global variables maintaining things. That eliminates the only "it's more elegant" argument. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 00:51:14 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 17 Jan 2008 23:51:14 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200613874.75.0.821793753578.issue1856@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > PyGILState_Ensure WOULD block forever if it acquired the GIL > before doing anything else. Is it possible at all? PyThread_acquire_lock is not reentrant. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 01:01:07 2008 From: report at bugs.python.org (Mark Hammond) Date: Fri, 18 Jan 2008 00:01:07 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za> Message-ID: <1200614467.89.0.308323934774.issue1763@psf.upfronthosting.co.za> Mark Hammond added the comment: I'm not sure why the approach of "load-em-all" is being taken. Interestingly, SHGetFolderPathW is listed as deprecated, so I doubt that list will grow too much, but the implementation as specified prevents the user from using other facilities available via the API (ie, what if they *do* want it verified? What if they want to specify CSIDL_FLAG_CREATE?) That said though, I don't object to the patch as it stands, and agree it will meet the requirements of the majority of people who need a "known path" on Windows. ---------- nosy: +mhammond __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 01:12:28 2008 From: report at bugs.python.org (Adam Olsen) Date: Fri, 18 Jan 2008 00:12:28 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200615148.3.0.935031242749.issue1856@psf.upfronthosting.co.za> Adam Olsen added the comment: Hrm. It seems you're right. Python needs thread-local data to determine if the GIL is held by the current thread. Thus, autoTLSkey and all that need to never be torn down. (The check could be done much more directly than the current PyThreadState_IsCurrent machinations, but I digress.) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 02:22:44 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 18 Jan 2008 01:22:44 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200619364.74.0.438903510257.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think the -Wstrict-overflow option may not be enough for the audit we need. The overflow issue in expandtabs() still exists (in 2.5 as well as in the trunk): if (*p == '\n' || *p == '\r') { i += j; old_j = j = 0; if (i < 0) { PyErr_SetString(PyExc_OverflowError, "new string is too long"); return NULL; } } Here i and j are signed ints (Py_ssize_t) initially know to be >= 0; i can only become < 0 through overflow. This is the place where Ismail (cartman) found a crash because the test was optimized away by GCC 4.3 before we added -fwrap. If we ever hope to clean up the code to the point where -fwrapv is no longer needed, the audit should find this spot! (Good thing we at least had a unittest for the overflow check. This should be standard practice for all overflow checks, as long it doesn't require allocating a GB or more of memory.) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 02:51:00 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 18 Jan 2008 01:51:00 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200621060.35.0.698893184962.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: FWIW I reported this to GCC bugzilla as a missing diagnostic @ http://gcc.gnu.org/PR34843 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 05:05:52 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Fri, 18 Jan 2008 04:05:52 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200629152.67.0.896753812277.issue1682@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Here's a patch that adds construction from strings (Guido favored them) and .from_decimal(), changes __init__ to __new__ to enforce immutability, and removes "rational." from repr and the parens from str. I don't expect this to be contentious, so I'll commit it tomorrow unless I hear objections. Added file: http://bugs.python.org/file9201/rational_tweaks.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 05:28:48 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Fri, 18 Jan 2008 04:28:48 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200630528.3.0.430139711238.issue1682@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: After this come the two approximation methods. Both are implemented using the continued fraction representation of the number: http://en.wikipedia.org/wiki/Continued_fraction#Best_rational_approximations. The first, currently named "trim", takes the closest rational whose denominator is less than a given number. This seems useful for computations in which you want to sacrifice some accuracy for speed. At one point in this discussion, Guido suggested that Decimal removed the need for a method like this, and this type isn't optimized for speed anyway. The other, currently named "approximate", returns the "simplest" rational within a certain distance of the real value. This seems useful for converting from float and displaying results to users, where we prefer readability over accuracy ("yes, I'll take '1/3' even though it's farther away than '1234/3690'."). We could provide 0, 1, or both of them, or an accessor for the continued fraction representation of the number, which might help with third-party implementations of both. I've never actually used either of these, so I can't say which is actually more useful. It's probably a good question to send to the full python-dev list. Even if we decide against including them in the class, we might put the implementations into the docs or the test as a demonstration. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 09:07:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 18 Jan 2008 08:07:32 -0000 Subject: [issue1763] Winpath module - easy access to Windows directories like My Documents In-Reply-To: <1200614467.89.0.308323934774.issue1763@psf.upfronthosting.co.za> Message-ID: <47905E33.1010607@cheimes.de> Christian Heimes added the comment: Mark Hammond wrote: > I'm not sure why the approach of "load-em-all" is being taken. > Interestingly, SHGetFolderPathW is listed as deprecated, so I doubt that > list will grow too much, but the implementation as specified prevents > the user from using other facilities available via the API (ie, what if > they *do* want it verified? What if they want to specify > CSIDL_FLAG_CREATE?) > > That said though, I don't object to the patch as it stands, and agree it > will meet the requirements of the majority of people who need a "known > path" on Windows. Indeed, the patch targets the most basic requirements. I wanted to implement a simple and straight solution without implementing a complex API or adding about 30 new constants to a module. Users with extend needs should use your pywin32 package. I don't feel like rewriting your package here. ;) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 09:55:02 2008 From: report at bugs.python.org (Christian Walther) Date: Fri, 18 Jan 2008 08:55:02 -0000 Subject: [issue1596321] KeyError at exit after 'import threading' in other thread Message-ID: <1200646502.59.0.595886054866.issue1596321@psf.upfronthosting.co.za> Christian Walther added the comment: > Is the bug avoided if you import threading first and use it instead of thread? Yes. The bug happens when the (first) import of threading and the call to Py_Finalize() happen in different threads. To reproduce the problem in pure Python, I therefore have to use thread instead of threading to create the secondary thread. (In the C++ application, it's created on the C++ side.) Has anyone checked if the solution I propose in the first post makes sense? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 18 11:49:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2008 10:49:12 -0000 Subject: [issue1222] locale.format bug if thousand separator is space (french separator as example) In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za> Message-ID: <1200653352.44.0.142159966436.issue1222@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I manage to reproduce it on an Ubuntu box with both 2.5.2a0 and SVN trunk. IMO it's a bug since the expected behaviour would be to enforce the locale settings for number formatting. That's the whole purpose of locale.format() after all. (no to mention the discrepancy between %.2f and %9.2f) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 11:49:30 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2008 10:49:30 -0000 Subject: [issue1222] locale.format bug if thousand separator is space (french separator as example) In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za> Message-ID: <1200653370.65.0.224459824839.issue1222@psf.upfronthosting.co.za> Changes by Antoine Pitrou: ---------- versions: +Python 2.6 -Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 12:29:38 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2008 11:29:38 -0000 Subject: [issue1864] test_locale doesn't use unittest In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za> Message-ID: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za> New submission from Antoine Pitrou: test_locale uses its own result printout and doesn't throw an exception when a test fails. It should be probably converted to unittest. ---------- components: Library (Lib) messages: 60085 nosy: pitrou severity: normal status: open title: test_locale doesn't use unittest versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 12:32:54 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 18 Jan 2008 11:32:54 -0000 Subject: [issue215555] Parser crashes for deeply nested list displays Message-ID: <1200655974.29.0.636218491686.issue215555@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Well, I've been a victim of this one yesterday in a real world example. I'm logging the repr of arguments to XMLRPC method calls and we happen to use nested lists, which where deep enough to overflow that stack. It's now 8 years later and I can live with the parser using 60K memory. I think this limit should be upped a bit. ---------- versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 18 12:33:47 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 18 Jan 2008 11:33:47 -0000 Subject: [issue215555] Parser crashes for deeply nested list displays Message-ID: <1200656027.07.0.67916956042.issue215555@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Ofcouse the problem was not logging, but I wanted to "replay" those commands. This is where I got the error. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 18 13:00:49 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 18 Jan 2008 12:00:49 -0000 Subject: [issue1472] Small bat files to build docs on Windows In-Reply-To: <1195529295.02.0.66501222215.issue1472@psf.upfronthosting.co.za> Message-ID: <1200657649.78.0.928327113353.issue1472@psf.upfronthosting.co.za> Christian Heimes added the comment: I've implemented Amaury's suggestions and also added a call to hhc.exe if the target is htmlhelp. The files was added in r60048 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 13:01:55 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 18 Jan 2008 12:01:55 -0000 Subject: [issue1864] test_locale doesn't use unittest In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za> Message-ID: <1200657715.89.0.975492629557.issue1864@psf.upfronthosting.co.za> Christian Heimes added the comment: A patch is welcome. Was the test covered by a GHOP task? ---------- nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 13:19:07 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2008 12:19:07 -0000 Subject: [issue1864] test_locale doesn't use unittest In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za> Message-ID: <1200658747.77.0.473869858243.issue1864@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > A patch is welcome. I'll try to work on it in a few days. > Was the test covered by a GHOP task? Hmm, what is a "GHOP task"? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 14:45:57 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2008 13:45:57 -0000 Subject: [issue1864] test_locale doesn't use unittest In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za> Message-ID: <1200663957.15.0.60381106675.issue1864@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, here is an almost straight conversion of the original test_locale to unittest. Added file: http://bugs.python.org/file9202/locale_test.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 15:02:20 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 18 Jan 2008 14:02:20 -0000 Subject: [issue1863] NameError with genexp in class scope In-Reply-To: <1200603837.96.0.69062914341.issue1863@psf.upfronthosting.co.za> Message-ID: <1200664940.59.0.78408233866.issue1863@psf.upfronthosting.co.za> Facundo Batista added the comment: Don't follow you: >>> class C: a = 42 list(a for _ in 'x') >>> Works here! (Python 2.5.1 on win32) ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 15:18:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2008 14:18:35 -0000 Subject: [issue1222] locale.format bug if thousand separator is space (french separator as example) In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za> Message-ID: <1200665915.75.0.488479165496.issue1222@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Eric, your diagnostic looks right, format() gets confused when it tries to remove padding characters to account for the added thousands separators. It does not check that there were padding characters in the first place, and it assumes that the thousands separator is not a space character itself. Since Georg Brandl and Martin von Loewis are listed as co-authors, I add them to the cc list ;) ---------- nosy: +georg.brandl, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 15:19:58 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 18 Jan 2008 14:19:58 -0000 Subject: [issue1863] NameError with genexp in class scope In-Reply-To: <1200603837.96.0.69062914341.issue1863@psf.upfronthosting.co.za> Message-ID: <1200665998.31.0.460592710276.issue1863@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Facundo, are your sure that your output starts from a fresh environment? I get: C:\Python25>python Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class C: ... a = 42 ... list(a for _ in 'x') ... Traceback (most recent call last): File "", line 1, in File "", line 3, in C File "", line 3, in NameError: global name 'a' is not defined This error is actually approximately "documented" in an obscure sentence in http://docs.python.org/dev/reference/executionmodel.html#naming """ The scope of names defined in a class block is limited to the class block; it does not extend to the code blocks of methods. """ Well, I'm not sure that the genexpr can be considered as a "method", but it is certainly a nested code block. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 16:44:37 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 18 Jan 2008 15:44:37 -0000 Subject: [issue215555] Parser crashes for deeply nested list displays Message-ID: <1200671077.79.0.113237915897.issue215555@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fine, submit a patch. Might as well open a new bug for the patch (referring to this one for background). ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 18 16:47:42 2008 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 18 Jan 2008 15:47:42 -0000 Subject: [issue1694155] Python 2.5 installer ended prematurely Message-ID: <1200671262.86.0.573441754926.issue1694155@psf.upfronthosting.co.za> anatoly techtonik added the comment: It appears to be well known issue with MSI installer which is unable to handle subst'ed drives correctly. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 18 16:58:17 2008 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 18 Jan 2008 15:58:17 -0000 Subject: [issue932563] logging: need a way to discard Logger objects Message-ID: <1200671897.76.0.661382101038.issue932563@psf.upfronthosting.co.za> Vinay Sajip added the comment: LoggerAdapter class added to trunk. Documentation also updated. ---------- resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 18 17:03:59 2008 From: report at bugs.python.org (=?utf-8?q?Ren=C3=A9_Stadler?=) Date: Fri, 18 Jan 2008 16:03:59 -0000 Subject: [issue1857] subprocess.Popen.poll/__del__ API breakage In-Reply-To: <1200569458.8.0.233156398307.issue1857@psf.upfronthosting.co.za> Message-ID: <1200672239.71.0.723409483454.issue1857@psf.upfronthosting.co.za> Ren? Stadler added the comment: Yes, it works. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 17:23:35 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 18 Jan 2008 16:23:35 -0000 Subject: [issue1865] Bytes alias for 2.6 In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za> Message-ID: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za> New submission from Christian Heimes: As discussed on the ml. It adds a bytes builtin and syntax for b"" and br"". ---------- components: Interpreter Core files: trunk_bytes.patch keywords: patch messages: 60099 nosy: tiran priority: normal severity: normal status: open title: Bytes alias for 2.6 type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9203/trunk_bytes.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 17:33:20 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 18 Jan 2008 16:33:20 -0000 Subject: [issue1863] NameError with genexp in class scope In-Reply-To: <1200603837.96.0.69062914341.issue1863@psf.upfronthosting.co.za> Message-ID: <1200674000.64.0.59648185103.issue1863@psf.upfronthosting.co.za> Facundo Batista added the comment: Yes, something was bad with my test. Now I have the same behaviour. Sorry for the noise. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 17:44:16 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 18 Jan 2008 16:44:16 -0000 Subject: [issue1863] NameError with genexp in class scope In-Reply-To: <1200665998.31.0.460592710276.issue1863@psf.upfronthosting.co.za> Message-ID: <4790D7E5.4070002@gmx.net> Georg Brandl added the comment: Amaury Forgeot d'Arc schrieb: > Well, I'm not sure that the genexpr can be considered as a "method", but > it is certainly a nested code block. Technically it is a method, that's why this happens. I added a note to the docs in r60051; closing this as "won't fix". ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 17:49:04 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 18 Jan 2008 16:49:04 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200674944.21.0.851909392326.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Problem was that -Wall at the end was resetting -Wstrict-overflow, so here is the current results for signed overflow warnings (python 2.5 branch SVN), a lot of them : Parser/acceler.c: In function 'fixstate': Parser/acceler.c:90: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/node.c: In function 'PyNode_AddChild': Parser/node.c:90: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/node.c:90: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/firstsets.c: In function 'calcfirstset': Parser/firstsets.c:71: warning: assuming signed overflow does not occur when simplifying conditional to constant Parser/pgen.c: In function 'compile_item': Parser/pgen.c:268: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/pgen.c: In function '_Py_pgen': Parser/pgen.c:454: warning: assuming signed overflow does not occur when simplifying conditional to constant Parser/pgen.c:556: warning: assuming signed overflow does not occur when simplifying conditional to constant Parser/pgen.c:604: warning: assuming signed overflow does not occur when simplifying conditional to constant Parser/pgen.c:611: warning: assuming signed overflow does not occur when simplifying conditional to constant Parser/tokenizer.c: In function 'new_string': Parser/tokenizer.c:175: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/tokenizer.c: In function 'tok_get': Parser/tokenizer.c:1163: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/tokenizer.c: In function 'PyTokenizer_Get': Parser/tokenizer.c:1443: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/tokenizer.c:1443: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/tokenizer.c: In function 'PyTokenizer_FromString': Parser/tokenizer.c:607: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/abstract.c: In function 'PyObject_CallMethodObjArgs': Objects/abstract.c:2038: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/abstract.c:2038: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/abstract.c: In function 'PyObject_CallFunctionObjArgs': Objects/abstract.c:2038: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/abstract.c:2038: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/intobject.c: In function 'PyInt_FromUnicode': Objects/intobject.c:394: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/listobject.c: In function 'merge_at': Objects/listobject.c:1595: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/listobject.c:1459: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/listobject.c:1459: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/listobject.c:1595: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/longobject.c: In function 'PyLong_FromUnicode': Objects/longobject.c:1701: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/longobject.c: In function '_PyLong_AsScaledDouble': Objects/longobject.c:703: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/longobject.c:703: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/longobject.c: In function 'long_sub': Objects/longobject.c:1978: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/longobject.c: In function 'l_divmod': Objects/longobject.c:1802: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/longobject.c:1802: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/stringobject.c: In function 'string_expandtabs': Objects/stringobject.c:3331: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/stringobject.c:3339: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/stringobject.c: In function 'string_replace': Objects/stringobject.c:2509: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/stringobject.c:2509: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/stringobject.c:2509: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/stringobject.c:2509: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/stringobject.c:2672: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/stringobject.c: In function 'string_count': Objects/stringlib/count.h:24: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/stringlib/count.h:24: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/unicodeobject.c: In function 'unicode_expandtabs': Objects/unicodeobject.c:5719: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/unicodeobject.c:5727: warning: assuming signed overflow does not occur when simplifying conditional to constant Objects/unicodeobject.c: In function 'PyUnicodeUCS4_Compare': Objects/unicodeobject.c:5376: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/unicodeobject.c:5376: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Objects/unicodeobject.c: In function 'PyUnicodeUCS4_Join': Objects/unicodeobject.c:4659: warning: assuming signed overflow does not occur when simplifying conditional to constant Python/ast.c: In function 'ast_for_genexp': Python/ast.c:1195: warning: assuming signed overflow does not occur when simplifying conditional to constant Python/ast.c:1160: warning: assuming signed overflow does not occur when simplifying conditional to constant Python/ast.c: In function 'ast_for_atom': Python/ast.c:1040: warning: assuming signed overflow does not occur when simplifying conditional to constant Python/ast.c:1005: warning: assuming signed overflow does not occur when simplifying conditional to constant Python/bltinmodule.c: In function 'builtin_map': Python/bltinmodule.c:907: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Python/bltinmodule.c:847: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Python/bltinmodule.c:847: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/tokenizer.c:1163: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/tokenizer.c: In function 'PyTokenizer_Get': Parser/tokenizer.c:1443: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Parser/tokenizer.c:1443: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Python/getargs.c:994: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Python/getargs.c:1040: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Python/getargs.c: In function 'seterror': Python/getargs.c:357: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Python/import.c: In function 'PyImport_ExtendInittab': Python/import.c:3129: warning: assuming signed overflow does not occur when simplifying conditional to constant Python/modsupport.c: In function 'va_build_value': Python/modsupport.c:529: warning: assuming signed overflow does not occur when simplifying conditional to constant Python/sysmodule.c: In function 'sys_getframe': Python/sysmodule.c:650: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 Modules/gcmodule.c: In function 'collect': Modules/gcmodule.c:767: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 ./Modules/_sre.c: In function 'sre_match': ./Modules/_sre.c:1002: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1069: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1086: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1143: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1185: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1214: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1238: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1251: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1277: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1291: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1308: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1395: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1408: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c: In function 'sre_umatch': ./Modules/_sre.c:1002: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1069: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1086: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1143: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1185: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1214: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1238: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1251: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1277: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1291: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1308: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1395: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1408: warning: assuming signed overflow does not occur when simplifying conditional to constant /packages/python-2.5/Modules/stropmodule.c: In function 'strop_replace': /packages/python-2.5/Modules/stropmodule.c:1102: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 /packages/python-2.5/Modules/_heapqmodule.c: In function 'heappop': /packages/python-2.5/Modules/_heapqmodule.c:146: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 /packages/python-2.5/Modules/_hotshot.c: In function 'pack_line_times': /packages/python-2.5/Modules/_hotshot.c:693: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 /packages/python-2.5/Modules/_hotshot.c: In function 'pack_frame_times': /packages/python-2.5/Modules/_hotshot.c:706: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 /packages/python-2.5/Modules/binascii.c: In function 'binascii_a2b_base64': /packages/python-2.5/Modules/binascii.c:320: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 /packages/python-2.5/Modules/binascii.c: In function 'binascii_b2a_uu': /packages/python-2.5/Modules/binascii.c:287: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 /packages/python-2.5/Modules/parsermodule.c: In function 'validate_subscript': /packages/python-2.5/Modules/parsermodule.c:2811: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 /packages/python-2.5/Modules/cPickle.c: In function 'Unpickler_noload': /packages/python-2.5/Modules/cPickle.c:193: warning: assuming signed overflow does not occur when simplifying conditional to constant /packages/python-2.5/Modules/cPickle.c:194: warning: assuming signed overflow does not occur when reducing constant in comparison /packages/python-2.5/Modules/cPickle.c:4232: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false /packages/python-2.5/Modules/cPickle.c:194: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false /packages/python-2.5/Modules/cPickle.c: In function 'load': /packages/python-2.5/Modules/cPickle.c:4232: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false /packages/python-2.5/Modules/audioop.c: In function 'audioop_ratecv': /packages/python-2.5/Modules/audioop.c:1150: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 /packages/python-2.5/Modules/imageop.c: In function 'imageop_dither2grey2': /packages/python-2.5/Modules/imageop.c:430: warning: assuming signed overflow does not occur when simplifying conditional to constant /packages/python-2.5/Modules/_csv.c: In function 'join_append_data': /packages/python-2.5/Modules/_csv.c:969: warning: assuming signed overflow does not occur when simplifying conditional to constant /packages/python-2.5/Modules/expat/xmlparse.c: In function 'getAttributeId': /packages/python-2.5/Modules/expat/xmlparse.c:5337: warning: assuming signed overflow does not occur when simplifying conditional to constant /packages/python-2.5/Modules/dlmodule.c: In function 'dl_call': /packages/python-2.5/Modules/dlmodule.c:103: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 18:53:43 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 18 Jan 2008 17:53:43 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200678823.37.0.315365252621.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! Good catch about -Wall. I think I am now able to reproduce these results with gcc 4.2. These results, while much more disturbing regarding the state of our code base, at least restore my faith in GCC. :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 19:10:07 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 18 Jan 2008 18:10:07 -0000 Subject: [issue1865] Bytes alias for 2.6 In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za> Message-ID: <1200679807.02.0.479842955119.issue1865@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks like you forgot tokenize.py Make sure none of this gets merged into 3.0! ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 19:16:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 18 Jan 2008 18:16:27 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200680187.06.0.278221177504.issue1621@psf.upfronthosting.co.za> Christian Heimes added the comment: I still don't get additional error messages on the trunk. I've altered the configure.in file to include -Wstrict-overflow=5 after -Wall: gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -Wstrict-overflow=5 -I. -IInclude -I./Include -DPy_BUILD_CORE -o Objects/listobject.o Objects/listobject.c Either all problems are already solved or I'm doing something wrong here. $ LC_ALL=C gcc-4.2 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.1 (Ubuntu 4.2.1-5ubuntu4) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 19:25:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 18 Jan 2008 18:25:19 -0000 Subject: [issue1865] Bytes alias for 2.6 In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za> Message-ID: <1200680719.86.0.0663291577093.issue1865@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied in r60052. I'll run a svnmerge now and exclude the revision from the merge. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 19:27:53 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 18 Jan 2008 18:27:53 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200680873.41.0.543835667235.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: -Wstrict-overflow=5 is not valid afaik its 1-3, 3 for most verbose also you need a recent gcc 4.3 snapshot for best results, check your distribution for gcc-snapshot package. About the -Wall thing it seems to be a gcc bug, but for now workaround is easy :-) Regards, ismail __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 19:46:10 2008 From: report at bugs.python.org (phil) Date: Fri, 18 Jan 2008 18:46:10 -0000 Subject: [issue1866] const arg for PyInt_FromString In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za> Message-ID: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za> New submission from phil: In PyInt_FromString(), please change the type of the first arg from char * to const char *. That is, of course, if the function indeed does not write to the string. (I took a quick look at the code; it doesn't appear to.) If the function does modify the string, it should be documented. I'm getting a compiler error in some C++ code when I use a std::string::c_str() as the arg. Of course, I could cast away the const, but paranoid as I am, I'd like reassurance that I can do so with impunity. :-) ---------- components: Extension Modules messages: 60108 nosy: philipdumont severity: minor status: open title: const arg for PyInt_FromString type: rfe versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 19:50:23 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 18 Jan 2008 18:50:23 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200682223.46.0.349461590595.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Btw I think we need an unsigned version of Py_ssize_t to fix this problem cleanly. I am not sure if you would agree with me though. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 19:56:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 18 Jan 2008 18:56:45 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200682605.94.0.311317611063.issue1621@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't think we can make Py_ssize_t unsigned. On several occasions Python uses -1 as error flag or default flag. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 19:59:34 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 18 Jan 2008 18:59:34 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200682774.69.0.0976761591747.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: No I mean we need a new unsigned variant. Else we will have to cast it to unsigned for many overflow cases which is ugly. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 20:44:01 2008 From: report at bugs.python.org (Santiago Gala) Date: Fri, 18 Jan 2008 19:44:01 -0000 Subject: [issue1867] patch for pydoc to work in py3k In-Reply-To: <1200685441.85.0.862976764101.issue1867@psf.upfronthosting.co.za> Message-ID: <1200685441.85.0.862976764101.issue1867@psf.upfronthosting.co.za> New submission from Santiago Gala: Basically I'm finding to simple errors: * an iterable where it expects a list, I solved it using a simple list comprehension on the original iterable * it tries to write a string to the socket, I used "UTF-8" both in the Content-Type header and in the conversion to bytes. It could easyly be parameterized. This two changes enabled me to get a basic pydoc running. ---------- components: Documentation files: pydoc.patch messages: 60112 nosy: sgala severity: normal status: open title: patch for pydoc to work in py3k versions: Python 3.0 Added file: http://bugs.python.org/file9204/pydoc.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 21:22:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 18 Jan 2008 20:22:21 -0000 Subject: [issue1867] patch for pydoc to work in py3k In-Reply-To: <1200685441.85.0.862976764101.issue1867@psf.upfronthosting.co.za> Message-ID: <1200687741.41.0.0407362065301.issue1867@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Library (Lib) -Documentation keywords: +easy, patch priority: -> normal type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 21:30:29 2008 From: report at bugs.python.org (Kathryn M Kowalski) Date: Fri, 18 Jan 2008 20:30:29 -0000 Subject: [issue1836] 'weekly' rotating logging file rotation incorrect In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> Message-ID: <1200688229.36.0.742916234287.issue1836@psf.upfronthosting.co.za> Kathryn M Kowalski added the comment: I did not put suggested code in - walking through it and counting days on my fingers I don't think it works. If the desired rollover day is Tuesday (self.dayOfWeek = 1) and today is Tuesday (day = 1) then self.rolloverAt is the seconds to midnight as if daysToWait =0, and it rolls over at midnight Tuesday. However if the desired rollover day is Tuesday (self.dayOfWeek = 1) and today is Monday (day = 0) then daysToWait = 0 again. It rolls over on Monday at midnight - not Tuesday at midnight. If the desired rollover day is Tuesday (self.dayOfWeek = 1) and today is Wednesday (day = 2) then daysToWait = 5. It also rolls over on Monday at midnight - not Tuesday at midnight. Changing it to: day = t[6] # 0 is Monday if day != self.dayOfWeek: if day < self.dayOfWeek: daysToWait = self.dayOfWeek - day else: daysToWait = 6 - day + self.dayOfWeek + 1 would make it equivalent to what I have running and appears to work. (Always rolls (ends) on day specified at midnight.) Alternatively, if you wanted to change it so the log starts on the day specified you could just get rid of "if day != self.dayOfWeek:" from your code. if when.startswith('W'): day = t[6] # 0 is Monday if day < self.dayOfWeek: daysToWait = self.dayOfWeek - day - 1 else: daysToWait = 6 - day + self.dayOfWeek self.rolloverAt = self.rolloverAt + (daysToWait * (60 * 60 * 24)) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 21:47:55 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 18 Jan 2008 20:47:55 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200689275.2.0.686844362416.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: The proper thing to do here is to add -Werror=strict-overflow to the CFLAGS (*before* -Wall -- we should fix the position of -Wall!); this will turn all those spots into errors, forcing us to fix them, and alerting users who might be using a newer compiler than we tested with. This should be done in favor of -fwrapv, but only if strict-overflow is supported (which we can find out in the same way as we found out whether -fwrapv is supported). I think in practice this means GCC 4.2 or newer. Can someone come up with a patch? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 21:49:08 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 18 Jan 2008 20:49:08 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200689348.66.0.483351596686.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: An unsigned variant of Py_ssize_t would just be size_t -- that's a much older type than ssize_t. I don't think we need to invent a Py_ name for it. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 21:58:32 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 18 Jan 2008 20:58:32 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200689912.59.0.0472995243763.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Replace -fwrapv with -Wstrict-overflow=3 -Werror=strict-overflow when supported. Guido, does this do what you wanted? Regards, ismail Added file: http://bugs.python.org/file9205/overflow-error.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 22:03:17 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 18 Jan 2008 21:03:17 -0000 Subject: [issue1866] const arg for PyInt_FromString In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za> Message-ID: <1200690197.29.0.593921632034.issue1866@psf.upfronthosting.co.za> Guido van Rossum added the comment: So how about submitting a patch *and* building everything from scratch and running all the unit tests to make sure this doesn't break anything? ---------- nosy: +gvanrossum priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 22:05:33 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 18 Jan 2008 21:05:33 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200690333.74.0.212675070858.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: Close, I'd like to keep the -fwrapv if -Wstrict-overflow isn't supported. Also, would checking this in mean we can't build with GCC 4.3 until those issues are all fixed? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 22:10:47 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2008 21:10:47 -0000 Subject: [issue1353344] python.desktop Message-ID: <1200690647.07.0.842601724692.issue1353344@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm adding a French translation, and removing the "Application" category (which doesn't exist as per the freedesktop specification). Also, I think the Name is too long right now. "The Python programming language" or "Le langage de programmation Python" looks longish for a menu entry. So I suggest just setting the Name to "Python". The only people for which the menu entry may be useful know what Python is anyway. PS : the desktop entry specification http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec the menu spec (listing possible categories) http://www.freedesktop.org/wiki/Specifications/menu-spec ---------- nosy: +pitrou Added file: http://bugs.python.org/file9206/python.desktop _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 18 22:11:27 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 18 Jan 2008 21:11:27 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200690687.52.0.835424033311.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Yes it breaks compilation with gcc 4.3. Fixing these bugs are mostly s/int/unsigned int. But some parts of code need Python wisdom :/ New patch attached adressing your comment. Added file: http://bugs.python.org/file9207/overflow-error2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 22:11:58 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2008 21:11:58 -0000 Subject: [issue1353344] python.desktop Message-ID: <1200690718.08.0.901184480181.issue1353344@psf.upfronthosting.co.za> Changes by Antoine Pitrou: Added file: http://bugs.python.org/file9208/pycon.png _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 18 22:13:36 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 18 Jan 2008 21:13:36 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200690816.62.0.98315177669.issue1621@psf.upfronthosting.co.za> Changes by Ismail Donmez: Added file: http://bugs.python.org/file9209/overflow-error3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 22:16:53 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 18 Jan 2008 21:16:53 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200691013.88.0.759292706364.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: Would you mind also adding patches for the places you think you can fix, and providing us with a list of places you need help with? O'm hoping that Greg or Christian can help reviewing these and committing them. Thanks much for your help BTW! ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 22:20:12 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 18 Jan 2008 21:20:12 -0000 Subject: [issue1568] PATCH: Armin's attribute lookup caching for 3.0 In-Reply-To: <1197034097.09.0.871896219058.issue1568@psf.upfronthosting.co.za> Message-ID: <1200691212.46.0.529305817895.issue1568@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Yes, now the test suite runs without problem. The patch also contains a file "fastattr_test_py3k.py". It seems to perform some benchmark, but I'm not sure to understand its output. Is it meant to be added somewhere? Does it make sense to keep it as a unit test? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 18 22:22:13 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2008 21:22:13 -0000 Subject: [issue588825] unittest.py, better error message Message-ID: <1200691333.36.0.0795370904815.issue588825@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The second proposal shouldn't be accepted as-is. If you compare two very long or undecipherable strings, you don't want them to appear in the failure message. ---------- nosy: +pitrou ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 18 23:24:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 18 Jan 2008 22:24:18 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200695058.35.0.537076820713.issue1621@psf.upfronthosting.co.za> Christian Heimes added the comment: The -fwrapv doesn't look right. You aren't testing for -fwrapv at all ;) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 00:15:06 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 18 Jan 2008 23:15:06 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200698106.39.0.66310012379.issue1621@psf.upfronthosting.co.za> Changes by Ismail Donmez: Added file: http://bugs.python.org/file9210/overflow-error4.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 00:36:00 2008 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 18 Jan 2008 23:36:00 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200699360.66.0.312455603389.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: First stub at fixing overflows, regresses following tests : test_doctests.py test_locale.py test_long.py test_long_future.py test_optparse.py test_pickle.py test_str.py (crash) test_string.py (crash) test_unicode.py (crash) test_userstring.py (crash) test_xpickle.py Not great, but a start. Added file: http://bugs.python.org/file9211/fix-overflows-try1.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 00:40:41 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 18 Jan 2008 23:40:41 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1200682223.46.0.349461590595.issue1621@psf.upfronthosting.co.za> Message-ID: <479138F6.8080209@v.loewis.de> Martin v. L?wis added the comment: > Btw I think we need an unsigned version of Py_ssize_t to fix this > problem cleanly. I am not sure if you would agree with me though. There is an unsigned version, it's called "size_t". __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 00:55:07 2008 From: report at bugs.python.org (Peter Fein) Date: Fri, 18 Jan 2008 23:55:07 -0000 Subject: [issue1868] threading.local doesn't free attrs when assigning thread exits In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za> Message-ID: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za> New submission from Peter Fein: threading.local doesn't free attributes assigned to a local() instance when the assigning thread exits. See attached patch for _threading_local.py doctests. Per discussion with Crys and arkanes in #python, this may be an issue with PyThreadState_Clear / PyThreadState_GetDict This appears to affect both thread._local and _threading_local.py ---------- components: Library (Lib) files: _threading_local.py.patch messages: 60127 nosy: pfein severity: normal status: open title: threading.local doesn't free attrs when assigning thread exits type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9212/_threading_local.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 01:10:14 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 00:10:14 -0000 Subject: [issue1868] threading.local doesn't free attrs when assigning thread exits In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za> Message-ID: <1200701414.38.0.475833853004.issue1868@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Extension Modules priority: -> high versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 01:55:19 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 19 Jan 2008 00:55:19 -0000 Subject: [issue1694] floating point number round failures under Linux In-Reply-To: <1198497194.94.0.235082191295.issue1694@psf.upfronthosting.co.za> Message-ID: <1200704119.11.0.881432956594.issue1694@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm closing this as invalid. ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 02:04:26 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 19 Jan 2008 01:04:26 -0000 Subject: [issue1869] Builtin round function is sometimes inaccurate for floats In-Reply-To: <1200704666.74.0.121276369369.issue1869@psf.upfronthosting.co.za> Message-ID: <1200704666.74.0.121276369369.issue1869@psf.upfronthosting.co.za> New submission from Mark Dickinson: The documentation for the builtin round(x, n) says: "Values are rounded to the closest multiple of 10 to the power minus n." This isn't always true; for example: Python 2.6a0 (trunk:59634M, Dec 31 2007, 17:27:56) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> round(562949953421312.5, 1) 562949953421312.62 Here 562949953421312.5 is exactly representable as an IEEE754 double, so the output from the round function should be exactly the same as the input. Assigning this to myself to remind me to try to fix it someday. ---------- assignee: marketdickinson messages: 60129 nosy: marketdickinson priority: low severity: minor status: open title: Builtin round function is sometimes inaccurate for floats type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 02:24:25 2008 From: report at bugs.python.org (Martey Dodoo) Date: Sat, 19 Jan 2008 01:24:25 -0000 Subject: [issue1092502] Memory leak in socket.py on Mac OS X Message-ID: <1200705865.71.0.568482044189.issue1092502@psf.upfronthosting.co.za> Martey Dodoo added the comment: I am not sure that this is outdated. After running into memory errors trying to download messages with attachments using imaplib, I ran the example client and server. After iteration 357, there was a malloc error, just like etrepum suggested. I am using Mac OS X 10.5, with Python 2.5 (not the Apple-supplied Python). ---------- nosy: +martey title: Memory leak in socket.py on Mac OS X 10.3 -> Memory leak in socket.py on Mac OS X _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 02:59:35 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 19 Jan 2008 01:59:35 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200707975.18.0.845269424358.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: (About the latest patch): this all looks good to me. The comment that "Decimal provides no other public way to detect nan and infinity." is not true (though it once was). Decimal has public methods is_nan and is_infinite, added as part of updating to the most recent specification. (Yes, it also has private methods _isnan and _isinfinity, dating from long ago; I'm working on a patch that gets rid of the duplication.) (About the approximation methods): I agree that these aren't a necessary part of a Rational module---just something that might be nice to have around. So my vote would be for adding either 0 or 1 of these; adding two such similar methods with similar use-cases just seems like a cause of possible confusion to me. I'd also vote against a method for providing the convergents of the continued-fraction, but that's just me. See what python- dev says! One interesting use-case for approximate is to recover a simple rational from a float, in a case where the float was rational to begin with, but lost a little accuracy in conversion; approximate works well here because you generally have some idea how close the float is to the rational. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 03:17:42 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 19 Jan 2008 02:17:42 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200709061.98.0.979398611883.issue1682@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Were the new methods part of the spec update? If so that's great. If not, we need to take them out. We want zero API creep that isn't mandated by the spec (no playing fast and loose with this module). __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 03:28:37 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 19 Jan 2008 02:28:37 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200709717.94.0.0471293876521.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: Raymond: > Were the new methods part of the spec update? If so that's great. Yes. See http://www2.hursley.ibm.com/decimal/damisc.html > If not, we need to take them out. We want zero API creep that isn't > mandated by the spec (no playing fast and loose with this module). Understood. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 04:25:21 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 19 Jan 2008 03:25:21 -0000 Subject: [issue923643] long <-> byte-string conversion Message-ID: <1200713121.23.0.605497065494.issue923643@psf.upfronthosting.co.za> Mark Dickinson added the comment: It seems to me that this issue is almost entirely subsumed by issue #1023290. I'm quite tempted to close this and direct further discussion there---personally, I'd support Josiah's proposed struct addition. Paul: if you're still listening after all this time, is it true that between them, Josiah's proposal and pickle.{encode_long, decode_long} would cover your needs? ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 04:54:58 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 19 Jan 2008 03:54:58 -0000 Subject: [issue1023290] proposed struct module format code addition Message-ID: <1200714898.46.0.938885377612.issue1023290@psf.upfronthosting.co.za> Mark Dickinson added the comment: See also issue #923643. ---------- nosy: +marketdickinson _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 10:53:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 09:53:01 -0000 Subject: [issue1222] locale.format bug if thousand separator is space (french separator as example) In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za> Message-ID: <1200736381.21.0.0259696156957.issue1222@psf.upfronthosting.co.za> Georg Brandl added the comment: The space removal was there before my change; assigning to Martin. ---------- assignee: -> loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 10:56:34 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sat, 19 Jan 2008 09:56:34 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1200736594.32.0.538475682642.issue1682@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I coulda sworn I looked for is_nan and is_infinite. Oh well, switched to using .is_finite, which is even better and checked in as r60068. Thanks for the pointer. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 10:57:31 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 09:57:31 -0000 Subject: [issue487738] weaklist Message-ID: <1200736651.72.0.866319272102.issue487738@psf.upfronthosting.co.za> Facundo Batista added the comment: No news after two years and a half. Considering the arguments of Raymond after S. Kochen brought the issue back up, I'd close the patch as rejected. Feel free to bring this issue to python-dev, and if there's real need, we can always open the patch back. Fred, it's assigned to you... what do you think? Thank you! ---------- nosy: +facundobatista ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 11:02:41 2008 From: report at bugs.python.org (Jonathan Share) Date: Sat, 19 Jan 2008 10:02:41 -0000 Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za> Message-ID: <1200736961.89.0.96958322225.issue1823@psf.upfronthosting.co.za> Jonathan Share added the comment: Martin, I can almost agree with you _if_ I was setting the Content-Transfer- Encoding myself, however I am not. I am setting the charset and the library chooses an appropriate Content-Transfer-Encoding to represent the mime part with. Currently I can't see any way other than reading the source or writing a test case (and that would require understanding what the email.mime module was doing "under the hood") for a developer to find out which Content-Transfer-Encoding was going to be used. Also, just from a usability point of view I would expect that creating an invalid mime part would be a little more difficult. Especially considering the fix should be as small as adding "if not encoding in valid encodings: raise SensibleException". __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 11:11:10 2008 From: report at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Sat, 19 Jan 2008 10:11:10 -0000 Subject: [issue602245] os.popen() negative error code IOError Message-ID: <1200737470.21.0.670207238726.issue602245@psf.upfronthosting.co.za> Jeroen Ruigrok van der Werven added the comment: Current output on XP with 2.5.1: D:\>test.py Traceback (most recent call last): File "D:\test.py", line 12, in r.close() IOError: [Errno 0] Error Traceback (most recent call last): File "D:\test.py", line 20, in r.close() IOError: [Errno 0] Error Traceback (most recent call last): File "D:\test.py", line 29, in e.close() IOError: [Errno 0] Error ---------- nosy: +asmodai ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 11:43:50 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 10:43:50 -0000 Subject: [issue616247] More documentation for the imp module Message-ID: <1200739430.85.0.969286305963.issue616247@psf.upfronthosting.co.za> Facundo Batista added the comment: If those two are obsolete, we may add a DeprecationWarning in 2.6 and hide/remove them in 2.7. What do you think? ---------- nosy: +facundobatista ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 11:48:50 2008 From: report at bugs.python.org (ThurnerRupert) Date: Sat, 19 Jan 2008 10:48:50 -0000 Subject: [issue1870] bug tracker exception, when searching for "creator" In-Reply-To: <1200739730.74.0.0823503686607.issue1870@psf.upfronthosting.co.za> Message-ID: <1200739730.74.0.0823503686607.issue1870@psf.upfronthosting.co.za> New submission from ThurnerRupert: filling out "creator" gives the following traceback: Traceback (most recent call last): File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/client.py", line 770, in renderContext result = pt.render(self, None, None, **args) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/templating.py", line 323, in render getEngine().getContext(c), output, tal=1, strictinsert=0)() File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 192, in __call__ self.interpret(self.program) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in interpret handlers[opcode](self, args) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 666, in do_useMacro self.interpret(macro) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in interpret handlers[opcode](self, args) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 411, in do_optTag_tal self.do_optTag(stuff) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 396, in do_optTag return self.no_tag(start, program) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 391, in no_tag self.interpret(program) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in interpret handlers[opcode](self, args) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 689, in do_defineSlot self.interpret(slot) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in interpret handlers[opcode](self, args) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 411, in do_optTag_tal self.do_optTag(stuff) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 396, in do_optTag return self.no_tag(start, program) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 391, in no_tag self.interpret(program) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in interpret handlers[opcode](self, args) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/TAL/TALInterpreter.py", line 462, in do_setLocal_tal self.engine.setLocal(name, self.engine.evaluateValue(expr)) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/PageTemplates/TALES.py", line 227, in evaluate return expression(self) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/PageTemplates/Expressions.py", line 194, in __call__ return self._eval(econtext) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/PageTemplates/Expressions.py", line 189, in _eval return render(ob, econtext.vars) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/PageTemplates/Expressions.py", line 95, in render ob = ob() File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/cgi/templating.py", line 2463, in batch l = [id for id in klass.filter(matches, filterspec, sort, group) File "/home/roundup/roundup-production//lib/python2.4/site- packages/roundup/backends/rdbms_common.py", line 2178, in filter del d[None] KeyError ---------- components: None messages: 60142 nosy: ThurnerRupert severity: minor status: open title: bug tracker exception, when searching for "creator" type: crash versions: 3rd party __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 11:53:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 10:53:40 -0000 Subject: [issue1870] bug tracker exception, when searching for "creator" In-Reply-To: <1200739730.74.0.0823503686607.issue1870@psf.upfronthosting.co.za> Message-ID: <1200740020.61.0.496404289722.issue1870@psf.upfronthosting.co.za> Georg Brandl added the comment: Note that this only happens when the user does not exist. It's a bug nevertheless. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 11:54:04 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 10:54:04 -0000 Subject: [issue1870] bug tracker exception, when searching for "creator" In-Reply-To: <1200739730.74.0.0823503686607.issue1870@psf.upfronthosting.co.za> Message-ID: <1200740044.59.0.932243676639.issue1870@psf.upfronthosting.co.za> Georg Brandl added the comment: I've now moved it to the meta tracker, where python's roundup is maintained. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 11:54:51 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 10:54:51 -0000 Subject: [issue1870] bug tracker exception, when searching for "creator" In-Reply-To: <1200739730.74.0.0823503686607.issue1870@psf.upfronthosting.co.za> Message-ID: <1200740091.37.0.37624080661.issue1870@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 11:58:46 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 10:58:46 -0000 Subject: [issue1870] bug tracker exception, when searching for "creator" In-Reply-To: <1200739730.74.0.0823503686607.issue1870@psf.upfronthosting.co.za> Message-ID: <1200740326.08.0.249890273492.issue1870@psf.upfronthosting.co.za> Georg Brandl added the comment: (for reference: http://psf.upfronthosting.co.za/roundup/meta/issue179) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 12:01:48 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 11:01:48 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200740508.49.0.823454850893.issue1621@psf.upfronthosting.co.za> Christian Heimes added the comment: Crashes ain't good ;) I suggest that you chance only a small portion of files at a time, then make && ./python Lib/test/regrtest.py. Start with the Parser, then move over to AST and the rest of Python/. You may have to remove all pyc and pyo files if you change code related to the Parser, AST and byte code marshaling. I'm not sure if it's required but it's worth a shot. Bytecode mismatches can lead to strange errors. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 12:04:02 2008 From: report at bugs.python.org (ThurnerRupert) Date: Sat, 19 Jan 2008 11:04:02 -0000 Subject: [issue1871] help fix memory usage or leak - edgewall trac 0.11 blocked ... In-Reply-To: <1200740642.79.0.946360280482.issue1871@psf.upfronthosting.co.za> Message-ID: <1200740642.79.0.946360280482.issue1871@psf.upfronthosting.co.za> New submission from ThurnerRupert: how could one find a memory problem in python. edgewall trac 0.11 seems blocked for such a problem, where nobody had a really helpful idea for nearly three weeks. see http://groups.google.com/group/trac- dev/browse_thread/thread/116e519da54f16b. ---------- messages: 60147 nosy: ThurnerRupert severity: normal status: open title: help fix memory usage or leak - edgewall trac 0.11 blocked ... versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 12:07:37 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 11:07:37 -0000 Subject: [issue602245] os.popen() negative error code IOError Message-ID: <1200740857.91.0.659398002214.issue602245@psf.upfronthosting.co.za> Facundo Batista added the comment: os.popen* are deprecated, we should use subprocess now... could you please try what happens with this alternate example I'm attaching? Thank you! ---------- nosy: +facundobatista ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 12:08:17 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 11:08:17 -0000 Subject: [issue602245] os.popen() negative error code IOError Message-ID: <1200740897.92.0.556704201499.issue602245@psf.upfronthosting.co.za> Facundo Batista added the comment: Boo, I forgot the attach, :p Added file: http://bugs.python.org/file9213/using_subprocess.py ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 12:12:10 2008 From: report at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Sat, 19 Jan 2008 11:12:10 -0000 Subject: [issue602245] os.popen() negative error code IOError Message-ID: <1200741130.75.0.976486847664.issue602245@psf.upfronthosting.co.za> Jeroen Ruigrok van der Werven added the comment: Using Facundo's attachment: D:\>using_subprocess.py D:\> ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 12:12:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 11:12:29 -0000 Subject: [issue1871] help fix memory usage or leak - edgewall trac 0.11 blocked ... In-Reply-To: <1200740642.79.0.946360280482.issue1871@psf.upfronthosting.co.za> Message-ID: <1200741149.85.0.361345311409.issue1871@psf.upfronthosting.co.za> Christian Heimes added the comment: You should take the problem to the general Python mailing list. Sorry, but the bug tracker is the wrong place. Some hints: Do you have classes with a __del__ method which may create reference cycles? The GC can't break cycles when a __del__ method is involved. Are you keeping references to tracebacks, exception objects (except Exception, err) or frames (sys._getframe())? ---------- nosy: +tiran resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 12:21:51 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 11:21:51 -0000 Subject: [issue602245] os.popen() negative error code IOError Message-ID: <1200741711.48.0.450489206778.issue602245@psf.upfronthosting.co.za> Facundo Batista added the comment: Great! So it's fixed, :) ---------- resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 12:43:56 2008 From: report at bugs.python.org (Jonathan Share) Date: Sat, 19 Jan 2008 11:43:56 -0000 Subject: [issue1822] email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added. In-Reply-To: <1200308097.55.0.0363931421733.issue1822@psf.upfronthosting.co.za> Message-ID: <1200743036.28.0.273722976738.issue1822@psf.upfronthosting.co.za> Jonathan Share added the comment: Attaching a patch for the quick fix I proposed below. I would still like to see some feedback regarding making the design of the mime module more object oriented. email.Message really shouldn't be making assumtions about how subclasses represent their state. Added file: http://bugs.python.org/file9214/issue1822.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 12:49:48 2008 From: report at bugs.python.org (Jonathan Share) Date: Sat, 19 Jan 2008 11:49:48 -0000 Subject: [issue1822] email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added. In-Reply-To: <1200308097.55.0.0363931421733.issue1822@psf.upfronthosting.co.za> Message-ID: <1200743388.87.0.279350466687.issue1822@psf.upfronthosting.co.za> Changes by Jonathan Share: ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 13:36:31 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 12:36:31 -0000 Subject: [issue1822] email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added. In-Reply-To: <1200308097.55.0.0363931421733.issue1822@psf.upfronthosting.co.za> Message-ID: <1200746191.79.0.730672970558.issue1822@psf.upfronthosting.co.za> Facundo Batista added the comment: Fixed in r60073. Regarding the flag, you're right: maybe these classes should deal it in other way... but maybe there're reasons to do this. If you want to push a better structure for this flag, feel free to raise the issue in python-dev. Anyway, the real problem, here, is fixed, :) ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 13:44:13 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 12:44:13 -0000 Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za> Message-ID: <1200746653.33.0.181807689447.issue1823@psf.upfronthosting.co.za> Christian Heimes added the comment: Please provide an unit test which verifies the bug and a fix for the bug. ---------- nosy: +tiran priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 13:58:46 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 12:58:46 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200747526.1.0.149157857674.issue1621@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 14:05:13 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 13:05:13 -0000 Subject: [issue632323] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: <1200747913.69.0.793869897944.issue632323@psf.upfronthosting.co.za> Facundo Batista added the comment: Martin: I'll close this as it's marked as invalid, and nobody answered since two years ago. If you think that your first patch is a good solution (Fredrik agreed, good enough for me). If you want, reopen the bug and assign it to me, and I'll apply it and add a few lines and an example in the docs. ---------- status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 14:46:59 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 13:46:59 -0000 Subject: [issue1266] segfault in curses when calling redrawwin() before refresh() In-Reply-To: <1192126484.51.0.25368750134.issue1266@psf.upfronthosting.co.za> Message-ID: <1200750419.51.0.26850521384.issue1266@psf.upfronthosting.co.za> A.M. Kuchling added the comment: The C program does crash, but newwin() is returning NULL and the code should really be checking for this case. When I try the Python script with 2.5-maint and 2.6-trunk, I get the error: amk at amk:~/source/p/25$ ./python.exe ../python/curses-01.py Traceback (most recent call last): File "../python/curses-01.py", line 8, in curses.wrapper(foobar) File "/Users/amk/source/p/25/Lib/curses/wrapper.py", line 44, in wrapper return func(stdscr, *args, **kwds) File "../python/curses-01.py", line 4, in foobar winmain = curses.newwin(50,50,50,50) _curses.error: curses function returned NULL I removed the import of the 'readline' module because I don't have it on my Mac, but that seems unlikely to make a difference. ---------- resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 14:52:23 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 13:52:23 -0000 Subject: [issue1720705] thread + import => crashes? Message-ID: <1200750743.77.0.914049516755.issue1720705@psf.upfronthosting.co.za> Christian Heimes added the comment: For 2.6 I've fixed several places where C code was importing a Python module in a non-threadsafe way. In general a thread start must never be caused by an import and only the main thread should import modules. Imports within or caused-by a thread other than the main thread isn't safe. ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 14:55:14 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 13:55:14 -0000 Subject: [issue1720705] thread + import => crashes? Message-ID: <1200750914.54.0.215852903604.issue1720705@psf.upfronthosting.co.za> Christian Heimes added the comment: Follow up: Can somebody please document the possible issue with threads and imports in large, friendly letters? ---------- components: +Documentation -None _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 14:57:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 13:57:28 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi In-Reply-To: <1193367242.94.0.6471500852.issue1332@psf.upfronthosting.co.za> Message-ID: <1200751048.68.0.455487752018.issue1332@psf.upfronthosting.co.za> Christian Heimes added the comment: The problem was fixed and the OP suggested to close the bug. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 15:00:05 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 14:00:05 -0000 Subject: [issue774221] 2.3c1: zipfile.py confused by garbage at the very end of zip Message-ID: <1200751205.37.0.117484920777.issue774221@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I searched for references to 'zip file concatenate|append' and found no reference to extra data being ignored, so I'll agree with Alan and close this patch. Thanks for your contribution, anyway! ---------- resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 15:01:27 2008 From: report at bugs.python.org (Lorenzo Stoakes) Date: Sat, 19 Jan 2008 14:01:27 -0000 Subject: [issue1598083] Top-level exception handler writes to stdout unsafely Message-ID: <1200751287.64.0.198668993193.issue1598083@psf.upfronthosting.co.za> Lorenzo Stoakes added the comment: Surely it's not a good idea to attempt to generate an exception within an exception handler, couldn't this lead to an infinite loop scenario? The checks prior to fputs() handle any errors by calling err_closed() and returning -1. I suggest we do the same for the fputs() statement. According to the documentation for fputs(), any errors result in a return value of EOF, therefore an if(fputs(...) == EOF) { ... } check seems appropriate. I enclose a patch to this end, please let me know whether I'm way off the mark here :-) ---------- nosy: +codegrunt Added file: http://bugs.python.org/file9215/fputsfix _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 15:03:53 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 14:03:53 -0000 Subject: [issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__ Message-ID: <1200751433.47.0.349650165475.issue1692335@psf.upfronthosting.co.za> Facundo Batista added the comment: The last patch (exception_pickling_26.diff) applies cleanly, and all the tests run ok. System: Python 2.6a0 (trunk:60073M, Jan 19 2008, 11:41:33) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 ---------- nosy: +facundobatista _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 15:05:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:05:32 -0000 Subject: [issue1868] threading.local doesn't free attrs when assigning thread exits In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za> Message-ID: <1200751532.21.0.725440635801.issue1868@psf.upfronthosting.co.za> Christian Heimes added the comment: I've added a test in r60075. It shows that threading.local cleans up thread local data except for the last stopped thread. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 15:14:54 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 14:14:54 -0000 Subject: [issue818065] mailbox._Subfile readline() bug Message-ID: <1200752094.23.0.744009311487.issue818065@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I guess this bug report is out of date: mailbox.py doesn't seem to contain a _Subfile class, the ProxyFile.readline() function is one line, and there's no self.pos variable either. Probably 2.5's rewrite of the module removed this code. ---------- resolution: -> invalid status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 15:19:26 2008 From: report at bugs.python.org (Zooko O'Whielacronx) Date: Sat, 19 Jan 2008 14:19:26 -0000 Subject: [issue1759997] poll() on cygwin sometimes fails [PATCH] Message-ID: <1200752366.02.0.875851426665.issue1759997@psf.upfronthosting.co.za> Zooko O'Whielacronx added the comment: This bug was fixed in cygwin 1.5.25-7, released 2007-12-17. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 15:21:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:21:47 -0000 Subject: [issue1746071] class mutex doesn't do anything atomically Message-ID: <1200752507.54.0.317157523067.issue1746071@psf.upfronthosting.co.za> Christian Heimes added the comment: Making the mutex module thread safe is a low hanging fruit for the bug day. *wink* ---------- keywords: +easy nosy: +tiran versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 15:21:48 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:21:48 -0000 Subject: [issue1779233] PyThreadState_SetAsyncExc and the main thread Message-ID: <1200752508.83.0.26509763882.issue1779233@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> theller nosy: +theller _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 15:21:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:21:54 -0000 Subject: [issue1035] bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA In-Reply-To: <1188200568.98.0.237862868597.issue1035@psf.upfronthosting.co.za> Message-ID: <1200752514.02.0.913258306554.issue1035@psf.upfronthosting.co.za> Christian Heimes added the comment: *ping* Can this issue be closed? ---------- nosy: +tiran resolution: -> fixed status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 15:22:01 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:22:01 -0000 Subject: [issue1432694] Implement preemptive threads in Python Message-ID: <1200752521.05.0.00175187634242.issue1432694@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 15:28:29 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 14:28:29 -0000 Subject: [issue705836] struct.pack of floats in non-native endian order Message-ID: <1200752909.11.0.33251648204.issue705836@psf.upfronthosting.co.za> Facundo Batista added the comment: A lot of water passed around this bridge, but I don't know if this is fixed: In the trunk right, now: >>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 >>> v 7.9999999999999964 >>> p = struct.pack( ">f", v ) >>> p 'A\x00\x00\x00' >>> struct.unpack(">f", p) (8.0,) ---------- nosy: +facundobatista ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 15:38:38 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Sat, 19 Jan 2008 14:38:38 -0000 Subject: [issue1146] TextWrap vs words 1-character shorter than the width In-Reply-To: <1189517857.01.0.116632649875.issue1146@psf.upfronthosting.co.za> Message-ID: <1200753518.06.0.603933601597.issue1146@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: As i revisited this one for the Bug Day, I found I could optimize the patch a little bit. Here's the updated diff. Also... I think it's a good candidate for 2.5 maintenance release. Any thoughts ? Added file: http://bugs.python.org/file9216/textwrap_revised_r60075.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 15:42:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:42:05 -0000 Subject: [issue1306] Embedded python reinitialization In-Reply-To: <1192887310.11.0.424828418654.issue1306@psf.upfronthosting.co.za> Message-ID: <1200753725.79.0.0332973925039.issue1306@psf.upfronthosting.co.za> Christian Heimes added the comment: Right, the Python bug tracker is not the place to report Stackless bugs. But my tests have revealed a bug in Python 3.0. As today multiple reinitialization still fails. I suspect a reference bug but I can't proof it. ---------- assignee: gvanrossum -> priority: low -> high versions: -Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 15:42:14 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:42:14 -0000 Subject: [issue1175933] threading.Condition.wait() return value indicates timeout Message-ID: <1200753734.57.0.973169257073.issue1175933@psf.upfronthosting.co.za> Christian Heimes added the comment: Another bug day task. ---------- keywords: +easy nosy: +tiran type: -> rfe versions: +Python 2.6 -Python 2.4 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 15:42:33 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:42:33 -0000 Subject: [issue1175194] import statement likely to crash if module launches threads Message-ID: <1200753753.17.0.299858886181.issue1175194@psf.upfronthosting.co.za> Christian Heimes added the comment: Don't spawn new threads at module level. An import must never trigger the creation of a new thread. It's a design issue on your side. But you can blame us for not documenting the issues with imports and threads. ;) ---------- components: +Documentation nosy: +tiran resolution: -> invalid status: open -> pending type: -> behavior versions: +Python 2.6 -Python 2.4 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 15:42:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:42:41 -0000 Subject: [issue1503789] Cannot write source code in UTF16 Message-ID: <1200753761.52.0.332033956385.issue1503789@psf.upfronthosting.co.za> Christian Heimes added the comment: I turned it into a feature request for 2.6 with low priority. Somebody should either fix/implement the UTF-16 support or update the docs. ---------- components: +Documentation nosy: +tiran priority: normal -> low type: -> rfe versions: +Python 2.6 -Python 2.4 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 15:45:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:45:26 -0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1200753926.4.0.527994646115.issue1657@psf.upfronthosting.co.za> Christian Heimes added the comment: Can somebody else review the patch? therve from the Twisted team has reviewed it but I like to get an opinion of another core developer. Guido seems to be too busy. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 15:46:05 2008 From: report at bugs.python.org (John Lenton) Date: Sat, 19 Jan 2008 14:46:05 -0000 Subject: [issue1675533] setup.py LDFLAGS regexp is wrong Message-ID: <1200753965.62.0.491000147792.issue1675533@psf.upfronthosting.co.za> John Lenton added the comment: This was fixed in r57389 by georg.brandl by changing the replacement string '' to ' ' (turning the option into a non-option). Steps to reproduce this on Ubuntu Feisty, before that revision, were: $ mkdir banana $ sudo mv /usr/include/sqlite3.h banana/ $ make clean && ./configure && make [...] Failed to find the necessary bits to build these modules: _sqlite3 bsddb185 sunaudiodev [...] $ make clean && CPPFLAGS=-Ibanana ./configure && make Failed to find the necessary bits to build these modules: bsddb185 sunaudiodev $ make clean && CPPFLAGS=-Ibanana\ -Rmango ./configure && make Failed to find the necessary bits to build these modules: _sqlite3 bsddb185 sunaudiodev ---------- nosy: +Chipaca _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 15:48:09 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:48:09 -0000 Subject: [issue886488] WinPython 2.3.3 crashes using popen2 to spawn lots of child Message-ID: <1200754089.33.0.477553408711.issue886488@psf.upfronthosting.co.za> Christian Heimes added the comment: An easy C task for the bug day. ---------- components: +Interpreter Core keywords: +easy type: -> crash ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 15:48:33 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 14:48:33 -0000 Subject: [issue1792] o(n*n) marshal.dumps performance for largish objects with patch In-Reply-To: <1200061286.09.0.117532205028.issue1792@psf.upfronthosting.co.za> Message-ID: <1200754113.51.0.118801133119.issue1792@psf.upfronthosting.co.za> Christian Heimes added the comment: Yet another easy C task for the bug day. ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 15:50:57 2008 From: report at bugs.python.org (Peter Fein) Date: Sat, 19 Jan 2008 14:50:57 -0000 Subject: [issue1868] threading.local doesn't free attrs when assigning thread exits In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za> Message-ID: <1200754257.01.0.80085528542.issue1868@psf.upfronthosting.co.za> Peter Fein added the comment: re: r60075 : I'm unclear - is this intentional behavior? Adding a `del t` at line 24 after the loop doesn't help either (though it does make the test somewhat clear IMO). __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 16:10:36 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 15:10:36 -0000 Subject: [issue1779] int("- 1") is valud, but float("- 1") isn't. Which is right? In-Reply-To: <1199926803.21.0.243129638352.issue1779@psf.upfronthosting.co.za> Message-ID: <1200755435.99.0.734230204073.issue1779@psf.upfronthosting.co.za> Facundo Batista added the comment: Only left the version 3.0, as the OP said it's not so important as to break possible previous working code. ---------- nosy: +facundobatista versions: -Python 2.4, Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 16:15:53 2008 From: report at bugs.python.org (Jaroslav Pachola) Date: Sat, 19 Jan 2008 15:15:53 -0000 Subject: [issue1693149] patch to make 'trace.py --ignore-module' accept module name list. Message-ID: <1200755753.73.0.43278454556.issue1693149@psf.upfronthosting.co.za> Jaroslav Pachola added the comment: The patch works fine for me. ---------- nosy: +jarpa severity: -> normal _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 16:20:54 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 19 Jan 2008 15:20:54 -0000 Subject: [issue1868] threading.local doesn't free attrs when assigning thread exits In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za> Message-ID: <1200756054.22.0.969405942987.issue1868@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: On the opposite, simply evaluating local.__dict__ just before "deadlist = ...", frees the last value. Weird? I found that in threadmodule.c, the local object has a "self->dict" attribute, which contains the last used dictionary. The dictionaries switch when tp_getattro or tp_setattro are called from a different thread. Maybe localobject could be rewritten with no self->dict at all. Or make self->dict a *borrowed* reference inside the array of thread-local dictionaries. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 16:32:30 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 15:32:30 -0000 Subject: [issue1675533] setup.py LDFLAGS regexp is wrong Message-ID: <1200756750.22.0.329169673258.issue1675533@psf.upfronthosting.co.za> Facundo Batista added the comment: Yes, not it works ok! Thanks John for the testing example, and Carson for the report. ---------- nosy: +facundobatista resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 16:34:11 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 15:34:11 -0000 Subject: [issue1675533] setup.py LDFLAGS regexp is wrong Message-ID: <1200756851.5.0.573059982702.issue1675533@psf.upfronthosting.co.za> Facundo Batista added the comment: Bloody fingers. I meant that *now" it works ok. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 17:09:01 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Sat, 19 Jan 2008 16:09:01 -0000 Subject: [issue1714] ConfigParser.py do not allow leading (and trailing) space in values. In-Reply-To: <1199115002.03.0.289718233868.issue1714@psf.upfronthosting.co.za> Message-ID: <1200758941.6.0.932855790964.issue1714@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: Attached patch contain the added behavior, some unit tests to validate it and updated documentation. ---------- nosy: +quentin.gallet-gilles Added file: http://bugs.python.org/file9217/cfgparser_doublequotes.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:15:52 2008 From: report at bugs.python.org (Thomas Heller) Date: Sat, 19 Jan 2008 16:15:52 -0000 Subject: [issue1872] change the bool struct format code from 't' to '?' In-Reply-To: <1200759352.1.0.256938962764.issue1872@psf.upfronthosting.co.za> Message-ID: <1200759352.1.0.256938962764.issue1872@psf.upfronthosting.co.za> New submission from Thomas Heller: Currently the struct module uses the format code 't' for the bool datatype (this was added in python 2.6, in revision 53508). This conflicts with the specification in PEP 3118, which proposes the '?' format character for the bool type, 't' is proposed in the patch for a bit type. This patch changes the struct module format code for 'bool' from 't' to '?'. ---------- components: Extension Modules files: struct-bool.patch keywords: patch messages: 60187 nosy: theller severity: normal status: open title: change the bool struct format code from 't' to '?' versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9218/struct-bool.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:17:33 2008 From: report at bugs.python.org (Thomas Heller) Date: Sat, 19 Jan 2008 16:17:33 -0000 Subject: [issue1872] change the bool struct format code from 't' to '?' In-Reply-To: <1200759352.1.0.256938962764.issue1872@psf.upfronthosting.co.za> Message-ID: <1200759453.14.0.299979263698.issue1872@psf.upfronthosting.co.za> Changes by Thomas Heller: ---------- components: +Documentation __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:25:28 2008 From: report at bugs.python.org (Mike Beachy) Date: Sat, 19 Jan 2008 16:25:28 -0000 Subject: [issue1204] readline configuration for shared libs w/o curses dependencies In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za> Message-ID: <1200759928.35.0.467530138568.issue1204@psf.upfronthosting.co.za> Mike Beachy added the comment: Urgh. Re-reading this, I could barely understand what the hell I was saying. The problem: 64 bit compiles will dump core when readline is used if they don't properly identify the presence of readline and use the system headers. The solution: fix autoconf to properly recognize when readline is present by providing configure's readline test program with all necessary prerequisites. caveat: The fix for issue 1703270 (already checked in post-2.5.1) works around this by hard coding the completion_matches prototype in Modules/readline.c, but the autoconf fix seems better long term. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:28:07 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 19 Jan 2008 16:28:07 -0000 Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za> Message-ID: <1200760087.8.0.372883138177.issue1823@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: You're right that this should probably be fixed in the subclass, but you also have to remember that the parser generally doesn't create subclass instances. It only creates instances of Message. As long as you can make it work properly with the parser and generator, I'm okay with overriding set_charset() in the subclass to do the right thing. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:35:08 2008 From: report at bugs.python.org (Roy Smith) Date: Sat, 19 Jan 2008 16:35:08 -0000 Subject: [issue1873] threading.Thread.join() description could be more explicit In-Reply-To: <1200760508.83.0.199534103582.issue1873@psf.upfronthosting.co.za> Message-ID: <1200760508.83.0.199534103582.issue1873@psf.upfronthosting.co.za> New submission from Roy Smith: At http://docs.python.org/lib/thread-objects.html, under join(), it says: "As join() always returns None, you must call isAlive() to decide whether a timeout happened." This would be better if it were more explicit, i.e. "As join() always returns None, you must call isAlive() after calling join() to decide whether a timeout happened; a return value of True indicates the join() call timed out." ---------- components: Documentation messages: 60190 nosy: roysmith severity: minor status: open title: threading.Thread.join() description could be more explicit type: rfe versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:35:28 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 16:35:28 -0000 Subject: [issue742598] SocketServer timeout, zombies Message-ID: <1200760528.46.0.36356654104.issue742598@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Committed to Python 2.6 in rev. 60080. Thanks for your contribution! Whenever you find time, it would be nice if you could sign and submit a Python contributor agreement; please see http://www.python.org/psf/contrib/ for the forms. ---------- resolution: -> accepted status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 17:41:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 16:41:59 -0000 Subject: [issue1873] threading.Thread.join() description could be more explicit In-Reply-To: <1200760508.83.0.199534103582.issue1873@psf.upfronthosting.co.za> Message-ID: <1200760919.25.0.912438214866.issue1873@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl keywords: +easy nosy: +georg.brandl priority: -> low versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:43:05 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Sat, 19 Jan 2008 16:43:05 -0000 Subject: [issue1598083] Top-level exception handler writes to stdout unsafely Message-ID: <1200760985.1.0.886366856409.issue1598083@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: The attached patch doesn't fix the issue I described: * err_closed() will raise an exception indicated the file is closed. However, the file is not necessarily closed, so this exception is wrong. * Most or all PyFile_WriteString callers are still not checking its return value, so the exception will generally be ignored. * The traceback still won't be reported. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 17:43:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Jan 2008 16:43:44 -0000 Subject: [issue1204] readline configuration for shared libs w/o curses dependencies In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za> Message-ID: <1200761024.14.0.610350731086.issue1204@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Build priority: -> normal versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:48:12 2008 From: report at bugs.python.org (Jonathan Share) Date: Sat, 19 Jan 2008 16:48:12 -0000 Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za> Message-ID: <1200761292.88.0.717790928428.issue1823@psf.upfronthosting.co.za> Jonathan Share added the comment: I'm beginning to realise this is slightly bigger than I first thought ;-) Trying to make a nice test case for this issue, I thought it would be a good idea for the parser to register a defect for invalid content- transfer-encoding so I can test against that in the test case rather than fragile substring tests. Unfortunately the parser code isn't the easiest code to get your head around on a first look. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:54:21 2008 From: report at bugs.python.org (John Lenton) Date: Sat, 19 Jan 2008 16:54:21 -0000 Subject: [issue976880] mmap needs a rfind method Message-ID: <1200761661.31.0.82646223787.issue976880@psf.upfronthosting.co.za> John Lenton added the comment: Attached patch adds two things: an 'end' argument to find, and an 'rfind' method. This includes minimal tests for rfind, but as I actually refactored find and rfind into a single method, tests covering find also cover most of rfind :). I added 'end' first because the refactoring seemed more natural (symmetric?) after that. Also included are updated docs, and NEWS. ---------- nosy: +Chipaca Added file: http://bugs.python.org/file9219/mmap.rfind.patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 17:55:42 2008 From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=) Date: Sat, 19 Jan 2008 16:55:42 -0000 Subject: [issue1779] int("- 1") is valud, but float("- 1") isn't. Which is right? In-Reply-To: <1199926803.21.0.243129638352.issue1779@psf.upfronthosting.co.za> Message-ID: <1200761742.49.0.587291697653.issue1779@psf.upfronthosting.co.za> Juan Jos? Conti added the comment: This is my first patch. Bug fix on revision 60076. ---------- nosy: +jjconti Added file: http://bugs.python.org/file9220/bug_fix_for_1779.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:56:06 2008 From: report at bugs.python.org (Malte Helmert) Date: Sat, 19 Jan 2008 16:56:06 -0000 Subject: [issue1679] tokenizer permits invalid hex integer In-Reply-To: <1198240546.79.0.598190279926.issue1679@psf.upfronthosting.co.za> Message-ID: <1200761766.67.0.300112321396.issue1679@psf.upfronthosting.co.za> Malte Helmert added the comment: I can find three places where "0x" is accepted, but probably shouldn't: 1. Python's tokenizer: >>> 0x 0 >>> 0xL ValueError: invalid literal for long() with base 16: '0xL' => I think these should both be syntax errors. 2. int builtin: >>> int("0x", 0) == int("0x", 16) == 0 True >>> long("0x", 0) Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for long() with base 16: '0x' >>> long("0x", 16) Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for long() => The long behaviour looks right to me, and I think the int behaviour should match it. 3. tokenize module: This currently accepts "0x" and "0xL" as single tokens. The obvious fix would lead to these two being reported as two separate tokens ("0": NUMBER, "x": NAME; "0": NUMBER, "xL": NAME), as it currently does for other cases where a name follows a number like "23cats". However, this is not quite what Python's parser does, which returns an error token instead. (Fortunately, name after number appears to be a syntax error everywhere, so it doesn't really affect the behaviour; a syntax error occurs either way.) ---------- nosy: +maltehelmert __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 17:58:53 2008 From: report at bugs.python.org (Malte Helmert) Date: Sat, 19 Jan 2008 16:58:53 -0000 Subject: [issue1679] tokenizer permits invalid hex integer In-Reply-To: <1198240546.79.0.598190279926.issue1679@psf.upfronthosting.co.za> Message-ID: <1200761933.56.0.113850214741.issue1679@psf.upfronthosting.co.za> Malte Helmert added the comment: Here's a patch that fixes case 1: >>> 0x File "", line 1 0x ^ SyntaxError: invalid token >>> 0xL File "", line 1 0xL ^ SyntaxError: invalid token Added file: http://bugs.python.org/file9221/PATCH-1.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 18:00:13 2008 From: report at bugs.python.org (Malte Helmert) Date: Sat, 19 Jan 2008 17:00:13 -0000 Subject: [issue1679] tokenizer permits invalid hex integer In-Reply-To: <1198240546.79.0.598190279926.issue1679@psf.upfronthosting.co.za> Message-ID: <1200762013.58.0.551851947315.issue1679@psf.upfronthosting.co.za> Malte Helmert added the comment: And here's a patch that fixes case 3. Added file: http://bugs.python.org/file9222/PATCH-3.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 18:15:30 2008 From: report at bugs.python.org (John Lenton) Date: Sat, 19 Jan 2008 17:15:30 -0000 Subject: [issue976880] mmap needs a rfind method Message-ID: <1200762930.49.0.603995298384.issue976880@psf.upfronthosting.co.za> John Lenton added the comment: New patch, with small change after being reviewed by amk. Still against revision 60082. Added file: http://bugs.python.org/file9223/mmap.rfind.patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 18:32:12 2008 From: report at bugs.python.org (Lorenzo Stoakes) Date: Sat, 19 Jan 2008 17:32:12 -0000 Subject: [issue1598083] Top-level exception handler writes to stdout unsafely Message-ID: <1200763932.12.0.840505875616.issue1598083@psf.upfronthosting.co.za> Lorenzo Stoakes added the comment: Ok, thankyou for your feedback, I will take another look at it. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 18:33:48 2008 From: report at bugs.python.org (Malte Helmert) Date: Sat, 19 Jan 2008 17:33:48 -0000 Subject: [issue1679] tokenizer permits invalid hex integer In-Reply-To: <1198240546.79.0.598190279926.issue1679@psf.upfronthosting.co.za> Message-ID: <1200764028.91.0.114848679526.issue1679@psf.upfronthosting.co.za> Malte Helmert added the comment: And here's a patch for case 2 (int) conversion. There is still a slight inconsistency in error reporting (base 0 vs. base 16) between int and long, but I'd see this as long's fault: >>> int("0x", 0) Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 0: '0x' >>> int("0x", 16) Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 16: '0x' >>> long("0x", 0) Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for long() with base 16: '0x' >>> long("0x", 16) Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for long() with base 16: '0x' The patch is not pretty because it duplicates a lot of code, but it's probably easier to see what was changed that way. I'll add a prettier patch soon. Added file: http://bugs.python.org/file9224/PATCH-2a.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 18:39:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 17:39:01 -0000 Subject: [issue1873] threading.Thread.join() description could be more explicit In-Reply-To: <1200760508.83.0.199534103582.issue1873@psf.upfronthosting.co.za> Message-ID: <1200764341.08.0.727739101769.issue1873@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed r60083. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 18:43:56 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 19 Jan 2008 17:43:56 -0000 Subject: [issue1868] threading.local doesn't free attrs when assigning thread exits In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za> Message-ID: <1200764636.87.0.475657662948.issue1868@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Here is a patch that removes the member localobject->dict. Now the dictionary is always retrieved from the thread state. Added file: http://bugs.python.org/file9225/threading_local.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 18:49:45 2008 From: report at bugs.python.org (Malte Helmert) Date: Sat, 19 Jan 2008 17:49:45 -0000 Subject: [issue1679] tokenizer permits invalid hex integer In-Reply-To: <1198240546.79.0.598190279926.issue1679@psf.upfronthosting.co.za> Message-ID: <1200764985.35.0.0661382328361.issue1679@psf.upfronthosting.co.za> Malte Helmert added the comment: This is a cleaner version of PATCH-2a.diff in the sense that the resulting code contains less duplication. The disadvantage is that it applies more structural changes to PyOS_strtoul, so may be harder to merge with other changes. Added file: http://bugs.python.org/file9226/PATCH-2b.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 18:54:18 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 17:54:18 -0000 Subject: [issue976880] mmap needs a rfind method Message-ID: <1200765258.04.0.667423706587.issue976880@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 19:02:58 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 18:02:58 -0000 Subject: [issue1782] PyModule_AddIntConstant and PyModule_AddStringConstant can leak In-Reply-To: <1199976472.88.0.939409341911.issue1782@psf.upfronthosting.co.za> Message-ID: <1200765778.12.0.251575810412.issue1782@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed in r60084. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 19:24:50 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 18:24:50 -0000 Subject: [issue976880] mmap needs a rfind method Message-ID: <1200767090.1.0.579075993518.issue976880@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Committed to the 2.6 trunk in rev. 60086. Thanks for your contribution! Please sign and send in a contributor form whenever you have time; the forms are at http://www.python.org/psf/contrib/ . ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 19:25:58 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 18:25:58 -0000 Subject: [issue976880] mmap needs a rfind method Message-ID: <1200767158.51.0.087180316382.issue976880@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +patch resolution: -> accepted status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 19:37:22 2008 From: report at bugs.python.org (Jonathan Share) Date: Sat, 19 Jan 2008 18:37:22 -0000 Subject: [issue1874] email parser does not register a defect for invalid Content-Transfer-Encoding on multipart messages In-Reply-To: <1200767841.97.0.882225337338.issue1874@psf.upfronthosting.co.za> Message-ID: <1200767841.97.0.882225337338.issue1874@psf.upfronthosting.co.za> New submission from Jonathan Share: Although the documentation of FeedParser states that "It will populate a message object's defects attribute with a list of any problems it found in a message." no defect is found in the test case I am about to upload. The message in the test case is broken because it specifies a Content-Transfer-Encoding that is not valid for multipart/* messages[1]. I've spent some time today looking at the parser and cannot see where the parser is doing anything with the Content-Transfer-Encoding of a multipart message, leading me to believe that there might be another bug here with regards to not honoring Content-Transfer-Encoding at all for multipart/* messages but I don't have any more time today to look at it, I'll have to go away and read the rfc really well. If someone can guide me on how to get this test to pass then I can probably get a good test case and fix written for issue1823 as well. [1] http://tools.ietf.org/html/rfc2045#section-6.4 ---------- components: Library (Lib) messages: 60207 nosy: Sharebear, barry severity: normal status: open title: email parser does not register a defect for invalid Content-Transfer-Encoding on multipart messages type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 19:38:16 2008 From: report at bugs.python.org (Jonathan Share) Date: Sat, 19 Jan 2008 18:38:16 -0000 Subject: [issue1874] email parser does not register a defect for invalid Content-Transfer-Encoding on multipart messages In-Reply-To: <1200767841.97.0.882225337338.issue1874@psf.upfronthosting.co.za> Message-ID: <1200767896.99.0.553107758101.issue1874@psf.upfronthosting.co.za> Changes by Jonathan Share: Added file: http://bugs.python.org/file9227/issue1874.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 19:41:00 2008 From: report at bugs.python.org (Jonathan Share) Date: Sat, 19 Jan 2008 18:41:00 -0000 Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za> Message-ID: <1200768060.32.0.169790862344.issue1823@psf.upfronthosting.co.za> Jonathan Share added the comment: Run out of time to look at this today. In order to write a nice test case for this issue I need the parser to notice this error in messages. I've filed issue1874 for the parser not reporting the invalid cte in the msg.defects __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 19:43:03 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Jan 2008 18:43:03 -0000 Subject: [issue1035] bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA In-Reply-To: <1188200568.98.0.237862868597.issue1035@psf.upfronthosting.co.za> Message-ID: <1200768183.17.0.724849877866.issue1035@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 19:46:01 2008 From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=) Date: Sat, 19 Jan 2008 18:46:01 -0000 Subject: [issue1779] int("- 1") is valud, but float("- 1") isn't. Which is right? In-Reply-To: <1199926803.21.0.243129638352.issue1779@psf.upfronthosting.co.za> Message-ID: <1200768361.27.0.880193291182.issue1779@psf.upfronthosting.co.za> Juan Jos? Conti added the comment: The same patch as before plus tests. Added file: http://bugs.python.org/file9228/bug_fix_for_1779-plustests.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 19:46:37 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 18:46:37 -0000 Subject: [issue1693149] patch to make 'trace.py --ignore-module' accept module name list. Message-ID: <1200768397.3.0.704062897845.issue1693149@psf.upfronthosting.co.za> Facundo Batista added the comment: Applied in r60087, with some change added in the help of the trace.py. Thank you! ---------- nosy: +facundobatista resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 19:52:19 2008 From: report at bugs.python.org (Malte Helmert) Date: Sat, 19 Jan 2008 18:52:19 -0000 Subject: [issue1679] tokenizer permits invalid hex integer In-Reply-To: <1198240546.79.0.598190279926.issue1679@psf.upfronthosting.co.za> Message-ID: <1200768739.46.0.477611261037.issue1679@psf.upfronthosting.co.za> Malte Helmert added the comment: Added tests to test_grammar, test_builtin and test_tokenize. Added file: http://bugs.python.org/file9229/PATCH-TESTS.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 19:53:27 2008 From: report at bugs.python.org (Ryan Freckleton) Date: Sat, 19 Jan 2008 18:53:27 -0000 Subject: [issue1411695] XML.sax.saxutils.escape -- always escapes <, >, &, Message-ID: <1200768807.4.0.164366664451.issue1411695@psf.upfronthosting.co.za> Ryan Freckleton added the comment: I've included a unified diff that explicitly states the behavior of &, <, and > for escape/unescape in the documentation. It's based on msandler's patch. ---------- nosy: +ryan.freckleton Added file: http://bugs.python.org/file9230/sax_utils_rst.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 19:54:12 2008 From: report at bugs.python.org (Ryan Freckleton) Date: Sat, 19 Jan 2008 18:54:12 -0000 Subject: [issue1411695] XML.sax.saxutils.escape -- always escapes <, >, &, Message-ID: <1200768852.75.0.870261511044.issue1411695@psf.upfronthosting.co.za> Changes by Ryan Freckleton: ---------- components: +Documentation versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 19:55:50 2008 From: report at bugs.python.org (Armin Rigo) Date: Sat, 19 Jan 2008 18:55:50 -0000 Subject: [issue1875] "if 0: return" not raising SyntaxError In-Reply-To: <1200768950.55.0.245752373825.issue1875@psf.upfronthosting.co.za> Message-ID: <1200768950.55.0.245752373825.issue1875@psf.upfronthosting.co.za> New submission from Armin Rigo: Can you guess why importing the attached x.py does nothing, without printing "hello" at all? The real issue shown in that example is that 'return' and 'yield' outside a function are ignored instead of giving a SyntaxError if they are optimized away by 'if 0:'. (Hint about x.py: the yield sets the CO_GENERATOR flag before it gets optimized away. So clearly, that's a way to comment out a whole module -- just put "if 0: yield" anywhere at top-level...) ---------- components: Interpreter Core files: x.py messages: 60213 nosy: arigo priority: low severity: minor status: open title: "if 0: return" not raising SyntaxError versions: Python 2.6 Added file: http://bugs.python.org/file9231/x.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 19:59:32 2008 From: report at bugs.python.org (Maciek Fijalkowski) Date: Sat, 19 Jan 2008 18:59:32 -0000 Subject: [issue1875] "if 0: return" not raising SyntaxError In-Reply-To: <1200768950.55.0.245752373825.issue1875@psf.upfronthosting.co.za> Message-ID: <1200769172.83.0.213876280132.issue1875@psf.upfronthosting.co.za> Changes by Maciek Fijalkowski: ---------- nosy: +cfbolz, fijal __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 20:00:05 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sat, 19 Jan 2008 19:00:05 -0000 Subject: [issue1862] Error on "Save As" in IDLE (Vista 32-bit) In-Reply-To: <1200602826.92.0.485453445525.issue1862@psf.upfronthosting.co.za> (Christian Heimes's message of "Thu, 17 Jan 2008 20:47:07 -0000") Message-ID: <87lk6lhc9d.fsf@hydra.hampton.thirdcreek.com> Kurt B. Kaiser added the comment: IDLE creates the .idlerc folder if needed. It seems it should be marked as not hidden. Does anyone know how to do that? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 20:13:08 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 19 Jan 2008 19:13:08 -0000 Subject: [issue1779] int("- 1") is valud, but float("- 1") isn't. Which is right? In-Reply-To: <1199926803.21.0.243129638352.issue1779@psf.upfronthosting.co.za> Message-ID: <1200769988.3.0.844171934303.issue1779@psf.upfronthosting.co.za> Facundo Batista added the comment: Fixed in r60090. Thanks Juanjo for your contribution! Please sign and send in a contributor form whenever you have time; the forms are at http://www.python.org/psf/contrib/ . ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 20:13:30 2008 From: report at bugs.python.org (Jaroslav Pachola) Date: Sat, 19 Jan 2008 19:13:30 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. In-Reply-To: <1196215842.85.0.855394455026.issue1509@psf.upfronthosting.co.za> Message-ID: <1200770010.52.0.527099805454.issue1509@psf.upfronthosting.co.za> Jaroslav Pachola added the comment: Attaching a patch that adds fetchXXX() description to the documentation for Python 2.6. ---------- nosy: +jarpa versions: +Python 2.6 Added file: http://bugs.python.org/file9232/sqlite3_docs_26.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 20:14:55 2008 From: report at bugs.python.org (Jaroslav Pachola) Date: Sat, 19 Jan 2008 19:14:55 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. In-Reply-To: <1196215842.85.0.855394455026.issue1509@psf.upfronthosting.co.za> Message-ID: <1200770095.23.0.120694632786.issue1509@psf.upfronthosting.co.za> Jaroslav Pachola added the comment: Attaching a patch that fixes the docstrings for Python 2.6. Added file: http://bugs.python.org/file9233/sqlite3_docstrings_26.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 20:28:32 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 19:28:32 -0000 Subject: [issue1679] tokenizer permits invalid hex integer In-Reply-To: <1198240546.79.0.598190279926.issue1679@psf.upfronthosting.co.za> Message-ID: <1200770912.38.0.810026946707.issue1679@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed patches 1, 2a and 3, and test suite updates, in r60092. This won't be backported to 2.5, and no doc changes are necessary. Thanks for your work! ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 20:29:47 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 19:29:47 -0000 Subject: [issue1679] tokenizer permits invalid hex integer In-Reply-To: <1198240546.79.0.598190279926.issue1679@psf.upfronthosting.co.za> Message-ID: <1200770987.67.0.093211714376.issue1679@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 20:32:02 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 19:32:02 -0000 Subject: [issue1298962] MSI installer does not pass values as SecureProperty from UI Message-ID: <1200771122.62.0.0966139494716.issue1298962@psf.upfronthosting.co.za> Georg Brandl added the comment: There seems to be a related log at #1565468. ---------- nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 20:40:28 2008 From: report at bugs.python.org (Jaroslav Pachola) Date: Sat, 19 Jan 2008 19:40:28 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. In-Reply-To: <1196215842.85.0.855394455026.issue1509@psf.upfronthosting.co.za> Message-ID: <1200771628.86.0.430039426668.issue1509@psf.upfronthosting.co.za> Jaroslav Pachola added the comment: Attaching a patch that fixes the docstrings for Python 2.5. Added file: http://bugs.python.org/file9234/sqlite3_docstrings_25.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 20:48:43 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 19:48:43 -0000 Subject: [issue1146] TextWrap vs words 1-character shorter than the width In-Reply-To: <1189517857.01.0.116632649875.issue1146@psf.upfronthosting.co.za> Message-ID: <1200772123.18.0.342137424767.issue1146@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the patches, committed in r60093! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 20:53:19 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 19 Jan 2008 19:53:19 -0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1200772399.76.0.66657943438.issue1657@psf.upfronthosting.co.za> Guido van Rossum added the comment: Still haven't had the time (sorry!), but one comment: please don't specify timeouts in millisecond. We use seconds (floats if necessary) everywhere else in Python, regardless of the underlying data structure or resolution. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 21:15:03 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 20:15:03 -0000 Subject: [issue1277] mailbox.Maildir: factory not used In-Reply-To: <1192377763.05.0.280093607923.issue1277@psf.upfronthosting.co.za> Message-ID: <1200773703.66.0.878561843511.issue1277@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I think the required patch is much simpler; only get_message() needs to be updated. I've committed this change to trunk as rev60095, and to release25-maint as rev. 60096. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 21:22:46 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 20:22:46 -0000 Subject: [issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi Message-ID: <1200774166.86.0.966439822567.issue1663329@psf.upfronthosting.co.za> Georg Brandl added the comment: Reviewed and committed patch as r60097. Thanks for your work! ---------- assignee: gvanrossum -> georg.brandl nosy: +georg.brandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 21:28:54 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 20:28:54 -0000 Subject: [issue1124] Webchecker not parsing css "@import url" In-Reply-To: <1189128543.92.0.989336234213.issue1124@psf.upfronthosting.co.za> Message-ID: <1200774534.9.0.428043275137.issue1124@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: pending -> open type: -> rfe versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 21:29:54 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 20:29:54 -0000 Subject: [issue683658] PyErr_Warn may cause import deadlock Message-ID: <1200774594.51.0.725903041187.issue683658@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: pending -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 19 21:34:25 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 20:34:25 -0000 Subject: [issue1687] plistlib.py restricts to Python int when writing In-Reply-To: <1198342894.97.0.416358225944.issue1687@psf.upfronthosting.co.za> Message-ID: <1200774865.72.0.0345123230589.issue1687@psf.upfronthosting.co.za> Georg Brandl added the comment: Backported in r60098. ---------- nosy: +georg.brandl resolution: remind -> fixed status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 21:35:37 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 20:35:37 -0000 Subject: [issue1700467] stack size of python_d.exe on VC6 Message-ID: <1200774937.18.0.30069262503.issue1700467@psf.upfronthosting.co.za> Georg Brandl added the comment: No response, closing. ---------- nosy: +georg.brandl status: pending -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 21:36:52 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 20:36:52 -0000 Subject: [issue1719423] Python package support not properly documented Message-ID: <1200775012.92.0.188623994828.issue1719423@psf.upfronthosting.co.za> Georg Brandl added the comment: Any progress on this? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 21:41:16 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 20:41:16 -0000 Subject: [issue1411695] XML.sax.saxutils.escape -- always escapes <, >, &, Message-ID: <1200775276.6.0.598375008587.issue1411695@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60099. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 21:44:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 20:44:39 -0000 Subject: [issue1867] patch for pydoc to work in py3k In-Reply-To: <1200685441.85.0.862976764101.issue1867@psf.upfronthosting.co.za> Message-ID: <1200775479.14.0.705254713272.issue1867@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60100. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 21:47:29 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Jan 2008 20:47:29 -0000 Subject: [issue1746071] class mutex doesn't do anything atomically Message-ID: <1200775649.3.0.153923057648.issue1746071@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Making the mutex module thread safe is a low hanging fruit for the bug day. But would it bring anything that the threading module doesn't have? ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 21:48:38 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 20:48:38 -0000 Subject: [issue1019808] wrong socket error returned Message-ID: <1200775718.76.0.458182077365.issue1019808@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Applied to 2.6 trunk in rev. 60101 (at long last!). Thanks for your patch! ---------- keywords: +patch resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 21:50:25 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 20:50:25 -0000 Subject: [issue1161031] Neverending warnings from asyncore Message-ID: <1200775825.46.0.349141282672.issue1161031@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: akuchling -> josiahcarlson _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 21:53:19 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 20:53:19 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. In-Reply-To: <1196215842.85.0.855394455026.issue1509@psf.upfronthosting.co.za> Message-ID: <1200775999.92.0.138941720619.issue1509@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60103. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 21:57:19 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 20:57:19 -0000 Subject: [issue1296] optparse's OptionGroup not described In-Reply-To: <1192722391.31.0.57718526952.issue1296@psf.upfronthosting.co.za> Message-ID: <1200776239.05.0.562542520422.issue1296@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 22:02:40 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 21:02:40 -0000 Subject: [issue1296] optparse's OptionGroup not described In-Reply-To: <1192722391.31.0.57718526952.issue1296@psf.upfronthosting.co.za> Message-ID: <1200776560.43.0.832340031818.issue1296@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Thanks for pointing this out. I've restored the text to the trunk in rev. 60106, and to the 2.5-maint branch in rev. 60107. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 22:05:15 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Jan 2008 21:05:15 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za> Message-ID: <1200776715.18.0.0944759658579.issue1336@psf.upfronthosting.co.za> Gregory P. Smith added the comment: fixed in trunk r60104. i'm backporting it to 2.5 and 2.4. ---------- resolution: -> fixed versions: +Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 22:59:16 2008 From: report at bugs.python.org (Jaroslav Pachola) Date: Sat, 19 Jan 2008 21:59:16 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. In-Reply-To: <1196215842.85.0.855394455026.issue1509@psf.upfronthosting.co.za> Message-ID: <1200779956.8.0.552820011431.issue1509@psf.upfronthosting.co.za> Jaroslav Pachola added the comment: Attaching a patch that adds fetchXXX() description to the documentation for Python 2.5. Added file: http://bugs.python.org/file9235/sqlite3_docs_25.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:00:10 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 22:00:10 -0000 Subject: [issue1625] bz2.BZ2File doesn't support multiple streams In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za> Message-ID: <1200780009.97.0.348382211776.issue1625@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Like gzip, you can concatenate two bzip2 files: bzip2 -c /etc/passwd >/tmp/pass.bz2 bzip2 -c /etc/passwd >>/tmp/pass.bz2 bunzip2 will output both parts, generating two copies of the file. So nothing needs to be done on compression, but uncompression needs to look for another chunk of compressed data after finishing one chunk. ---------- nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:00:33 2008 From: report at bugs.python.org (Jaroslav Pachola) Date: Sat, 19 Jan 2008 22:00:33 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. In-Reply-To: <1196215842.85.0.855394455026.issue1509@psf.upfronthosting.co.za> Message-ID: <1200780032.99.0.231619246605.issue1509@psf.upfronthosting.co.za> Jaroslav Pachola added the comment: BTW, the first 2 patches (for Python 2.6) work also on version 3.0a2 for me. ---------- versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:25:16 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Jan 2008 22:25:16 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za> Message-ID: <1200781516.46.0.76932915524.issue1336@psf.upfronthosting.co.za> Gregory P. Smith added the comment: r60111 undid part of r60104 that added an unnecessary else and indentation. svn diff -r60103:60111 of Lib/subprocess.py is a nice clean patch. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:35:27 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Jan 2008 22:35:27 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za> Message-ID: <1200782127.86.0.343647149146.issue1336@psf.upfronthosting.co.za> Gregory P. Smith added the comment: r60113 in release25-maint, r60114 in release24-maint. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:39:53 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Jan 2008 22:39:53 -0000 Subject: [issue1300] subprocess.list2cmdline doesn't do pipe symbols In-Reply-To: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za> Message-ID: <1200782393.88.0.400124475734.issue1300@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- assignee: -> gregory.p.smith keywords: +easy nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:42:13 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 22:42:13 -0000 Subject: [issue1751519] curses - new window methods: addchstr and addchnstr Message-ID: <1200782533.7.0.862926172249.issue1751519@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I'm doubtful about passing strings of characters that contain characters + attrs. The usual convention used by the curses module is to allow strings containing attributeless characters to display, or integers that can include an attribute value. Perhaps these functions can take an iterable containing either 1-character strings or integers, and assemble them into a C-level array. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 23:47:13 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 19 Jan 2008 22:47:13 -0000 Subject: [issue1659] Tests needing network flag? In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org> Message-ID: <1200782833.13.0.836069132298.issue1659@psf.upfronthosting.co.za> Skip Montanaro added the comment: This is an easy patch, but I'd like someone to at least verify it works before checking it in... nudge, nudge, wink, wink... ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:49:56 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Jan 2008 22:49:56 -0000 Subject: [issue1300] subprocess.list2cmdline doesn't do pipe symbols In-Reply-To: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za> Message-ID: <1200782996.13.0.32478864047.issue1300@psf.upfronthosting.co.za> Gregory P. Smith added the comment: fixed in trunk r60115 (2.6). ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:50:50 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 22:50:50 -0000 Subject: [issue1659] Tests needing network flag? In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org> Message-ID: <1200783050.79.0.761818646358.issue1659@psf.upfronthosting.co.za> Georg Brandl added the comment: This won't work without corresponding changes in regrtest.py; it currently mentions test_socket_ssl and test_timeout explicitly. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:54:46 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 22:54:46 -0000 Subject: [issue1689] Backport PEP 3141 to 2.6 In-Reply-To: <1198375234.59.0.21975095893.issue1689@psf.upfronthosting.co.za> Message-ID: <1200783286.77.0.254023084411.issue1689@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> accepted status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:55:21 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 19 Jan 2008 22:55:21 -0000 Subject: [issue1048820] Only "Overwrite" mode possible with curses.textpad.Textbox Message-ID: <1200783321.98.0.029204236509.issue1048820@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +patch title: Only "Overwrite" mode possible with curses.textpad.Textbox -> Only "Overwrite" mode possible with curses.textpad.Textbox _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 19 23:57:43 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 22:57:43 -0000 Subject: [issue1738] filecmp.dircmp does exact match only In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za> Message-ID: <1200783463.5.0.224360952105.issue1738@psf.upfronthosting.co.za> Changes by Georg Brandl: Removed file: http://bugs.python.org/file9067/filecmp.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 19 23:58:42 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 22:58:42 -0000 Subject: [issue683910] zipfile should have a tarfile-like API Message-ID: <1200783522.39.0.221194177268.issue683910@psf.upfronthosting.co.za> Georg Brandl added the comment: Said patch has now been applied. ---------- assignee: anthonybaxter -> nosy: +georg.brandl resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 00:01:55 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 23:01:55 -0000 Subject: [issue487738] weaklist Message-ID: <1200783715.61.0.954282842202.issue487738@psf.upfronthosting.co.za> Georg Brandl added the comment: Also we already have a WeakSet now since the abc module needs it. ---------- nosy: +georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 00:15:58 2008 From: report at bugs.python.org (Ismail Donmez) Date: Sat, 19 Jan 2008 23:15:58 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200784558.05.0.702870871097.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: I created a git repo for my fixes over http://repo.or.cz/w/pytest.git?a=shortlog;h=overflow-fix . Now as tiran suggested I fix one file and make sure nothing regressed. But! Feel free to beat me to it and fix this. I am all new to this and progress might be and possibly be slow. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 00:16:16 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Jan 2008 23:16:16 -0000 Subject: [issue1189216] zipfile module and 2G boundary Message-ID: <1200784576.44.0.25345443832.issue1189216@psf.upfronthosting.co.za> Gregory P. Smith added the comment: fixed in trunk r60116 (2.6). and release25-maint r60117 (2.5.2). ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 00:39:57 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Jan 2008 23:39:57 -0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) In-Reply-To: <1188423295.47.0.201015368946.issue1060@psf.upfronthosting.co.za> Message-ID: <1200785996.99.0.160797525711.issue1060@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The issue here was that reading more data than will fit into an in memory string fails. While the zipfile module could detect this in some cases, it is not really worth such a runtime check. This is just a fact of python and of sane programming, if you're reading data from a file like object you should never use unbounded reads without having checked your input for sanity first. ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 00:40:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Jan 2008 23:40:39 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200786039.73.0.161697442555.issue1826@psf.upfronthosting.co.za> Georg Brandl added the comment: Attaching another patch that doesn't create a list of strings every time the attrgetter is called. Also includes docs. ---------- nosy: +georg.brandl Added file: http://bugs.python.org/file9236/attrgetter-2.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 00:41:24 2008 From: report at bugs.python.org (Johann Tonsing) Date: Sat, 19 Jan 2008 23:41:24 -0000 Subject: [issue1401] urllib2 302 POST In-Reply-To: <1194471779.09.0.301126280852.issue1401@psf.upfronthosting.co.za> Message-ID: <1200786084.8.0.54320753544.issue1401@psf.upfronthosting.co.za> Changes by Johann Tonsing: ---------- nosy: +jtonsing __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 00:51:08 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Jan 2008 23:51:08 -0000 Subject: [issue1003] zipfile password fails validation In-Reply-To: <1187902396.85.0.749832175087.issue1003@psf.upfronthosting.co.za> Message-ID: <1200786668.12.0.936988457869.issue1003@psf.upfronthosting.co.za> Gregory P. Smith added the comment: this failure also occurs on simple zip files created using infozip's zip with -e to "encrypt" the contents. debugging... __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 01:02:35 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 20 Jan 2008 00:02:35 -0000 Subject: [issue1048820] Only "Overwrite" mode possible with curses.textpad.Textbox Message-ID: <1200787355.48.0.648446214795.issue1048820@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Applied to the trunk in rev. 60119. Thanks for your patch! Please remember to sign and send in a contributor form; the forms are available at http://www.python.org/psf/contrib/ ---------- resolution: -> accepted status: open -> closed versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 02:16:23 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 20 Jan 2008 01:16:23 -0000 Subject: [issue777884] minidom.py -- TypeError: object doesn't support slice assig Message-ID: <1200791783.24.0.0689292172463.issue777884@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: fdrake -> akuchling ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 02:26:12 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 20 Jan 2008 01:26:12 -0000 Subject: [issue1003] zipfile password fails validation In-Reply-To: <1187902396.85.0.749832175087.issue1003@psf.upfronthosting.co.za> Message-ID: <1200792372.29.0.428059775719.issue1003@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Fixed in r60121 (2.6). zip file decryption "check" bytes were more complicated than the existing code supported. Algorithm updated. ---------- resolution: -> fixed status: open -> closed versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 02:42:56 2008 From: report at bugs.python.org (Steven Downum) Date: Sun, 20 Jan 2008 01:42:56 -0000 Subject: [issue1627] Problem with httplib and Content-Length: -1 In-Reply-To: <1197636721.61.0.0455165758222.issue1627@psf.upfronthosting.co.za> Message-ID: <1200793376.72.0.0986795186676.issue1627@psf.upfronthosting.co.za> Steven Downum added the comment: I have made a patch of the proposed fixed and ran the httplib test afterwards, to make sure it passed. ---------- nosy: +sdownum Added file: http://bugs.python.org/file9237/1626_patch.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 02:48:16 2008 From: report at bugs.python.org (Ismail Donmez) Date: Sun, 20 Jan 2008 01:48:16 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200793696.72.0.273626421038.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: With second patch now python builds without any overflow warnings, no new regressions. Please test and/or review. Only thing left is fixing Modules subdirectory. Thanks. Added file: http://bugs.python.org/file9238/fix-overflows-try2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 02:51:26 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 20 Jan 2008 01:51:26 -0000 Subject: [issue705836] struct.pack of floats in non-native endian order Message-ID: <1200793886.43.0.206087211754.issue705836@psf.upfronthosting.co.za> Mark Dickinson added the comment: It's a little odd: the relevant code is in floatobject.c, in _PyFloat_Pack4. The issue is what happens when a Python float (stored internally as a platform double) is packed as an IEEE-754 single-precision float. The current code doesn't behave consistently across platforms: - if the platform float format is unknown, the code turns a Python float into an IEEE-754 float anyway, and goes to great lengths to raise OverflowError when the Python float is too large to fit into an IEEE single-precision float. - if the platform float format is recognised as IEEE-754, then a C cast is used to turn the Python float (stored as a double) into a single-precision float; for something that's too large for single precision, the natural result of that conversion is an IEEE-754 infinity. I'm not 100% sure that the C standard (even C99) actually guarantees this, or whether there's a danger of floating-point exceptions being raised here. I think the behaviour should be consistent: either always raise OverflowError or always return the 4-byte sequence corresponding to an infinity. I'm not sure which. From the test-suite, it's clear that the original intention was that OverflowError should be raised. On the other hand, 98.22% of Python users (i.e. those on IEEE-754 platforms) have been living happily with the 'output an infinity' behaviour for the last 5 years without noticing. And we've been moving towards exposing infinities and NaNs more within Python. One the OverflowError/infinity decision is made, this is a relatively easy fix, and I'd be happy to take care of it. Christian, do you have any thoughts on this issue? ---------- nosy: +marketdickinson, tiran ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 03:07:50 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 20 Jan 2008 02:07:50 -0000 Subject: [issue705836] struct.pack of floats in non-native endian order Message-ID: <1200794870.09.0.785593857315.issue705836@psf.upfronthosting.co.za> Mark Dickinson added the comment: Aha: the C99 standard, section 6.3.1.5, says: When a double is demoted to float, a long double is demoted to double or float, or a value being represented in greater precision and range than required by its semantic type (see 6.3.1.8) is explicitly converted to its semantic type [...] if the value being converted is outside the range of values that can be represented, the behavior is undefined. So the current code likely has different behaviours even on different IEEE-754 platforms. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 03:12:08 2008 From: report at bugs.python.org (George Castillo) Date: Sun, 20 Jan 2008 02:12:08 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200795128.36.0.948184352527.issue1640@psf.upfronthosting.co.za> George Castillo added the comment: Is there still interest in implementing the inverse hyperbolic trig functions for real numbers? I would be willing to explore this if there is. ---------- nosy: +gmcastil __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 03:31:50 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 20 Jan 2008 02:31:50 -0000 Subject: [issue1659] Tests needing network flag? In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org> Message-ID: <1200796310.33.0.207680449974.issue1659@psf.upfronthosting.co.za> Skip Montanaro added the comment: > it currently mentions test_socket_ssl and test_timeout explicitly "it" being regrtest.py? This patch works for me. In what way is regrtest's reference to test_socket_ssl (for example) a problem? All I did for that test was tighten up the requirements to run the test. I didn't do anything with test_timeout. It's unclear to me why you mentioned it. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 04:07:17 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 20 Jan 2008 03:07:17 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200798437.06.0.116299628375.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: George: I'm certainly still interested in having asinh, acosh and atanh in math---I'm not sure about anyone else, but I consider these three functions to be basic ingredients in any math library. They even appear in most calculus texts. And the complex versions are already in cmath. The right thing to do would be to wrap the libm functions when they exist, but provide fallbacks for the platforms where they don't. I think these functions are present on OS X and in the GNU libm, but they might be missing on Windows. There's a fallback version of asinh already provided in the patch to issue #1381, which I believe to be reasonably sound (but since I wrote it, a second opinion would be good). For acosh and atanh, you'd have to find the right way to deal with domain errors (e.g. acosh(0.5), atanh(2.0)) and singularities (atanh(1.0), atanh(-1.0)). I'd suggest trying to follow the details in Appendix F (section F.9.2) of the C99 standard where possible. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 04:29:13 2008 From: report at bugs.python.org (Ismail Donmez) Date: Sun, 20 Jan 2008 03:29:13 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200799753.61.0.393278993291.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Possibly last one before final patch, only Modules/_sre.c left to fix, I appreciate help on that. Please ignore tab problems, I think that can be fixed later on. Thanks. Added file: http://bugs.python.org/file9239/fix-overflows-try3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 06:07:45 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Sun, 20 Jan 2008 05:07:45 -0000 Subject: [issue1183712] package_data chops off first char of default package Message-ID: <1200805665.11.0.317132065128.issue1183712@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Closing this as the required code change is committed (as part of #1720897). ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 06:10:51 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 20 Jan 2008 05:10:51 -0000 Subject: [issue705836] struct.pack of floats in non-native endian order Message-ID: <1200805851.1.0.932257164449.issue705836@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a patch that fixes the test that Collin mentioned to reflect what's actually been happening for the last nearly 5 years, and changes _PyFloat_Pack4 and _PyFloat_Pack8, as follows. When packing a float that's too large for the destination format (e.g. pack(">f", 1e39)): - before the patch, _PyFloat_Pack* gives an OverflowError on non-IEEE-754 platforms and an IEEE infinity on IEEE-754 platforms. - after the patch, _PyFloat_Pack* gives an IEEE infinity on all platforms. This patch doesn't fix the problem that the cast from double to float on IEEE machines involves potentially undefined behaviour; I think that should be considered a separate issue. Added file: http://bugs.python.org/file9240/705836.patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 09:44:26 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 08:44:26 -0000 Subject: [issue1659] Tests needing network flag? In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org> Message-ID: <1200818665.97.0.501780340836.issue1659@psf.upfronthosting.co.za> Georg Brandl added the comment: Sorry, I was being unclear. I grepped through Lib/test for "skip_expected" and couldn't find a location where e.g. the newly set test_urllib2.skip_expected would be accessed. regrtest.py only accesses this attribute on the two modules I named. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 09:57:09 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 08:57:09 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200819429.01.0.469826512668.issue1640@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm +1 in adding fallbacks for important functions like copysign, asinh, acosh and atanh. expm1 and log1p may be worth adding, too. Windows doesn't have any of the functions except of _copysign(). But why write our own version if we can reuse existing implementations? I found a set of very well written and documented implementations in the uclibc sources of libm. The sources are under a BSDish license: * ==================================================== * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. * * Developed at SunPro, a Sun Microsystems, Inc. business. * Permission to use, copy, modify, and distribute this * software is freely granted, provided that this notice * is preserved. * ==================================================== In #1381 I suggested two new files Python/pymath.c and Include/pymath.h. We could stick all the replacement implementations in the files and maybe move some of the code from Include/pyport.h and Python/hypot.c to the new files. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 09:57:23 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 08:57:23 -0000 Subject: [issue705836] struct.pack of floats in non-native endian order Message-ID: <1200819443.55.0.0212512893037.issue705836@psf.upfronthosting.co.za> Christian Heimes added the comment: Sounds like a good idea to me. Although all major platforms support IEEE Python should guarantee a stable behavior on all platforms. The lines should be a safe replacement of the downcast: double fromd; float tof; tof = abs(fromd) >= FLT_MAX ? FLT_MAX : fromd; tof = (float)copysign((double)tof, fromd); By the way the release notes of Python should mention the our work on better IEEE-754 and numeric support in bold letters. "Python 2.6 - now with even better support for professional math in the core". It's a good advertisement. :) ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 10:01:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 09:01:51 -0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1200819711.26.0.24486102868.issue1657@psf.upfronthosting.co.za> Christian Heimes added the comment: Yeah, it's a reasonable suggestion. I'm changing the code to seconds as positive float and None = blocking. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 10:08:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 09:08:52 -0000 Subject: [issue1659] Tests needing network flag? In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org> Message-ID: <1200820132.74.0.0785855519964.issue1659@psf.upfronthosting.co.za> Christian Heimes added the comment: I've disabled a single test in socket if the network resource isn't enable. It fixes the problem for me when I'm offline or my WLAN is broken again. The test was also called by test_ssl. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 10:12:39 2008 From: report at bugs.python.org (Thomas Herve) Date: Sun, 20 Jan 2008 09:12:39 -0000 Subject: [issue1625] bz2.BZ2File doesn't support multiple streams In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za> Message-ID: <1200820359.84.0.649626478744.issue1625@psf.upfronthosting.co.za> Thomas Herve added the comment: The gzip module supports reopening an existing file to add another stream. I think the bz2 module should not the same. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 11:16:46 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 10:16:46 -0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1200824206.48.0.913322334696.issue1657@psf.upfronthosting.co.za> Changes by Christian Heimes: Added file: http://bugs.python.org/file9241/trunk_select_epoll_kqueue8.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 12:13:45 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 11:13:45 -0000 Subject: [issue1351692] Switch to make pprint.pprint display ints and longs in hex Message-ID: <1200827625.08.0.0154829117582.issue1351692@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed to trunk in r60131. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 12:18:09 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 11:18:09 -0000 Subject: [issue1473257] Add a gi_code attr to generators Message-ID: <1200827889.77.0.723062369495.issue1473257@psf.upfronthosting.co.za> Georg Brandl added the comment: Guido, do you have an opinion? Seems like a nonproblematic and probably useful change for 2.6. ---------- assignee: pje -> gvanrossum nosy: +gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 12:34:37 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 11:34:37 -0000 Subject: [issue1449471] Splitting CJK codecs from pythoncore dll Message-ID: <1200828877.77.0.151801224463.issue1449471@psf.upfronthosting.co.za> Georg Brandl added the comment: Another year has passed; closing this. ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 12:37:00 2008 From: report at bugs.python.org (Ismail Donmez) Date: Sun, 20 Jan 2008 11:37:00 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200829020.44.0.674928379316.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Final patch should be complete. Used a trick in _sre.c, instead of i < 0 , I used i + i < i to trick gcc. Added file: http://bugs.python.org/file9242/fix-overflows-final.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 12:43:18 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 11:43:18 -0000 Subject: [issue1178141] urllib.py overwrite HTTPError code with 200 Message-ID: <1200829398.17.0.103031541483.issue1178141@psf.upfronthosting.co.za> Georg Brandl added the comment: The bug (interpreting non-200 2xx codes as error) has already been fixed. I've finished and committed the other part (adding getcode() to addinfourl) in r60133. ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 12:45:15 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 11:45:15 -0000 Subject: [issue1117751] urllib.urlopen should put the http-error-code in .info() Message-ID: <1200829515.35.0.203602069309.issue1117751@psf.upfronthosting.co.za> Georg Brandl added the comment: For #1178141 I added f.getcode() in r60133. ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 13:06:03 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:06:03 -0000 Subject: [issue856047] urllib.py does not use "no_proxy"; Message-ID: <1200830763.19.0.127012507452.issue856047@psf.upfronthosting.co.za> Georg Brandl added the comment: Added docs and committed as r60134. Thanks for your patch! ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 13:11:28 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:11:28 -0000 Subject: [issue1731720] urllib.urlretrieve/URLopener.retrieve - 'buff' argument Message-ID: <1200831088.66.0.645817285764.issue1731720@psf.upfronthosting.co.za> Georg Brandl added the comment: Why don't you use open() and transfer the data between file objects yourself? The point of retrieve() is to create a local file containing the data. Closing as "won't fix". ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 13:18:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:18:40 -0000 Subject: [issue1664522] Fix for urllib.ftpwrapper.retrfile() and none existing files Message-ID: <1200831520.37.0.0940126823581.issue1664522@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed patch (added an additional try-finally) as r60135. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 13:21:12 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:21:12 -0000 Subject: [issue735515] urllib / urllib2 should cache 301 redirections Message-ID: <1200831672.91.0.250451836482.issue735515@psf.upfronthosting.co.za> Georg Brandl added the comment: John, what did you have in mind? ---------- nosy: +georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 13:23:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:23:08 -0000 Subject: [issue1197207] Add proxies arg to urllib.urlretrieve Message-ID: <1200831788.81.0.569354410069.issue1197207@psf.upfronthosting.co.za> Georg Brandl added the comment: Waiting for diff from OP, setting to Pending. ---------- nosy: +georg.brandl status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 13:28:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:28:08 -0000 Subject: [issue614557] LookupError etc. need API to get the key Message-ID: <1200832088.59.0.896613312826.issue614557@psf.upfronthosting.co.za> Georg Brandl added the comment: Will this be revisited for py3k? ---------- nosy: +georg.brandl versions: +Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 13:29:25 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:29:25 -0000 Subject: [issue487566] smart module import Message-ID: <1200832165.62.0.359311238021.issue487566@psf.upfronthosting.co.za> Georg Brandl added the comment: Chris, is this something that could be done with your post-import hooks? ---------- assignee: -> tiran nosy: +georg.brandl, tiran ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 13:32:26 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:32:26 -0000 Subject: [issue460474] codecs.StreamWriter: reset() on close() Message-ID: <1200832346.47.0.485267061113.issue460474@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> lemburg nosy: +lemburg ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 13:33:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:33:39 -0000 Subject: [issue592703] HTTPS does not handle pipelined requests Message-ID: <1200832419.1.0.244338083424.issue592703@psf.upfronthosting.co.za> Georg Brandl added the comment: SSL support was rewritten, so this may be fixed now... ---------- assignee: jhylton -> janssen nosy: +georg.brandl, janssen ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 13:42:47 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:42:47 -0000 Subject: [issue771334] pydoc.TextDoc raises for some kinds of objects Message-ID: <1200832967.92.0.0680481209731.issue771334@psf.upfronthosting.co.za> Georg Brandl added the comment: docother() was fixed in r39636 to accept the additional argument. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 13:44:23 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:44:23 -0000 Subject: [issue771479] pyconfig.h duplicates common defines Message-ID: <1200833063.26.0.0737353934829.issue771479@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> loewis nosy: +loewis ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 13:55:00 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2008 12:55:00 -0000 Subject: [issue1034053] unittest.py patch: add skipped test functionality Message-ID: <1200833700.95.0.0931149285818.issue1034053@psf.upfronthosting.co.za> Antoine Pitrou added the comment: So what's the status of this? Skipping test is still an important ability to have. ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 13:57:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 12:57:53 -0000 Subject: [issue799369] documentation for sys.platform is unclear Message-ID: <1200833873.48.0.807768322543.issue799369@psf.upfronthosting.co.za> Georg Brandl added the comment: Implemented the suggestions in r60136. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 14:01:07 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 13:01:07 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1200829020.44.0.674928379316.issue1621@psf.upfronthosting.co.za> Message-ID: <4793460D.70607@cheimes.de> Christian Heimes added the comment: Ismail Donmez wrote: > Ismail Donmez added the comment: > > Final patch should be complete. Used a trick in _sre.c, instead of i < 0 > , I used > i + i < i to trick gcc. I'm going to review your patch later. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 14:08:46 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 13:08:46 -0000 Subject: [issue652749] extra __builtin__ stuff not documented Message-ID: <1200834526.74.0.918911947353.issue652749@psf.upfronthosting.co.za> Georg Brandl added the comment: Documented in r60137. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 14:24:01 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 20 Jan 2008 13:24:01 -0000 Subject: [issue460474] codecs.StreamWriter: reset() on close() Message-ID: <1200835441.89.0.734758208259.issue460474@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Sounds reasonable. Could you come up with a patch ? Thanks. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 14:54:50 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 13:54:50 -0000 Subject: [issue546558] Windows getpass bug Message-ID: <1200837290.44.0.912441380874.issue546558@psf.upfronthosting.co.za> Georg Brandl added the comment: So it seems to be fixed in NT -- we don't support 9x anymore in 2.6 up. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 14:56:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 13:56:10 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1200829020.44.0.674928379316.issue1621@psf.upfronthosting.co.za> Message-ID: <47935293.7010306@cheimes.de> Christian Heimes added the comment: Ismail Donmez wrote: > Final patch should be complete. Used a trick in _sre.c, instead of i < 0 > , I used > i + i < i to trick gcc. > > Added file: http://bugs.python.org/file9242/fix-overflows-final.patch Does the C89 standard allow this code? int q = 1; int p = (unsigned)q; I've never seen an unsigned cast without a type. Does the code compile with gcc -std=C89? Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 14:56:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 13:56:47 -0000 Subject: [issue487566] smart module import Message-ID: <1200837407.38.0.644300124574.issue487566@psf.upfronthosting.co.za> Christian Heimes added the comment: It is possible to re-use post import hooks for the purpose but really, this is a job for PEP 3124 "Overloading, Generic Functions, Interfaces, and Adaptation". ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 14:59:58 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 13:59:58 -0000 Subject: [issue1648] add new function, sys.gettrace In-Reply-To: <1197962206.78.0.66019854769.issue1648@psf.upfronthosting.co.za> Message-ID: <1200837598.46.0.924814374383.issue1648@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed as r60138. Thanks for the complete patch! ---------- assignee: brett.cannon -> georg.brandl nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 15:07:49 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sun, 20 Jan 2008 14:07:49 -0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1200838069.16.0.575007445798.issue1700463@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Rev59716 required some fix. I'm not sure the patch for Lib/socket.py is apropriate. Added file: http://bugs.python.org/file9244/vc6-trunk-ver5.zip _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 15:11:19 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 14:11:19 -0000 Subject: [issue487566] smart module import Message-ID: <1200838279.81.0.45833432654.issue487566@psf.upfronthosting.co.za> Georg Brandl added the comment: I agree. In any case, this issue will be handled by one of the PEPs. ---------- resolution: -> later status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 15:14:32 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2008 14:14:32 -0000 Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za> Message-ID: <1200838472.01.0.446373332337.issue1826@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FWIW, Georg's patch works here. Perhaps there should be a test for unicode attribute names since it is special-cased in the patch. ---------- nosy: +pitrou __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 15:16:32 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2008 14:16:32 -0000 Subject: [issue1876] bogus attrgetter test in test_operator In-Reply-To: <1200838592.82.0.0545990493887.issue1876@psf.upfronthosting.co.za> Message-ID: <1200838592.82.0.0545990493887.issue1876@psf.upfronthosting.co.za> New submission from Antoine Pitrou: In test_operator we find the following lines: class C(object): def __getattr(self, name): raise SyntaxError self.failUnlessRaises(AttributeError, operator.attrgetter('foo'), C()) Obviously "__getattr" has no effect. However, when changing it to "__getattr__", the test fails. Is there is any motivation for this test in the first place? If yes, why the typo and why the error when the typo is corrected? ---------- components: Tests messages: 61297 nosy: pitrou severity: normal status: open title: bogus attrgetter test in test_operator type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 15:18:26 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 14:18:26 -0000 Subject: [issue1669] shutil.rmtree fails on symlink, after deleting contents In-Reply-To: <1198140802.03.0.559721880432.issue1669@psf.upfronthosting.co.za> Message-ID: <1200838706.09.0.322764923619.issue1669@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed a variant of the last patch in r60139; it now raises OSError like all other functions that are used in rmtree(). Added docs and tests. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 15:22:14 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 14:22:14 -0000 Subject: [issue1647] IDLE messes around with sys.exitfunc In-Reply-To: <1197948552.45.0.790109797324.issue1647@psf.upfronthosting.co.za> Message-ID: <1200838934.85.0.167799833734.issue1647@psf.upfronthosting.co.za> Georg Brandl added the comment: Should be no problem then. ---------- nosy: +georg.brandl resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 15:27:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 14:27:53 -0000 Subject: [issue1652] subprocess should have an option to restore SIGPIPE to default action In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za> Message-ID: <1200839273.83.0.67700970248.issue1652@psf.upfronthosting.co.za> Georg Brandl added the comment: Raising priority. What incompatibilities could occur if SIGPIPE is restored by default? ---------- nosy: +georg.brandl priority: -> high severity: normal -> major type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 15:32:32 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 14:32:32 -0000 Subject: [issue1876] bogus attrgetter test in test_operator In-Reply-To: <1200838592.82.0.0545990493887.issue1876@psf.upfronthosting.co.za> Message-ID: <1200839552.4.0.231169157838.issue1876@psf.upfronthosting.co.za> Georg Brandl added the comment: As seen from the __eq__ example, the exception should be SyntaxError. With both changes, it works fine again in r60142. As for why the test is there, maybe the operator functions had lax error checking once. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 15:41:01 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 14:41:01 -0000 Subject: [issue1389051] imaplib causes excessive fragmentation for large documents Message-ID: <1200840061.31.0.700921031812.issue1389051@psf.upfronthosting.co.za> Christian Heimes added the comment: I read your posting on the python general list. Eeeeh! That's awful. ---------- keywords: +easy nosy: +tiran priority: normal -> high type: -> behavior versions: +Python 2.5, Python 2.6 -Python 2.4 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 15:48:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 14:48:08 -0000 Subject: [issue1877] unhelpful error when calling "python " In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za> Message-ID: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za> New submission from Georg Brandl: gbr at lap ~/devel/python> ./python Lib Traceback (most recent call last): File "Lib/runpy.py", line 99, in _run_module_as_main loader, code, fname = _get_module_details(mod_name) File "Lib/runpy.py", line 86, in _get_module_details raise ImportError("No code object available for %s" % mod_name) ImportError: No code object available for __main__ ---------- assignee: ncoghlan messages: 61303 nosy: georg.brandl, ncoghlan severity: normal status: open title: unhelpful error when calling "python " __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 15:49:37 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 14:49:37 -0000 Subject: [issue1877] unhelpful error when calling "python " In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za> Message-ID: <1200840577.81.0.138576253423.issue1877@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Library (Lib) keywords: +easy priority: -> normal type: -> behavior versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 15:50:35 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 14:50:35 -0000 Subject: [issue1087735] mmap instance method access bug Message-ID: <1200840635.62.0.836693579575.issue1087735@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60143 by switching the mmap object's getattr function to the standard PyObject_GenericGetAttr(). ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 16:16:17 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 15:16:17 -0000 Subject: [issue1506171] Add "methodcaller" to the operator module Message-ID: <1200842176.98.0.955714821097.issue1506171@psf.upfronthosting.co.za> Georg Brandl added the comment: Attaching patch against SVN trunk. ---------- assignee: -> rhettinger nosy: +georg.brandl resolution: rejected -> Added file: http://bugs.python.org/file9245/methodcaller.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 16:17:48 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 20 Jan 2008 15:17:48 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200842268.68.0.742763967143.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Excellent! I'll take a look. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 16:42:28 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2008 15:42:28 -0000 Subject: [issue1715] Make pydoc list submodules In-Reply-To: <1199145132.63.0.00647784499418.issue1715@psf.upfronthosting.co.za> Message-ID: <1200843748.94.0.971956835516.issue1715@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This should be a better patch, although it only applies to the text formatter of pydoc, not the HTML one (I'm too lazy for this :-)). ---------- nosy: +pitrou Added file: http://bugs.python.org/file9246/pydocsubmodules.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 17:11:37 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 20 Jan 2008 16:11:37 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200845497.42.0.693264014775.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: One question: is there a policy on what should happen for singularities and domain errors? If not, I think it would be useful to have one. Following the policy may not be achievable on all platforms, but it should be easy to do on major platforms, and at least we'll know what we're aiming for in general. Maybe it already exists, and I missed it :) For domain errors (e.g. sqrt(-1), log(-1), acosh(0)), the obvious two options are: - raise an exception (e.g. OverflowError), or - return a NaN For singularities (e.g. log(0), atanh(1)), the options are basically the same: - raise an exception (preferably something different from OverflowError), or - return the IEEE-754 recommended value (usually +/-Inf) I suspect there are use-cases for both types of behaviour here. Of course, the *right* thing to do, in some sense, would be to have a thread-local floating-point environment that makes it possible for the user to choose whether he/she wants an exception or a special value, much like the way Decimal behaves at the moment. But that would be a big change, almost certainly requiring a PEP and a lot of work. A few months ago I definitely would have said that an exception should be raised in both cases, as already happens (mostly); but since then NaNs and Infinities have acquired greater legitimacy within Python. Tim, if you're listening: any words of wisdom? Should I ask this on python-dev? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 17:33:28 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 20 Jan 2008 16:33:28 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200846808.16.0.614126845603.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: whoops. OverflowError should be something else in the previous post; of course, OverflowError is inappropriate for domain errors (but entirely appropriate for something like exp(1000)). Currently, on Linux I get: - overflow (exp(1000)) -> OverflowError - domain error (sqrt(-1)) -> ValueError - singularity (log(0)) -> OverflowError On OS X I get: - overflow -> OverflowError - domain error -> NaN - singularity -> OverflowError __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 17:53:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 16:53:31 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1200846808.16.0.614126845603.issue1640@psf.upfronthosting.co.za> Message-ID: <47937C88.2040902@cheimes.de> Christian Heimes added the comment: Mark Dickinson wrote: > Currently, on Linux I get: > - overflow (exp(1000)) -> OverflowError > - domain error (sqrt(-1)) -> ValueError > - singularity (log(0)) -> OverflowError Windows raises the same exceptions as Linux. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 18:09:37 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 20 Jan 2008 17:09:37 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200848977.67.0.798149640776.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Okay: for now, I guess we just follow the pattern that already exists on Linux and Windows. I think the OS X sqrt(-1) behaviour is a bug. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 18:29:08 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2008 17:29:08 -0000 Subject: [issue1615] descriptor protocol bug In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za> Message-ID: <1200850148.09.0.827845504318.issue1615@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I can confirm that with SVN trunk, and it's actually even worse because it can return unexpected results without raising an exception at all: >>> class Foo(object): ... def __getattr__(self, name): return 42 ... @property ... def bacon(self): return int.lalala ... >>> f = Foo() >>> f.bacon 42 >>> Foo.bacon.__get__(f) Traceback (most recent call last): File "", line 1, in File "", line 4, in bacon AttributeError: type object 'int' has no attribute 'lalala' ---------- nosy: +pitrou severity: normal -> major __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 18:32:43 2008 From: report at bugs.python.org (John J Lee) Date: Sun, 20 Jan 2008 17:32:43 -0000 Subject: [issue735515] urllib / urllib2 should cache 301 redirections Message-ID: <1200850363.36.0.868945867482.issue735515@psf.upfronthosting.co.za> John J Lee added the comment: In what respect? I just meant that it would be nice (and more compliant with the RFC) if rather than fetching the original URL each time, a map of URLs to 301-redirected URLs was kept. For urllib2, I suppose the map would be a private attribute of HTTPRedirectHandler. There's no obvious need to provide any interface to get the intermediate URLs in the redirection chain. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 18:39:58 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 20 Jan 2008 17:39:58 -0000 Subject: [issue771479] pyconfig.h duplicates common defines Message-ID: <1200850798.93.0.512092444595.issue771479@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I fail to see the problem. HAVE_CHROOT (e.g.) is indeed generic, but so on purpose. If some other package also defines HAVE_CHROOT, but in a different way, then the problem is not that the names of the defines are identical, but that the values are different, hinting at a problem elsewhere (either Python's or that other package's autoconf must have computed the value incorrectly). ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 18:40:04 2008 From: report at bugs.python.org (Bill Janssen) Date: Sun, 20 Jan 2008 17:40:04 -0000 Subject: [issue592703] HTTPS does not handle pipelined requests Message-ID: <1200850804.35.0.807869513588.issue592703@psf.upfronthosting.co.za> Bill Janssen added the comment: Well, if someone writes test case and verifies it, I'll look at it. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 18:40:58 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 20 Jan 2008 17:40:58 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> New submission from Paul Pogonyshev: I have a regression from Python 2.5 to Python SVN (would-be-2.6). I believe this because of class attribute caching. The problem shown below happens because AbstractGCProtector is an extension class. So, Python interpreter doesn't have a chance to notice set_default() method below changes a class attribute. >>> from notify.all import * >>> original_protector = AbstractGCProtector.default >>> new_protector = FastGCProtector () >>> AbstractGCProtector.default is new_protector False >>> AbstractGCProtector.default is original_protector True Please note that this a regression. This code works as expected in 2.3 and 2.5. ---------- components: Interpreter Core messages: 61316 nosy: _doublep severity: major status: open title: class attribute cache failure (regression) type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 18:43:37 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 20 Jan 2008 17:43:37 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200851017.65.0.176769513433.issue1878@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Eh, disregard that, I missed one line with set_default() call. Still, the unit test fails... __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 18:45:32 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 20 Jan 2008 17:45:32 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200851132.21.0.235760287149.issue1878@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: OK, here it is: >>> from notify.all import * >>> original_protector = AbstractGCProtector.default >>> new_protector = FastGCProtector () >>> AbstractGCProtector.set_default (new_protector) >>> AbstractGCProtector.default is new_protector False >>> AbstractGCProtector.default is original_protector True It seems that this behaviour is somewhat random. Sometimes the False/True lines are reversed, as expected. I.e. it seems that attribute cache is sometimes recomputed... __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 18:47:02 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 20 Jan 2008 17:47:02 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <47935293.7010306@cheimes.de> Message-ID: <47938912.4010004@v.loewis.de> Martin v. L?wis added the comment: > Does the C89 standard allow this code? > > int q = 1; > int p = (unsigned)q; > I've never seen an unsigned cast without a type. Yes, that's fine; it's a different spelling of "unsigned int". In C99, 6.7.2p1 defines the following groups as equivalent: - short, signed short, short int, or signed short int - unsigned short, or unsigned short int - int, signed, or signed int - unsigned, or unsigned int - long, signed long, long int, or signed long int - unsigned long, or unsigned long int - long long, signed long long, long long int, or signed long long int - unsigned long long, or unsigned long long int Specifiers may occur in any order, so you may also write "int short unsigned". __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 18:57:56 2008 From: report at bugs.python.org (Ismail Donmez) Date: Sun, 20 Jan 2008 17:57:56 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1200851876.23.0.344974353651.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Hi Christian, unsigned cast is actually suggested by GCC developers to force correct wrapping for signed types. And thanks to Martin, it makes sense :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 19:09:31 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2008 18:09:31 -0000 Subject: [issue1615] descriptor protocol bug In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za> Message-ID: <1200852571.93.0.735412096679.issue1615@psf.upfronthosting.co.za> Antoine Pitrou added the comment: PyObject_GenericGetAttr is invoked from slot_tp_getattr_hook in typeobject.c via tp_getattro. The problem is that, when tp_getattro returns with an AttributeError, there is no way for slot_tp_getattr_hook to know whether the error was raised by PyObject_GenericGetAttr itself or by subsequent invocation of user code. Perhaps by adding an attribute to the raised AttributeError? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 19:17:17 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 18:17:17 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200853037.21.0.761510071636.issue1878@psf.upfronthosting.co.za> Georg Brandl added the comment: It would be very interesting to know what set_default() actually does. IOW, without the source code of the extension module we can't do anything about this. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 19:22:54 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 20 Jan 2008 18:22:54 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200853374.68.0.229132777903.issue1878@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: set_default() is a static method to set 'default'. Because of this: >>> AbstractGCProtector.default = 42 Traceback (most recent call last): File "", line 1, in TypeError: can't set attributes of built-in/extension type 'notify.gc.AbstractGCProtector' About source code: go to http://download.gna.org/py-notify/ download, unpack and do './run-tests.py' at top level. One test fails with Python SVN precisely because of this problem. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 19:44:21 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 18:44:21 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200854661.48.0.395832833123.issue1878@psf.upfronthosting.co.za> Georg Brandl added the comment: I'm sorry, but I can't get this to run. With a clean 0.1.14 tarball, I get Building extension... running build_ext building 'notify.gc' extension creating build creating build/temp.linux-i686-2.5 creating build/temp.linux-i686-2.5/notify i686-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC -I/usr/include/python2.5 -c notify/gc.c -o build/temp.linux-i686-2.5/notify/gc.o creating build/lib.linux-i686-2.5 creating build/lib.linux-i686-2.5/notify i686-pc-linux-gnu-gcc -pthread -shared build/temp.linux-i686-2.5/notify/gc.o -L/usr/lib -lpython2.5 -o build/lib.linux-i686-2.5/notify/gc.so [1] 28189 segmentation fault ~/devel/python/python run-tests.py when running with a trunk python (note the "2.5" in the paths...) When I build the extension manually and comment out the building command in run-tests.py, I get Note that most of the time is spent in gc.collect() calls, not in this package ..............................................................Fatal Python error: Objects/classobject.c:2311 object at 0x82dd2bc has negative ref count -606348326 [1] 28540 abort ~/devel/python/python run-tests.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 19:47:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 18:47:39 -0000 Subject: [issue779825] plistlib and bundlebuilder not in the documentation Message-ID: <1200854859.94.0.538345439233.issue779825@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: jvr -> components: +Documentation -Library (Lib) keywords: +easy versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 19:49:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 18:49:10 -0000 Subject: [issue917120] imaplib: incorrect quoting in commands Message-ID: <1200854950.03.0.0777972698115.issue917120@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy type: -> rfe versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 19:49:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 18:49:51 -0000 Subject: [issue756982] mailbox should use email not rfc822 Message-ID: <1200854991.87.0.849125164798.issue756982@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Documentation, Library (Lib) -Extension Modules keywords: +easy versions: +Python 2.6, Python 3.0 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 19:50:23 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 20 Jan 2008 18:50:23 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200855023.42.0.509079721746.issue1878@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Weird. Does it even run with a stable Python (not trunk)? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 19:51:12 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 18:51:12 -0000 Subject: [issue756093] complex pow() crash on Alpha Message-ID: <1200855072.25.0.0782411380559.issue756093@psf.upfronthosting.co.za> Christian Heimes added the comment: Does the error occur with Python 2.6, too? ---------- components: +Extension Modules -None nosy: +tiran status: open -> pending type: -> crash versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 19:51:20 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 18:51:20 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200855080.24.0.77162175368.issue1878@psf.upfronthosting.co.za> Georg Brandl added the comment: Yes, runs fine with 2.5. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 19:51:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 18:51:47 -0000 Subject: [issue763043] unable to specify another compiler Message-ID: <1200855107.64.0.791977193768.issue763043@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Documentation keywords: +easy type: -> rfe versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 19:54:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 18:54:03 -0000 Subject: [issue808197] rlcompleter incompatibility Message-ID: <1200855243.49.0.0464421394812.issue808197@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 19:55:00 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 20 Jan 2008 18:55:00 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200855300.11.0.522456023343.issue1878@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Can you run the pasted script (from the third comment) manually then? The crash might be related to the bug in question. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 19:57:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 18:57:45 -0000 Subject: [issue761888] popen2.Popen3 and popen2.Popen4 leaks filedescriptors Message-ID: <1200855465.67.0.9122889391.issue761888@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 19:58:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 18:58:29 -0000 Subject: [issue814654] 'import Tkinter' causes windows missing-DLL popup Message-ID: <1200855509.15.0.824609647892.issue814654@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> behavior versions: +Python 2.5, Python 2.6, Python 3.0 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 19:59:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 18:59:21 -0000 Subject: [issue836058] socket.send() on behaves as nonblocking when timeout is set Message-ID: <1200855561.07.0.563017782456.issue836058@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> behavior versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:01:23 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:01:23 -0000 Subject: [issue840065] Incorrect shared library build Message-ID: <1200855683.94.0.0813299258521.issue840065@psf.upfronthosting.co.za> Christian Heimes added the comment: The user hasn't provided a patch in more than 4 years. Please open a new issue if you are still interested in the feature. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:02:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:02:41 -0000 Subject: [issue858253] EAGAIN when sys.stdin.readline() Message-ID: <1200855761.86.0.965841527186.issue858253@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug is probably outdated. Please create a new issue if the bug still occurs for you with newer versions of Python and your OS. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:04:55 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:04:55 -0000 Subject: [issue872686] Python 2.3.3 test_tempfile test_mode() fails on AIX 5.2 Message-ID: <1200855895.93.0.10064577021.issue872686@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug report is 4 years old. Please open a new issue if the test fails with Python 2.5+. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:06:00 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:06:00 -0000 Subject: [issue894743] build_ssl can't find ActiveState Perl from unusual locations Message-ID: <1200855959.98.0.816312526828.issue894743@psf.upfronthosting.co.za> Christian Heimes added the comment: We have a new build system for Windows. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:07:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:07:08 -0000 Subject: [issue849218] ZipInfo shows incorrect file size for large files Message-ID: <1200856028.52.0.373025519337.issue849218@psf.upfronthosting.co.za> Christian Heimes added the comment: Several 32bit related issues were solved a while ago. Please creaet a new issue if the latest (!) svn checkout fails for you. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:07:38 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:07:38 -0000 Subject: [issue847812] 64 bit solaris versus /usr/local/lib Message-ID: <1200856058.06.0.728813800133.issue847812@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> works for me status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:08:27 2008 From: report at bugs.python.org (Christopher Friedt) Date: Sun, 20 Jan 2008 19:08:27 -0000 Subject: [issue1597850] Cross compiling patches for MINGW Message-ID: <1200856107.19.0.358808131552.issue1597850@psf.upfronthosting.co.za> Christopher Friedt added the comment: I can confirm what John Stowers experienced with ac_cv_printf_zd Did someone forget to run autoconf afterward? When I did, retrying configure again returned an error saying that config.sub was missing. I made configure just write out a yes to the ac_cv_printf_zd_format. After running 'make', the build failed saying make: *** No rule to make target `Parser/acceler. at O_FOR_BUILD@', needed by `Parser/pgen at EXEEXT_FOR_BUILD@'. Stop. ---------- nosy: +cfriedt _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:09:11 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:09:11 -0000 Subject: [issue811295] ntohs on Solaris can return negative values Message-ID: <1200856151.3.0.234299912558.issue811295@psf.upfronthosting.co.za> Christian Heimes added the comment: The ntohs bug was fixed in Python 2.6. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:09:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:09:52 -0000 Subject: [issue921868] socket_htons does not work under AIX 64-bit Message-ID: <1200856192.31.0.921226828298.issue921868@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Extension Modules -Library (Lib) keywords: +easy versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:10:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:10:10 -0000 Subject: [issue908316] pdb should hash stdout Message-ID: <1200856210.72.0.758307687468.issue908316@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: normal -> low type: -> rfe versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:11:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:11:36 -0000 Subject: [issue808164] socket.close() doesn't play well with __del__ Message-ID: <1200856296.5.0.685837143372.issue808164@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Extension Modules -Library (Lib) type: -> behavior versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:11:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:11:56 -0000 Subject: [issue896199] Some Carbon modules missing Message-ID: <1200856316.79.0.774145701942.issue896199@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: normal -> low type: -> rfe versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:13:43 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:13:43 -0000 Subject: [issue997912] Enclosing Scope missing from namespace in Tutorial Message-ID: <1200856423.66.0.49609234589.issue997912@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl keywords: +easy nosy: +georg.brandl priority: normal -> low versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:14:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:14:56 -0000 Subject: [issue977461] Cannot specify compiler for 'install' on command line Message-ID: <1200856496.59.0.0432259770194.issue977461@psf.upfronthosting.co.za> Christian Heimes added the comment: Use "python setup.py build --compiler=bcpp install" ---------- nosy: +tiran resolution: -> invalid status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:15:24 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:15:24 -0000 Subject: [issue970783] PyObject_GenericGetAttr is undocumented Message-ID: <1200856524.49.0.738315043548.issue970783@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl keywords: +easy nosy: +georg.brandl priority: normal -> low type: -> rfe versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:16:22 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:16:22 -0000 Subject: [issue951275] ihooks chokes on BioPython package Message-ID: <1200856582.33.0.954891209459.issue951275@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug is probably outdated. Please open a new issue if the code fails under Python 2.5 ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:20:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:20:27 -0000 Subject: [issue909308] Embedded Python Interpreter in MFC apps leaks Message-ID: <1200856827.39.0.121268689022.issue909308@psf.upfronthosting.co.za> Christian Heimes added the comment: See Roland Trainor's comment. ---------- nosy: +tiran resolution: -> works for me status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:21:17 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:21:17 -0000 Subject: [issue1072642] dyld: ./python.exe multiple definitions of symbol _BC Message-ID: <1200856877.24.0.732551485795.issue1072642@psf.upfronthosting.co.za> Christian Heimes added the comment: I interpret 3 years of silence as yes, Raymond :) ---------- nosy: +tiran resolution: -> invalid status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:21:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:21:45 -0000 Subject: [issue1095821] The doc for DictProxy is missing Message-ID: <1200856905.86.0.401616490646.issue1095821@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Documentation -Library (Lib) keywords: +easy priority: normal -> low type: -> rfe versions: +Python 2.6 -Python 2.3 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:24:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:24:04 -0000 Subject: [issue1003535] Simple File fix for Windows Runtime incompatability Message-ID: <1200857044.0.0.842833661084.issue1003535@psf.upfronthosting.co.za> Christian Heimes added the comment: We are using VS 2008 now and we don't support mixing multiple CRTs. If you still want to get your patch into Python 2.6 create a new issue with a clean patch. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:24:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:24:27 -0000 Subject: [issue767645] incorrect os.path.supports_unicode_filenames Message-ID: <1200857067.38.0.578545654045.issue767645@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> low versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:24:31 2008 From: report at bugs.python.org (Martey Dodoo) Date: Sun, 20 Jan 2008 19:24:31 -0000 Subject: [issue1092502] Memory leak in socket.py on Mac OS X Message-ID: <1200857071.28.0.858332933898.issue1092502@psf.upfronthosting.co.za> Martey Dodoo added the comment: Just wanted to note that the good people of comp.lang.python helped me figure out that the issue is actually http://bugs.python.org/issue1389051, in case anyone in similar straits ended up here. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:24:41 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:24:41 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200857081.96.0.564770960362.issue1878@psf.upfronthosting.co.za> Georg Brandl added the comment: I've now built my trunk python without debugging enabled, and can reproduce your problem. Armin: the extension module directly modifies an extension type's tp_dict -- what should it do instead to make the cache happy? ---------- assignee: -> arigo nosy: +arigo __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:25:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:25:08 -0000 Subject: [issue924008] make fails using -std option Message-ID: <1200857108.73.0.948688625649.issue924008@psf.upfronthosting.co.za> Christian Heimes added the comment: No response from OP in about 3 years, closing. ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:27:12 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:27:12 -0000 Subject: [issue1069092] segfault on printing nested sequences of None/Ellipsis Message-ID: <1200857232.02.0.104453551378.issue1069092@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> crash versions: +Python 2.6 -Python 2.3 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:27:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:27:53 -0000 Subject: [issue1069410] import on Windows: please call SetErrorMode first Message-ID: <1200857273.9.0.047253733512.issue1069410@psf.upfronthosting.co.za> Christian Heimes added the comment: I'll take fix it for 2.6 ---------- assignee: -> tiran components: +Interpreter Core -Library (Lib) nosy: +tiran priority: normal -> high versions: +Python 2.6 -Python 2.3 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:29:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:29:54 -0000 Subject: [issue874900] threading module can deadlock after fork Message-ID: <1200857394.0.0.823302324038.issue874900@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: normal -> high type: -> behavior versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:30:38 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:30:38 -0000 Subject: [issue1099746] copy.deepcopy barfs when copying a class derived from dict Message-ID: <1200857438.4.0.363687989531.issue1099746@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> duplicate status: open -> closed superseder: -> deepcopying listlike and dictlike objects _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:31:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:31:34 -0000 Subject: [issue786827] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: <1200857494.03.0.269137055964.issue786827@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- type: -> behavior versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:31:37 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:31:37 -0000 Subject: [issue1533491] C/API sec 10 is clipped Message-ID: <1200857497.35.0.250009415893.issue1533491@psf.upfronthosting.co.za> Georg Brandl added the comment: They have since been filled. ---------- nosy: +georg.brandl -gbrandl.historic resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:32:20 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:32:20 -0000 Subject: [issue1544306] checking size of int... configure: error: cannot compute siz Message-ID: <1200857540.67.0.406107305119.issue1544306@psf.upfronthosting.co.za> Georg Brandl added the comment: No response -> closing. ---------- nosy: +georg.brandl resolution: -> works for me status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:32:20 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:32:20 -0000 Subject: [issue1205736] wrong location for math lib with --prefix Message-ID: <1200857540.94.0.873139496497.issue1205736@psf.upfronthosting.co.za> Christian Heimes added the comment: No response in more than 2 years, closing. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:32:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:32:36 -0000 Subject: [issue898271] symtable module crashes w/ coding declaration Message-ID: <1200857556.81.0.0462847841759.issue898271@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:33:18 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:33:18 -0000 Subject: [issue1597000] HTTP headers Message-ID: <1200857598.92.0.218492731667.issue1597000@psf.upfronthosting.co.za> Georg Brandl added the comment: Lowering priority. ---------- components: +Library (Lib) -None keywords: +easy nosy: +georg.brandl -gbrandl.historic priority: normal -> low versions: +Python 2.5, Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:33:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:33:39 -0000 Subject: [issue1304179] 2.3.5 configure / make infinite loop Message-ID: <1200857619.23.0.278213630624.issue1304179@psf.upfronthosting.co.za> Christian Heimes added the comment: Yes, the makefile runs ./configure when the configure script is newer than Makefile. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:35:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:35:08 -0000 Subject: [issue1373762] Tweak pprint.PrettyPrinter.format for subclassing Message-ID: <1200857708.86.0.373042325941.issue1373762@psf.upfronthosting.co.za> Georg Brandl added the comment: This has now been fixed with #1351692. ---------- assignee: fdrake -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:36:13 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:36:13 -0000 Subject: [issue538961] Using the lib index mechanically Message-ID: <1200857773.01.0.890623853046.issue538961@psf.upfronthosting.co.za> Georg Brandl added the comment: I think the upcoming 2.6 release will provide the necessary functions to create such a feature. ---------- assignee: fdrake -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:36:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:36:36 -0000 Subject: [issue832159] C++ extensions using SWIG and MinGW Message-ID: <1200857796.57.0.075187993995.issue832159@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: normal -> low versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:39:33 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:39:33 -0000 Subject: [issue1241545] garbage collection asserts failing Message-ID: <1200857973.84.0.523376954504.issue1241545@psf.upfronthosting.co.za> Christian Heimes added the comment: No response from the OP in the last 2 years. I'm closing this bug. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:40:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:40:15 -0000 Subject: [issue962226] Python 2.3.4 on Linux: test test_grp failed Message-ID: <1200858015.7.0.204688279798.issue962226@psf.upfronthosting.co.za> Christian Heimes added the comment: No response from the OP in the last 2 years, closing ... ---------- nosy: +tiran resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:41:16 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:41:16 -0000 Subject: [issue760657] Tutorial: executable scripts on Windows Message-ID: <1200858076.68.0.298099891033.issue760657@psf.upfronthosting.co.za> Georg Brandl added the comment: Added a blurb in r60145. The details are in the new "Using on Windows" document. ---------- assignee: fdrake -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:46:13 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:46:13 -0000 Subject: [issue1597000] Use \r\n, not \n for HTTP headers Message-ID: <1200858373.07.0.453829646804.issue1597000@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- title: HTTP headers -> Use \r\n, not \n for HTTP headers _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:48:49 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:48:49 -0000 Subject: [issue1219903] tp_richcompare documentation wrong and incomplete Message-ID: <1200858529.24.0.525451968659.issue1219903@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60146. ---------- assignee: fdrake -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:49:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:49:39 -0000 Subject: [issue965065] document docs.python.org in PEP-101 Message-ID: <1200858579.53.0.888604506595.issue965065@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: fdrake -> georg.brandl nosy: +georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Jan 20 20:50:33 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:50:33 -0000 Subject: [issue1224] SimpleHTTPServer doesn't understand // at beginning of path anymore In-Reply-To: <1191237626.38.0.0266691685704.issue1224@psf.upfronthosting.co.za> Message-ID: <1200858633.51.0.907923596026.issue1224@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: -> normal versions: +Python 2.6 -Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:51:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:51:51 -0000 Subject: [issue1363] python 2.4.4 fails on solaris (sun4u sparc SUNW, Sun-Fire-880) In-Reply-To: <1193768290.81.0.981284051139.issue1363@psf.upfronthosting.co.za> Message-ID: <1200858711.18.0.853206445774.issue1363@psf.upfronthosting.co.za> Christian Heimes added the comment: Please provide the logs. I'm going to close the bug in two week unless you respond. ---------- nosy: +tiran status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:52:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:52:05 -0000 Subject: [issue1375] hotshot IndexError when loading stats In-Reply-To: <1194031021.72.0.351195403989.issue1375@psf.upfronthosting.co.za> Message-ID: <1200858725.06.0.591135165698.issue1375@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:54:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:54:02 -0000 Subject: [issue1434] SocketServer creates non-blocking files In-Reply-To: <1194952971.52.0.0175345572361.issue1434@psf.upfronthosting.co.za> Message-ID: <1200858842.0.0.187830644119.issue1434@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:54:23 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:54:23 -0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1200858863.82.0.492510859596.issue1545463@psf.upfronthosting.co.za> Georg Brandl added the comment: In the light of no further results, closing this bug. ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:54:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:54:28 -0000 Subject: [issue1429] FD leak in SocketServer In-Reply-To: <1194870454.07.0.621713310435.issue1429@psf.upfronthosting.co.za> Message-ID: <1200858868.52.0.289938934391.issue1429@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> high versions: +Python 2.6 -Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:54:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:54:41 -0000 Subject: [issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks In-Reply-To: <1196226917.03.0.0879630569127.issue1511@psf.upfronthosting.co.za> Message-ID: <1200858881.53.0.908813120201.issue1511@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:54:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:54:52 -0000 Subject: [issue1523] xdrlib fails to detect overflow (struct bug?) In-Reply-To: <1196356512.02.0.767950905039.issue1523@psf.upfronthosting.co.za> Message-ID: <1200858892.59.0.952953111999.issue1523@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:55:11 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:55:11 -0000 Subject: [issue1552] fromfd() and socketpair() should return wrapped sockets In-Reply-To: <1196739495.6.0.25894007336.issue1552@psf.upfronthosting.co.za> Message-ID: <1200858911.67.0.263867928852.issue1552@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy, patch priority: -> normal versions: -Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:55:18 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 19:55:18 -0000 Subject: [issue1454285] test_parsedate_acceptable_to_time_functions+DST == :-( Message-ID: <1200858918.15.0.310724941288.issue1454285@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: bwarsaw.historic -> barry nosy: +barry _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 20:55:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:55:31 -0000 Subject: [issue1556] Failure when calling __str__ for MIMEBase(message, rfc822) objects In-Reply-To: <1196869876.98.0.0449623543334.issue1556@psf.upfronthosting.co.za> Message-ID: <1200858931.89.0.883844846846.issue1556@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal versions: +Python 2.6 -Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:55:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:55:54 -0000 Subject: [issue1432] Strange behavior of urlparse.urljoin In-Reply-To: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za> Message-ID: <1200858954.74.0.444730682419.issue1432@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal versions: -Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:57:00 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:57:00 -0000 Subject: [issue1772] popen fails when there are two or more pathnames/parameters with spaces In-Reply-To: <1199859779.21.0.234395665559.issue1772@psf.upfronthosting.co.za> Message-ID: <1200859020.68.0.560063822041.issue1772@psf.upfronthosting.co.za> Christian Heimes added the comment: The popen*() function don't quote the paths for you. Please use the subprocess module. It takes care of the quoting on Windows. ---------- nosy: +tiran resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:57:46 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:57:46 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za> Message-ID: <1200859066.02.0.466059321069.issue1327@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 20:57:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 19:57:56 -0000 Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads running In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za> Message-ID: <1200859076.94.0.18989201362.issue1856@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:01:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 20:01:53 -0000 Subject: [issue1615] descriptor protocol bug In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za> Message-ID: <1200859313.08.0.976823890275.issue1615@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:03:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 20:03:36 -0000 Subject: [issue1874] email parser does not register a defect for invalid Content-Transfer-Encoding on multipart messages In-Reply-To: <1200767841.97.0.882225337338.issue1874@psf.upfronthosting.co.za> Message-ID: <1200859416.99.0.628320333103.issue1874@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy, patch priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:03:48 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 20:03:48 -0000 Subject: [issue1836] 'weekly' rotating logging file rotation incorrect In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> Message-ID: <1200859428.27.0.756417964944.issue1836@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:04:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 20:04:03 -0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za> Message-ID: <1200859443.89.0.112410933286.issue1622@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:04:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 20:04:26 -0000 Subject: [issue1817] module-cgi: handling GET and POST together In-Reply-To: <1200189536.91.0.809582793643.issue1817@psf.upfronthosting.co.za> Message-ID: <1200859466.17.0.222556226141.issue1817@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Library (Lib) priority: -> normal type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:04:43 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 20:04:43 -0000 Subject: [issue1825] msilib.add_data() takes exactly three parameters In-Reply-To: <1200337960.21.0.113421612542.issue1825@psf.upfronthosting.co.za> Message-ID: <1200859483.65.0.39901115278.issue1825@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy, patch priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:05:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 20:05:19 -0000 Subject: [issue1215] Python hang when catching a segfault In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> Message-ID: <1200859519.6.0.117794640932.issue1215@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Documentation keywords: +easy priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:34:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 20:34:44 -0000 Subject: [issue1343] XMLGenerator: nice elements In-Reply-To: <1193492035.12.0.0580891111126.issue1343@psf.upfronthosting.co.za> Message-ID: <1200861284.82.0.0387776742074.issue1343@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy, patch priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:34:54 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Sun, 20 Jan 2008 20:34:54 -0000 Subject: [issue1675] Race condition in os.makedirs In-Reply-To: <1198180171.38.0.482360233935.issue1675@psf.upfronthosting.co.za> Message-ID: <1200861294.5.0.695639280165.issue1675@psf.upfronthosting.co.za> Changes by Gabriel Genellina: ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:35:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 20:35:15 -0000 Subject: [issue1441] Cycles through ob_type aren't freed In-Reply-To: <1195009292.31.0.0975446267952.issue1441@psf.upfronthosting.co.za> Message-ID: <1200861315.37.0.202804541332.issue1441@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal type: -> behavior versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:38:32 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 20 Jan 2008 20:38:32 -0000 Subject: [issue1877] unhelpful error when calling "python " In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za> Message-ID: <1200861512.44.0.0369812857678.issue1877@psf.upfronthosting.co.za> Nick Coghlan added the comment: In what sense is this being flagged as easy? All the runpy code knows at this point is that it asked the import system for the __main__ module's code object and didn't get one. __main__ always exists, so the module is definitely able to be found - working out after the fact why the code object can't be provided isn't the simplest thing in the world. For example, "./python -m sys" triggers a similar error message. Or are you merely suggesting the addition of something like "(e.g. directory or zipfile does not contain __main__.py)" to the current error message when the requested module is "__main__"? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 21:40:49 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jan 2008 20:40:49 -0000 Subject: [issue1877] unhelpful error when calling "python " In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za> Message-ID: <1200861649.3.0.736273980437.issue1877@psf.upfronthosting.co.za> Georg Brandl added the comment: No idea about the "easy" -- I haven't really looked at the code, but amending the error message would be a good thing. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 22:03:11 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 20 Jan 2008 21:03:11 -0000 Subject: [issue1877] unhelpful error when calling "python " In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za> Message-ID: <1200862991.94.0.827581092013.issue1877@psf.upfronthosting.co.za> Nick Coghlan added the comment: I removed the easy tag. I'll try to come up with some ideas for making the error message more helpful without making it misleading. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 22:03:35 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2008 21:03:35 -0000 Subject: [issue1363] python 2.4.4 fails on solaris (sun4u sparc SUNW, Sun-Fire-880) In-Reply-To: <1193768290.81.0.981284051139.issue1363@psf.upfronthosting.co.za> Message-ID: <1200863015.7.0.493018796907.issue1363@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 22:50:40 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2008 21:50:40 -0000 Subject: [issue1720595] Allow T_BOOL in PyMemberDef definitions Message-ID: <1200865840.62.0.292005171106.issue1720595@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It seems to me that, when a boolean is to be represented, most C programmers would expect a char rather than an int. Also an int would make the object larger without any benefit. As for type checking, Angelo's patch already does a PyBool_Check against the argument. Is anything more required? ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Jan 20 22:54:31 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 20 Jan 2008 21:54:31 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200866071.0.0.0114686414482.issue1878@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Even if there is an easy workaround for the extension (or even a fix, if modifying 'tp_dict' is not legal), I don't think it would be acceptable to make a backward-incompatible change in 2.6. I mean, sure Py-notify is by no means a widely-used library, but can you guarantee that no other extension will get broken? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 23:02:19 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 20 Jan 2008 22:02:19 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200866539.75.0.282415541435.issue1878@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The issue seems similar to the one we had in ctypes when the method attribute cache was implemented. Ctypes was corrected in r59943. Maybe similar changes are needed for this extension. For example, PyDict_SetItemString (AbstractGCProtector_Type.tp_dict, "default", new_protector) should be modified like this: PyObject_SetAttr(AbstractGCProtector_Type, "default", new_protector) ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 23:07:19 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 20 Jan 2008 22:07:19 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200866839.87.0.387459869965.issue1878@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: It doesn't help: ERROR: test_default_property (test._gc.AbstractGCProtectorTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/paul/notify/test/_gc.py", line 59, in test_default_property AbstractGCProtector.set_default (original_protector) TypeError: can't set attributes of built-in/extension type 'notify.gc.AbstractGCProtector' With this code: if (PyObject_SetAttrString ((PyObject *) &AbstractGCProtector_Type, "default", new_protector) == -1) return NULL; __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 23:24:42 2008 From: report at bugs.python.org (George Castillo) Date: Sun, 20 Jan 2008 22:24:42 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200867882.81.0.239647793818.issue1640@psf.upfronthosting.co.za> George Castillo added the comment: Just a quick addition here regarding the singularities to these functions. The atanh(x) is only defined for |x| < 1, so atanh(1) or atanh(-1) isn't singular there so much as simply isn't defined. So, even though the function approaches infinite as x -> 1, it wouldn't really be correct to return a value at |x| = 1. I think raising an exception at those points would be more correct. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 20 23:54:36 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 20 Jan 2008 22:54:36 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200869676.13.0.848344794912.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: No: IEEE-754r and the C99 standard both say clearly that atanh(1) should be infinity and atanh(-1) should be -infinity, and furthermore that the 'divide-by-zero' exception should be raised rather than the 'invalid' exception. It's a singularity, just like log(0). (This makes even more sense viewed from the perspective of complex arithmetic, where atanh is defined at all points in the complex plane except -1 and 1, where it has log-type singularities.) The general idea is that it's meaningful to set atanh(1) = infinity because that's what the limit of atanh(x) is as x approaches 1 from below; similarly for atanh(-1) and log(0). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 00:39:52 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2008 23:39:52 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200872392.45.0.0378965427698.issue1703448@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I can reproduce this with both SVN trunk and 2.5.1 (on an x86 Mandriva box). ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 01:26:17 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 21 Jan 2008 00:26:17 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200875177.05.0.368494671873.issue1703448@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Also reproduced on winXP with SVN trunk. The cause seems that in threading.py, the __stop() method notifies all waiting threads, and that __delete() effectively removes the thread from the active list. I dared to swap the two calls, and it seems to solve the problem. Tests still pass, but can someone check that this can be done safely? ---------- nosy: +amaury.forgeotdarc _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 01:30:45 2008 From: report at bugs.python.org (George Castillo) Date: Mon, 21 Jan 2008 00:30:45 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200875445.87.0.904736511445.issue1640@psf.upfronthosting.co.za> George Castillo added the comment: I misunderstood the rationale for the function returning infinite at those points - I didn't realize that C99 was the governing force behind the implementation of these functions, rather than mathematical rigor. Thanks for pointing it out. In that case, I agree with you that, in order to conform, these functions would need to return the values required by those documents. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 02:02:15 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 01:02:15 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200877335.13.0.434975901325.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: George: I think my last post was a bit rude. I apologize if it came across that way. Mathematical rigor and IEEE-754 recommendations aren't necessarily in conflict here, though. For example, the natural log function from (0, infinity) to (-infinity, infinity) extends naturally and uniquely to a continuous function on the closed subset [0, infinity] of the extended real line---i.e., the real line together with the two extra points -infinity and infinity. With the appropriate topology, the extended real line is a perfectly well-defined and well-behaved mathematical object, though of course it's no longer a field. Since IEEE-754 floats include infinities, it's reasonable, and sometimes useful, to regard the set of IEEE-floats as a computational model of the extended real line instead of the reals. At any rate, I agree with you that log(0) and atanh(1) should raise Python exceptions, at least for now. But these calculations are qualitatively different from log(-1) and atanh(2), and it wouldn't be at all unreasonable if they raised a different exception--- e.g. ZeroDivisionError instead of ValueError. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 02:05:36 2008 From: report at bugs.python.org (Tim Peters) Date: Mon, 21 Jan 2008 01:05:36 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200877536.97.0.0204421613917.issue1640@psf.upfronthosting.co.za> Tim Peters added the comment: Mark, these are the "spirit of 754" rules: 1. If the mathematical result is a real number, but of magnitude too large to approximate by a machine float, overflow is signaled and the result is an infinity (with the appropriate sign). 2. If the mathematical result is a real number, but of magnitude too small to approximate by a machine float, underflow is signaled and the result is a zero (with the appropriate sign). 3. At a singularity (a value x such that the limit of f(y) as y approaches x exists and is an infinity), "divide by zero" is signaled and the result is an infinity (with the appropriate sign). This is complicated a little by that the left-side and right-side limits may not be the same; e.g., 1/x approaches +inf or -inf as x approaches 0 from the positive or negative directions. In that specific case, the sign of the zero determines the result of 1/0. 4. At a point where a function has no defined result in the extended reals (i.e., the reals plus an infinity or two), invalid operation is signaled and a NaN is returned. And these are what Python has historically /tried/ to do (but not always successfully, as platform libm behavior varies a lot): For #1, raise OverflowError. For #2, return a zero (with the appropriate sign if that happens by accident ;-)). For #3 and #4, raise ValueError. It may have made sense to raise Python's ZeroDivisionError in #3, but historically that's only been raised for division by zero and mod by zero. You're right that you can't make everyone happy, so may as well stick with historical consistency, and wait for a PEP to introduce a more flexible mechanism. As W. Kahan wrote long ago, the reason they're called "exceptions" is that no matter which fixed policy you adopt, someone will take strident exception to it ;-) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 03:51:29 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 02:51:29 -0000 Subject: [issue1879] sqrt(-1) doesn't raise ValueError on OS X In-Reply-To: <1200883888.97.0.437374079609.issue1879@psf.upfronthosting.co.za> Message-ID: <1200883888.97.0.437374079609.issue1879@psf.upfronthosting.co.za> New submission from Mark Dickinson: On OS X 10.4, and probably other versions of OS X too, calls to math.log and math.sqrt that should raise ValueError instead return a NaN: Python 2.6a0 (trunk:60144, Jan 20 2008, 21:43:56) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import sqrt, log >>> sqrt(-1) nan >>> log(-1) nan The problem is that OS X doesn't set errno in these cases. Attached is a quick fix for this. Note that there's already a test for this (test_exceptions in test_math.py), but this test is only run in verbose mode. See also issue #871657. ---------- components: Extension Modules files: sqrt_minus_one.patch keywords: patch messages: 61373 nosy: marketdickinson priority: normal severity: normal status: open title: sqrt(-1) doesn't raise ValueError on OS X type: behavior versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9247/sqrt_minus_one.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 03:58:52 2008 From: report at bugs.python.org (David W. Lambert) Date: Mon, 21 Jan 2008 02:58:52 -0000 Subject: [issue1880] Generalize math.hypot function In-Reply-To: <1200884332.34.0.152014748905.issue1880@psf.upfronthosting.co.za> Message-ID: <1200884332.34.0.152014748905.issue1880@psf.upfronthosting.co.za> New submission from David W. Lambert: Please generalize math.hypot. While I don't have a survey of python codes, it seems to me unlikely for this change to break existing programs. import math def hypot(*args): ''' Return the Euclidean vector length. >>> from math import hypot, sqrt >>> hypot(5,12) # traditional definition 13.0 >>> hypot() 0.0 >>> hypot(-6.25) 6.25 >>> hypot(1,1,1) == sqrt(3) # diagonal of unit box True ''' return math.sqrt(sum(arg*arg for arg in args)) I propose this version as closest to: >>> print sys.version 2.5.1 (r251:54863, Jan 4 2008, 17:15:14) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] >>> print math.hypot.__doc__ hypot(x,y) Return the Euclidean distance, sqrt(x*x + y*y). Thanks, Dave. PS. I don't understand why python is so restrictive. Although hypot is in the math library, it could be written in EAFP style as def hypot(*args): return sum(arg*arg for arg in args)**0.5 Rather than review the entire python library for items to generalize, I'll accept that the resulting errors would confuse "the penguin on my tele". "hypot" crosses me most often. I've not yet needed a version in the complex domain, such as my second version. I typically fill my need for length with scipy.sqrt(scipy.dot(v,v)), only to realize that for the short vectors I use, standard python constructs always perform faster than scipy ---------- components: Library (Lib) messages: 61374 nosy: LambertDW severity: minor status: open title: Generalize math.hypot function type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 04:16:38 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 21 Jan 2008 03:16:38 -0000 Subject: [issue1275] bsddb closing a DB object before all DBCursors using it are closed crashes In-Reply-To: <1192216802.58.0.956972286502.issue1275@psf.upfronthosting.co.za> Message-ID: <1200885398.77.0.949284780562.issue1275@psf.upfronthosting.co.za> Gregory P. Smith added the comment: a code snipped using a database d that demonstrates this: c = d.cursor() d.close() print >>sys.stderr, "database closed before cursor" del c print >>sys.stderr, "cursor deleted and we didn't crash!" ---------- priority: -> normal versions: +Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 04:34:26 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 03:34:26 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200886466.04.0.101099736381.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks, Tim! Dare I suggest extending these rules to encompass things like sqrt(NaN), log(inf), etc., as follows: - return a special value in Python where IEEE-754r/C99 specifies a special value, but doesn't raise any of the three divide-by-zero, invalid, or overflow exceptions, and - raise OverflowError or ValueError as appropriate where IEEE-754r specifies raising one of these exceptions. So e.g. cos(infinity) should give a ValueError, while log(infinity) and exp(infinity) should not raise any Python exception, but should return an infinity instead. And most single variable operations should return an input NaN unaltered, without raising an exception. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 05:33:25 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 04:33:25 -0000 Subject: [issue1880] Generalize math.hypot function In-Reply-To: <1200884332.34.0.152014748905.issue1880@psf.upfronthosting.co.za> Message-ID: <1200890005.42.0.675662286525.issue1880@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm not sure either that such a generalization would belong in math (which right now does little more than expose some basic functions from the C library) or that it should be called hypot. It seems to me that this would belong with other vector-type math stuff, but there isn't any of that in core Python or the libraries at the moment. On one hand, this falls foul of the 'not every one-liner should be a builtin' rule. On the other hand, it's not a one-liner if done properly: compare the output of math.hypot(1e160, 1e160) with the output of your version. Similarly for math.hypot(1e-160, 1e-160). ---------- nosy: +marketdickinson priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 10:30:54 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 21 Jan 2008 09:30:54 -0000 Subject: [issue1087741] subclassable mmap Message-ID: <1200907854.65.0.245703873738.issue1087741@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I'm attaching a patch, which makes mmap.mmap the mmap class itself and also makes it subclassable. It also contains changes to the documentation. This is against revision 60148 of trunk. ---------- nosy: +schmir Added file: http://bugs.python.org/file9248/mmapclass.txt _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 11:10:00 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 21 Jan 2008 10:10:00 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> Message-ID: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> New submission from Ralf Schmitt: The parser can handle nested structures only up to a certain limit. The limit is currently reached around 33 deeply nested lists, which is a bit too low. This patch increases that limit by a factor of 10. see http://bugs.python.org/issue215555 for further discussion. ---------- messages: 61379 nosy: schmir severity: normal status: open title: increase parser stack limit type: rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 11:11:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 10:11:01 -0000 Subject: [issue1880] Generalize math.hypot function In-Reply-To: <1200884332.34.0.152014748905.issue1880@psf.upfronthosting.co.za> Message-ID: <1200910261.29.0.386409244084.issue1880@psf.upfronthosting.co.za> Georg Brandl added the comment: IOW, this is rejected. ---------- nosy: +georg.brandl resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 11:15:52 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 21 Jan 2008 10:15:52 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> Message-ID: <1200910552.46.0.455907319261.issue1881@psf.upfronthosting.co.za> Changes by Ralf Schmitt: ---------- versions: +Python 2.6 Added file: http://bugs.python.org/file9249/up-maxstack.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 11:16:25 2008 From: report at bugs.python.org (Armin Rigo) Date: Mon, 21 Jan 2008 10:16:25 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200910585.83.0.0844773470905.issue1878@psf.upfronthosting.co.za> Armin Rigo added the comment: I don't see in general how the patch can be kept compatible with extension modules that change the tp_dict of arbitrary types. All I can think of is a way to be safe against extension modules that only change the tp_dict of their own non-heap types (i.e. types defined in C). The method cache is disabled for types that don't have the Py_TPFLAGS_HAVE_VERSION_TAG flag; so if we would leave this flag out of Py_TPFLAGS_DEFAULT, non-heap types from extension modules would by default not use the cache. I'm not sure about the API for this. Would we then need to put Py_TPFLAGS_HAVE_VERSION_TAG explicitly on all core types? And about how to change tp_dict in a way that makes the cache happy - do we need to turn type_modified() into a public API? All in all, the lack of abstraction of the C API might kill the idea of this patch for CPython. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 11:17:00 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 21 Jan 2008 10:17:00 -0000 Subject: [issue215555] Parser crashes for deeply nested list displays Message-ID: <1200910620.7.0.936115382967.issue215555@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Ok, I've upped the limit to some very high value and tried to provoke a stack overflow. eval("["*x+"]"*x) segfaults on my machine for x somewhere around 20000 (linux, amd64). When setting MAXSTACK to 5000 eval("["*x+"]"*x) works for x <= 333. So, I guess this should be safe guess (even for the BSDs, which have a smaller default stack size). BTW: The hardest part was recognizing that nothing gets rebuilt and that more then parser.o depended on parser.h. Don't you have some kind of automatic dependency tracking? Or am I missing some build tools? Anyway, patch in http://bugs.python.org/issue1881 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 11:25:15 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 10:25:15 -0000 Subject: [issue1269] Exception in pstats print_callers() In-Reply-To: <1192173262.83.0.27550877069.issue1269@psf.upfronthosting.co.za> Message-ID: <1200911114.99.0.665579186281.issue1269@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed as r60149. Thanks for the patch! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 11:51:52 2008 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 21 Jan 2008 10:51:52 -0000 Subject: [issue1882] py_compile does not follow PEP 0263 In-Reply-To: <1200912712.61.0.875613384462.issue1882@psf.upfronthosting.co.za> Message-ID: <1200912712.61.0.875613384462.issue1882@psf.upfronthosting.co.za> New submission from Jakub Wilk: PEP 0263 allows an encoding declaration in the second line, but py_compile seems not to recognize such ones: >>> MODULE = "\n# encoding=UTF-8\nU = u'\xc3\xb3'\n" >>> f = file('tmp.py', 'w') >>> f.write(MODULE) >>> f.close() >>> from py_compile import compile >>> compile('tmp.py', 'tmp_buggy.pyc', 'tmp_buggy.py', doraise = True) >>> import tmp >>> import tmp_buggy >>> tmp.U u'\xf3' >>> tmp_buggy.U u'\xc3\xb3' ---------- components: Library (Lib) messages: 61384 nosy: jwilk severity: major status: open title: py_compile does not follow PEP 0263 type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 13:24:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 12:24:51 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1200886466.04.0.101099736381.issue1640@psf.upfronthosting.co.za> Message-ID: <47948F10.5000002@cheimes.de> Christian Heimes added the comment: Mark Dickinson wrote: > So e.g. cos(infinity) should give a ValueError, while log(infinity) and exp(infinity) > should not raise any Python exception, but should return an infinity instead. And most > single variable operations should return an input NaN unaltered, without raising an > exception. The matter should be discussed in a proper PEP and targeted for Python 3.0. Python 3.0 is the right place for subtle changes which may break code. For Python 2.6 we must not change the exception or outcome of a function and new functions should be as consistent with existing ones as possible. I still don't like the idea of math.atanh(1) == inf. Why? See for yourself: 18.714973875118524 >>> math.atanh(.99999999999999999) Traceback (most recent call last): File "", line 1, in ValueError: math domain error (Linux) Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 13:31:09 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 12:31:09 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200918669.82.0.325407716705.issue1640@psf.upfronthosting.co.za> Christian Heimes added the comment: The mail interface screwed up the message: >>> math.atanh(.9999999999999999) 18.714973875118524 >>> math.atanh(.99999999999999999) Traceback (most recent call last): File "", line 1, in ValueError: math domain error __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 14:12:40 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 13:12:40 -0000 Subject: [issue215555] Parser crashes for deeply nested list displays Message-ID: <1200921160.72.0.126882039899.issue215555@psf.upfronthosting.co.za> Christian Heimes added the comment: Parser/parser.h was not in the list of dependencies. I fixed it in r60151 ---------- nosy: +tiran ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 14:13:42 2008 From: report at bugs.python.org (Mikhail Zabaluev) Date: Mon, 21 Jan 2008 13:13:42 -0000 Subject: [issue460474] codecs.StreamWriter: reset() on close() Message-ID: <1200921221.98.0.238310309512.issue460474@psf.upfronthosting.co.za> Mikhail Zabaluev added the comment: Wow, it's exciting to receive followups 6+ years after filing the bug. > Could you come up with a patch ? No, I don't do much Python development these days. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 14:19:06 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 21 Jan 2008 13:19:06 -0000 Subject: [issue460474] codecs.StreamWriter: reset() on close() Message-ID: <1200921546.09.0.442972740069.issue460474@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Sorry for not getting back to you earlier. The ticket was unassigned and only assigned to me yesterday. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 14:25:24 2008 From: report at bugs.python.org (Vlado Handziski) Date: Mon, 21 Jan 2008 13:25:24 -0000 Subject: [issue1754489] Non-portable address length calculation for AF_UNIX sockets Message-ID: <1200921924.0.0.849720295911.issue1754489@psf.upfronthosting.co.za> Vlado Handziski added the comment: So what is the procedure for checking in the patch? I don't have a commit access to the repository to do it myself... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 14:37:42 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 21 Jan 2008 13:37:42 -0000 Subject: [issue1464788] Python 2.4.3 build issue on Cygwin Message-ID: <1200922662.83.0.306269174201.issue1464788@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Closing as fixed, since the problem was reported as solved in 2.5alpha2 and it's unlikely anyone will make a 2.4.x bugfix release now. ---------- nosy: +akuchling resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 14:40:00 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 13:40:00 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> Message-ID: <1200922799.97.0.654386157383.issue1881@psf.upfronthosting.co.za> Georg Brandl added the comment: Guido, is the 10-fold increase okay? ---------- assignee: -> gvanrossum nosy: +georg.brandl, gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 14:48:04 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 21 Jan 2008 13:48:04 -0000 Subject: [issue1745108] 2.5.1 curses panel segfault in new_panel on aix 5.3 Message-ID: <1200923284.08.0.799143518594.issue1745108@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I don't see how win->win could be uninitialized. curses.newwin() creates a PyCursesWindowObject using PyCursesWindow_New(), which always fills in the ->win field. I'm puzzled by the 2007-06-28 traceback. Pycurses_new_panel has args = 0x0000000110246dc0; args should be a Python tuple containing the function's arguments. But the new_panel call has win=0x0000000110246dc0, the exact same pointer, which is obviously wrong. The code in PyCurses_new_panel does win->win, though, so the pointer should be different. Perhaps the traceback is wrong? Or perhaps this is a code-generation bug affecting PyCurses_new_panel? (But that function is small and straightforward -- I find it hard to imagine a compiler getting it wrong.) ---------- assignee: -> akuchling nosy: +akuchling _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 14:48:40 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 21 Jan 2008 13:48:40 -0000 Subject: [issue1723038] Curses Menu Message-ID: <1200923320.7.0.957406925012.issue1723038@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling nosy: +akuchling _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 14:50:17 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 21 Jan 2008 13:50:17 -0000 Subject: [issue1687125] cannot catch KeyboardInterrupt when using curses getkey() Message-ID: <1200923417.22.0.124002682373.issue1687125@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling nosy: +akuchling title: cannot catch KeyboardInterrupt when using curses getkey() -> cannot catch KeyboardInterrupt when using curses getkey() _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 14:50:56 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 21 Jan 2008 13:50:56 -0000 Subject: [issue1119331] curses.initscr - initscr exit w/o env(TERM) set Message-ID: <1200923456.69.0.556546466868.issue1119331@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: mwh -> akuchling _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 14:52:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 13:52:51 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200923571.15.0.583846082149.issue1640@psf.upfronthosting.co.za> Christian Heimes added the comment: I've added your complex patch and its tests to my patch. The tests are showing some flaws in the atanh (or log1p) function on Windows: AssertionError: atanh0022:atanh(-1.000000) returned -18.36840028483855, expected -18.714973875118524 On Linux the tests are passing just fine. Added file: http://bugs.python.org/file9250/trunk_pymath_hyberbolic_complex.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 14:53:37 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 21 Jan 2008 13:53:37 -0000 Subject: [issue1753732] xmlrpclib.Binary doesn't say which base64 spec it implements Message-ID: <1200923617.49.0.394898049931.issue1753732@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy, patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 14:57:10 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 21 Jan 2008 13:57:10 -0000 Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16) Message-ID: <1200923830.76.0.814247719589.issue1470548@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 15:03:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 14:03:15 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> Message-ID: <1200924195.49.0.232298758475.issue1881@psf.upfronthosting.co.za> Christian Heimes added the comment: 10-fold is very progressive. Let's be a bit more conservative for platforms with a small stack size (e.g. *BSD and mobile phones). A parser stack limit of about 1500 would still allow roughly 100 deeply nested lists. ---------- nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 15:16:59 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 14:16:59 -0000 Subject: [issue1087741] subclassable mmap Message-ID: <1200925019.03.0.784369140041.issue1087741@psf.upfronthosting.co.za> Georg Brandl added the comment: Reviewed and committed in r60152. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 15:22:34 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 21 Jan 2008 14:22:34 -0000 Subject: [issue1087741] subclassable mmap Message-ID: <1200925353.97.0.893459380943.issue1087741@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Many thanks for handling it immediately. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 15:35:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 14:35:36 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200926136.87.0.970967749582.issue1640@psf.upfronthosting.co.za> Christian Heimes added the comment: It's most probably the fault of log1p(): AssertionError: atanh0022:atanh(-0.99999999999999989) returned -18.36840028483855, expected -18.714973875118524 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 15:53:15 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 14:53:15 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200927195.69.0.767753890342.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Christian: I'm definitely not proposing atanh(1) = inf: it should raise ValueError. I'm proposing that we follow Tim's rules for now; this means no change for finite inputs. The new thing here is that since you've made inf and nan more accessible and consistent across platforms, I think we should make sure that the math functions do the right thing for an *input* of +/-inf or nan. I'm almost sure that the current behavior of e.g. exp(float("inf")) is more-or-less accidental rather than designed. I think I'm missing the point of your math.atanh(.999...) example. .99999999999999999 *is* already exactly equal to 1.0, so you're just proving that math.atanh(1.0) currently gives a ValueError. (Which, again, I think is the right thing to do.) >>> x = .99999999999999999 >>> x == 1.0 True The atanh0022 result is definitely a bug: it looks like either asinh or log1p is buggy. I'll try to figure it out. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 16:10:31 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 15:10:31 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200928231.17.0.743229176439.issue1878@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- priority: -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 16:11:19 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 21 Jan 2008 15:11:19 -0000 Subject: [issue1669] shutil.rmtree fails on symlink, after deleting contents In-Reply-To: <1198140802.03.0.559721880432.issue1669@psf.upfronthosting.co.za> Message-ID: <1200928279.76.0.487857041374.issue1669@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: If rmtree() always returns in case of symbolic links (as it is checked-in), wouldn't it be much simpler to totally do away with 'onerror' handling? I thought 'onerror' gives the user the option how to proceed (which is true in other usages). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 16:11:27 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 15:11:27 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200928287.73.0.152686192639.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Christian: would it be possible for you to tell me what the argument of the log1p call is on Windows in that last branch of c_atanh, for the testcase atanh0022. On OS X I get: Input to log1p is 3.2451855365842669075e+32 It's hard to imagine that there's anything wrong with log1p here, since all it does for a large input like this is compute log(1+x). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 16:25:03 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 15:25:03 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200929103.24.0.177485914176.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Okay: here's an attempted guess at what's happening on Windows: Near the end of c_atanh, there's a line that reads: r.real = log1p(4.*z.real/((1-z.real)*(1-z.real) + ay*ay))/4.; Somehow, when z.real is 0.99999999999999989 and ay is 0, the argument to log1p is ending up one-quarter of the size that it should be. I suspect that the 1-z.real calculation is producing, for reasons that are beyond me, the float 2**-52 instead of the correct value of 2**- 53. Christian: if you have any time to play with this, could you try replacing this line with something like: double temp = 1-z.real printf("z.real is %.19e\n", z.real); r.real = log1p(4.*z.real/(temp*temp + ay*ay))/4.; and see if either the problem goes away or if you can confirm that temp is coming out to be 2.2204460492503131e-16 rather than 1.1102230246251565e-16. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 16:29:44 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 21 Jan 2008 15:29:44 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1200929384.05.0.657843707124.issue1577@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: ---------- components: +Documentation -Library (Lib) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 16:31:43 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 15:31:43 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200929503.96.0.434288278689.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sorry: those lines should have been: double temp = 1-z.real; printf("temp is %.19e\n", temp); r.real = log1p(4.*z.real/(temp*temp + ay*ay))/4.; __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 17:34:45 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 16:34:45 -0000 Subject: [issue1555501] Please include pliblist for all plattforms Message-ID: <1200933285.03.0.0447368784869.issue1555501@psf.upfronthosting.co.za> Georg Brandl added the comment: I added documentation and moved plistlib to the general library in r60155. Ronald, if you want to enhance the documentation, please go ahead :) ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 17:35:31 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 16:35:31 -0000 Subject: [issue779825] plistlib and bundlebuilder not in the documentation Message-ID: <1200933331.32.0.00648804908443.issue779825@psf.upfronthosting.co.za> Georg Brandl added the comment: plistlib is now documented. I also added a stub for bundlebuilder that only has the module docstring as an overview -- Ronald, if you want to write more about that? ---------- assignee: -> ronaldoussoren nosy: +georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 17:39:56 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 16:39:56 -0000 Subject: [issue1153226] string interpolation breaks with %d and large float Message-ID: <1200933596.16.0.843585300905.issue1153226@psf.upfronthosting.co.za> Mark Dickinson added the comment: This is a duplicate of issue #1742669 ---------- nosy: +marketdickinson resolution: -> duplicate status: open -> closed superseder: -> "%d" format handling for long values _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 17:43:07 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 21 Jan 2008 16:43:07 -0000 Subject: [issue779825] plistlib and bundlebuilder not in the documentation Message-ID: <1200933787.52.0.603398471154.issue779825@psf.upfronthosting.co.za> Ronald Oussoren added the comment: bundlebuilder should be deprecated (and removed in 3.0 / 2.7). Currently the best tool for building bundles is py2app (which isn't part of the stdlib) ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 17:44:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 16:44:39 -0000 Subject: [issue1715] Make pydoc list submodules In-Reply-To: <1199145132.63.0.00647784499418.issue1715@psf.upfronthosting.co.za> Message-ID: <1200933879.45.0.165883449129.issue1715@psf.upfronthosting.co.za> Georg Brandl added the comment: The patch only amends TextDoc -- what about HtmlDoc? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 17:46:19 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 16:46:19 -0000 Subject: [issue779825] plistlib and bundlebuilder not in the documentation Message-ID: <1200933979.13.0.311784641717.issue779825@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, I'll remove the docs again. If you want to deprecate bundlebuilder, it must be added to PEP 4. ---------- resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 17:47:45 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 16:47:45 -0000 Subject: [issue1669] shutil.rmtree fails on symlink, after deleting contents In-Reply-To: <1198140802.03.0.559721880432.issue1669@psf.upfronthosting.co.za> Message-ID: <1200934065.93.0.408554713353.issue1669@psf.upfronthosting.co.za> Georg Brandl added the comment: Guido explicitly said "it should raise IOError, not ValueError, and it should use the onerror() handling used for all other errors" which makes sense for me too. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 17:52:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 16:52:01 -0000 Subject: [issue997912] Enclosing Scope missing from namespace in Tutorial Message-ID: <1200934321.88.0.901909753787.issue997912@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60158. ---------- resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 17:52:45 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 16:52:45 -0000 Subject: [issue1706] Force WINVER 0x0500 (Windows 2000) In-Reply-To: <1198848122.63.0.86389332394.issue1706@psf.upfronthosting.co.za> Message-ID: <1200934365.03.0.380208125397.issue1706@psf.upfronthosting.co.za> Georg Brandl added the comment: So what's the resolution here? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 17:55:20 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 16:55:20 -0000 Subject: [issue1720595] Allow T_BOOL in PyMemberDef definitions Message-ID: <1200934520.32.0.459802704049.issue1720595@psf.upfronthosting.co.za> Georg Brandl added the comment: Martin - is a char struct member for T_BOOL fine with you? ---------- assignee: -> loewis nosy: +loewis _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 17:56:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 16:56:36 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1200928287.73.0.152686192639.issue1640@psf.upfronthosting.co.za> Message-ID: <4794CEB7.2040502@cheimes.de> Christian Heimes added the comment: Mark Dickinson wrote: > Mark Dickinson added the comment: > > Christian: would it be possible for you to tell me what the argument of the > log1p call is on Windows in that last branch of c_atanh, for the testcase > atanh0022. > > On OS X I get: > > Input to log1p is 3.2451855365842669075e+32 > > It's hard to imagine that there's anything wrong with log1p here, since all > it does for a large input like this is compute log(1+x). You got me wrong (and I didn't explain it properly). All complex functions pass the test. math.atanh() fails. I think my implementation of Python/pymath.c:atanh() doesn't return the right value for arguments almost 1.0. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 17:58:41 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 16:58:41 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200934721.11.0.0252344024062.issue1878@psf.upfronthosting.co.za> Georg Brandl added the comment: We can of course add something like in #1229239, which allows type attributes to be set with PyObject_SetAttr, thereby updating the cache. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 18:01:02 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 17:01:02 -0000 Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results Message-ID: <1200934862.05.0.207427764976.issue1678380@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: aleax -> marketdickinson _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 18:02:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 17:02:18 -0000 Subject: [issue1706] Force WINVER 0x0500 (Windows 2000) In-Reply-To: <1200934365.03.0.380208125397.issue1706@psf.upfronthosting.co.za> Message-ID: <4794D018.5090606@cheimes.de> Christian Heimes added the comment: Georg Brandl wrote: > So what's the resolution here? We don't have a resolution yet. I may need the WINVER for the patch #1763 but I've to investigate the patch before I can submit it. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 18:06:40 2008 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 21 Jan 2008 17:06:40 -0000 Subject: [issue1836] 'weekly' rotating logging file rotation incorrect In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> Message-ID: <1200935200.51.0.543724707367.issue1836@psf.upfronthosting.co.za> Vinay Sajip added the comment: Fix checked into trunk and release25-maint. Thanks for the patch, Kathryn. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 18:14:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 17:14:08 -0000 Subject: [issue1883] Adapt pydoc to new doc system In-Reply-To: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za> Message-ID: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za> New submission from Georg Brandl: so that this doesn't get lost... ---------- assignee: georg.brandl components: Library (Lib) messages: 61418 nosy: georg.brandl severity: normal status: open title: Adapt pydoc to new doc system versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 18:14:50 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 17:14:50 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200935690.04.0.874915526538.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sorry: I should have read more carefully. So math.atanh works on Linux but is producing some strange results on Windows. It's still rather puzzling though. I still suspect that it's the argument to log1p that's coming out wrong rather than the result. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 18:15:25 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 17:15:25 -0000 Subject: [issue1836] 'weekly' rotating logging file rotation incorrect In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> Message-ID: <1200935725.8.0.541974914075.issue1836@psf.upfronthosting.co.za> Christian Heimes added the comment: Please update Misc/NEWS for the bug fix. You forgot to update it for this and another logging fix a week ago. ---------- nosy: +tiran status: closed -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 18:16:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 17:16:08 -0000 Subject: [issue1621660] this module (Zen of Python) docs list broken URL Message-ID: <1200935768.89.0.583729161064.issue1621660@psf.upfronthosting.co.za> Georg Brandl added the comment: Where exactly is that broken link? ---------- nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 18:22:51 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 17:22:51 -0000 Subject: [issue1726198] Line iteration readability Message-ID: <1200936170.99.0.105513015884.issue1726198@psf.upfronthosting.co.za> Georg Brandl added the comment: I also left out the changes to the ftplib and distutils functions since they also accept file objects as parameters, to keep b/w compatibility. Committed the rest as r60163. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 18:24:20 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 17:24:20 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1200935690.04.0.874915526538.issue1640@psf.upfronthosting.co.za> Message-ID: <4794D541.7020109@cheimes.de> Christian Heimes added the comment: Mark Dickinson wrote: > Sorry: I should have read more carefully. So math.atanh works on Linux > but is producing some strange results on Windows. > > It's still rather puzzling though. I still suspect that it's the > argument to log1p that's coming out wrong rather than the result. It uses t = 0.5 * log1p((x + x) / (1.0 - x)) for t > 0.5. I presume the culprit is in "2 / x" where x is almost 0. Do you have an idea how we can increase the accuracy for values nearly 1.? Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 18:29:34 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 17:29:34 -0000 Subject: [issue1631394] sre module has misleading docs Message-ID: <1200936574.31.0.463407268225.issue1631394@psf.upfronthosting.co.za> Georg Brandl added the comment: Clarified in r60164. ---------- assignee: effbot -> georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 18:31:12 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 17:31:12 -0000 Subject: [issue1570672] qtsupport.py mistake leads to bad _Qt module Message-ID: <1200936672.54.0.686960883927.issue1570672@psf.upfronthosting.co.za> Georg Brandl added the comment: This is a dupe of #1254695. ---------- resolution: -> duplicate status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 18:39:56 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 17:39:56 -0000 Subject: [issue1012468] Rational.py various bugfixes Message-ID: <1200937195.99.0.00381729311801.issue1012468@psf.upfronthosting.co.za> Georg Brandl added the comment: Now that we have a (different) rational module in the stdlib, shouldn't we remove this one altogether? ---------- assignee: -> jyasskin nosy: +georg.brandl, jyasskin _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 18:42:50 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 17:42:50 -0000 Subject: [issue1530959] distutils doesn't notice --with-pydebug Message-ID: <1200937370.36.0.916725795547.issue1530959@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed as r60166. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 18:44:17 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 21 Jan 2008 17:44:17 -0000 Subject: [issue1669] shutil.rmtree fails on symlink, after deleting contents In-Reply-To: <1200934065.93.0.408554713353.issue1669@psf.upfronthosting.co.za> Message-ID: <2c51ecee0801210944x1675a3ecx496089b75c95f5ee@mail.gmail.com> Raghuram Devarakonda added the comment: > and it should use the onerror() handling used for all other errors" > which makes sense for me too. Sure. I am ok with using 'onerror'. The point I am trying to make is that there is slight difference between 'onerror' in this case and in the three other places where it is called. In the case of symlink, rmtree() returns even when 'onerror' doesn't raise exception. This is not same in the other cases where rmtree() continues. I am just wondering if this inconsistency is worth it and if it is, an explicit mention in the doc will be nice. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 18:50:50 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 17:50:50 -0000 Subject: [issue1678345] A fix for the bug #1528074 [warning: quite slow] Message-ID: <1200937850.43.0.763672942732.issue1678345@psf.upfronthosting.co.za> Georg Brandl added the comment: Rejecting as per discussion. ---------- nosy: +georg.brandl resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 18:55:16 2008 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 21 Jan 2008 17:55:16 -0000 Subject: [issue1295] logging records cache the result of formatException() In-Reply-To: <1192721436.77.0.0263561863659.issue1295@psf.upfronthosting.co.za> Message-ID: <1200938116.87.0.457784901224.issue1295@psf.upfronthosting.co.za> Vinay Sajip added the comment: I've updated the docs (Formatter.format) to mention the caching and its effect on multiple formatters. ---------- nosy: +vsajip __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:04:35 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 18:04:35 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200938675.9.0.413047758272.issue1640@psf.upfronthosting.co.za> Christian Heimes added the comment: I disabled the tests for atanh0022 and atanh0023. Other changes: Added math.log1p + tests Added SUN license to Doc/licenses.rst Added docs to Doc/library/math.rst Added file: http://bugs.python.org/file9251/trunk_pymath_hyberbolic_complex2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:04:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 18:04:45 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200938685.6.0.377275358802.issue1640@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file9250/trunk_pymath_hyberbolic_complex.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:04:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 18:04:53 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200938693.37.0.759757087461.issue1640@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8989/trunk_math_sign_inf_nan.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:04:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 18:04:59 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200938699.66.0.124263094497.issue1640@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8975/trunk_mathmodule.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:05:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2008 18:05:05 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200938705.89.0.678537055051.issue1640@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file9243/trunk_pymath_hyberbolic.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:10:23 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 21 Jan 2008 18:10:23 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200939023.64.0.303858700675.issue1640@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- nosy: -gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:16:13 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 21 Jan 2008 18:16:13 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> Message-ID: <1200939373.28.0.937389605544.issue1881@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't know what common stack sizes are any more. Even on the same platform, the main thread may have a different stack size than other threads. Would it make sense to make this limit more platform-dependent? I guess really good would be a way to handle C stack overflows more gracefully, but that's for another era. All said, let's try a 3x increase, *and* have a unittest that pushes the limits to the max (both a case that is one short of the limit and a case that is over the limit, and is expected to raise an exception). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:19:08 2008 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 21 Jan 2008 18:19:08 -0000 Subject: [issue1836] 'weekly' rotating logging file rotation incorrect In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> Message-ID: <1200939548.82.0.777188219168.issue1836@psf.upfronthosting.co.za> Vinay Sajip added the comment: Misc/NEWS updated. Thanks for the reminder! __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:19:23 2008 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 21 Jan 2008 18:19:23 -0000 Subject: [issue1836] 'weekly' rotating logging file rotation incorrect In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za> Message-ID: <1200939563.73.0.331837839135.issue1836@psf.upfronthosting.co.za> Changes by Vinay Sajip: ---------- status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:37:36 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 18:37:36 -0000 Subject: [issue1882] py_compile does not follow PEP 0263 In-Reply-To: <1200912712.61.0.875613384462.issue1882@psf.upfronthosting.co.za> Message-ID: <1200940656.39.0.559806166072.issue1882@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the report, fixed in r60168, r60169 (2.5). ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:38:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 18:38:53 -0000 Subject: [issue1750076] Python 2.5+ skips while statements in debuggers Message-ID: <1200940733.02.0.767257168345.issue1750076@psf.upfronthosting.co.za> Georg Brandl added the comment: Raising priority. ---------- components: +Library (Lib) -None nosy: +georg.brandl priority: normal -> high type: -> behavior versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 19:39:35 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 18:39:35 -0000 Subject: [issue1081879] Pydoc can't find browser (bug+solution!) Message-ID: <1200940775.22.0.693519880779.issue1081879@psf.upfronthosting.co.za> Georg Brandl added the comment: This should be fixed in 2.5's webbrowser.py. ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 19:42:40 2008 From: report at bugs.python.org (Eric Sammons) Date: Mon, 21 Jan 2008 18:42:40 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1200441903.31.0.586391820932.issue1327@psf.upfronthosting.co.za> Message-ID: <6ee6d41b0801211042q7b8a5c6ak79c213975dc7de03@mail.gmail.com> Eric Sammons added the comment: Has anybody else tested this against an RPC server that has more than 300 items to be returned. I find it interesting that before all the xmlrpc code changed everything works fine, but after the code change (re-write) things don't seem to work. As for the bug, I do not claim there is a bug, I am simply pointing out that when using oprofile to profile the test application, most of the time is spent in a specific routine. Now it could be a side affect of xmlrpc, I don't know - I do not claim to be a "programmer". I am looking to turn on verbose mode in xmlrpc. As soon as I do that I will test again and send the results. On Jan 15, 2008 7:05 PM, Fredrik Lundh wrote: > > Fredrik Lundh added the comment: > > Can you switch on verbose mode in xmlrpclib, so you can see *where* the > transfer hangs? > > Arguing that a hanging Python program must be caused by a bug in the > code that *executes* the Python program isn't that meaningful, really. > After all, that code is used to run *all* Python programs, so I think > we'd noticed if it had a tendency to hang unexpectedly... > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:45:09 2008 From: report at bugs.python.org (Facundo Batista) Date: Mon, 21 Jan 2008 18:45:09 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> Message-ID: <1200941109.3.0.013366573873.issue1881@psf.upfronthosting.co.za> Facundo Batista added the comment: Ralf, could you please submit the unit test that Guido suggested? Please change also the 10x to 3x. We could then apply this, :) Thank you very much! ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 19:56:35 2008 From: report at bugs.python.org (Eric Sammons) Date: Mon, 21 Jan 2008 18:56:35 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za> Message-ID: <1200941795.43.0.262648044632.issue1327@psf.upfronthosting.co.za> Eric Sammons added the comment: I have added the verbose=1 option, the processing hangs in the body: where : for a in l: print a['channel_label'] Is returning the data. Initially it returns data quickly and then slows until it eventually stops. Here is the sample of the body data... data removed... body: ' This information is repeats ~500 times in the server where the program eventually times out. If you require anything further from the verbose output please let me know. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 20:14:06 2008 From: report at bugs.python.org (Jim Wilson) Date: Mon, 21 Jan 2008 19:14:06 -0000 Subject: [issue1884] msilib.SetProperty(msilib.PID_CODEPAGE, '1252') raises 0x65d = type mismatch In-Reply-To: <1200942846.08.0.229949051028.issue1884@psf.upfronthosting.co.za> Message-ID: <1200942846.08.0.229949051028.issue1884@psf.upfronthosting.co.za> New submission from Jim Wilson: I believe Codepage (a summary property which must be set *before* any other string value), is a string. Documentation admits it might also be an integer, but it doesn't matter. Both foo.SetProperty(PID_CODEPAGE, '1252') and foo.SetProperty(PID_CODEPAGE, 1252) raise "unknown error 65d". I believe 0x65d (1629d) to be ERROR_DATATYPE_MISMATCH. ---------- components: Build messages: 61440 nosy: Jimbo severity: normal status: open title: msilib.SetProperty(msilib.PID_CODEPAGE, '1252') raises 0x65d = type mismatch versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 20:29:41 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 19:29:41 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200943781.56.0.365314737021.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: The problem with atanh is that it should be using absx throughout, rather than x. So in "if (absx < 0.5)" branch and the following branch, replace all occurrences of x with absx, and it should work. One other comment: asinh shouldn't directly set errno for a NaN. It should do the same as acosh and atanh: return x+x. This makes asinh(float("nan")) return a nan, which makes it consistent with acosh and atanh, consistent with the way that Linux and OS X behave, and consistent with the other single-argument functions in math. I think asinh should also return x+x for x an infinity. This again should make it consistent with the way that the libm asinh works on OS X and Linux. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 20:39:58 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 19:39:58 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200944398.27.0.876465371891.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Also, for the C-level routines, atanh(1.0) and atanh(-1.0) should definitely return infinity and -infinity (and probably set errno as well.) Note that this is not an argument about what Python should do: Python will still raise a ValueError for atanh(1.0) and atanh(-1.0). But the atanh is supposed to be a drop-in replacement for the libm atanh, on those platforms where it's missing. And the C99 standard is clear about return values, even though it's not useful when it comes to deciding whether to set errno or not. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 21:14:03 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 20:14:03 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200946443.61.0.913968251162.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: One more comment: the Py_IS_NAN test in acosh is likely never reached, since the comparison x >= two_pow_p28 will probably evaluate to 0 when x is a NaN. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 21:42:15 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 20:42:15 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200948135.63.0.0562083307068.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Also: -1.0 shouldn't be returned at this level to indicate an error; these are pure C functions we're writing---the Python wrappers, and Python error conventions, apply further up the chain somewhere. Just so I'm doing something a little more constructive than yelling criticisms from the sideline, I've attached a file invhyp.c that's how I think the C functions should look. Some notes: - it doesn't touch errno, but lets the platform decide how to handle errors (i.e. produce a special value/set errno/signal a floating-point exception/some combination of these). This will make the asinh, acosh, atanh functions behave in the same way that the regular libm functions behave on any platform. So e.g. if a particular platform is used to setting errno for domain errors like sqrt(-1), it'll do so for atanh/asinh/acosh. And another platform that signals a floating-point exception for sqrt(-1) will do the same for atanh(3). - I've left in the "huge+x > 1.0" test in asinh; it's kinda pointless, but also fairly harmless. I think its only point is to make sure that the inexact flag gets set where appropriate, and Python doesn't much care about the inexact flag. - I'm reasonably sure that the test "x == 1." in acosh is safe. Added file: http://bugs.python.org/file9252/invhyp.c __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 21:43:32 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 21 Jan 2008 20:43:32 -0000 Subject: [issue1885] [distutils] - error when processing the "--formats=tar" option In-Reply-To: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za> Message-ID: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': Steps to reproduce the problem: 1: Run "python setup.py sdist --formats=gztar,tar". 2. dist directory now contains "module.gztar" and "module.tar" files as expected. 3: Run "python setup.py sdist --formats=tar,gztar". 4. dist directory now contains only "module.gztar" file. Reason: Since for every argument specified in "--formats" option a new .tar file is created every time by using the UNIX tar utility, the .tar file is removed/overwritten when creating subsequent archives. ---------- components: Distutils messages: 61445 nosy: giampaolo.rodola severity: normal status: open title: [distutils] - error when processing the "--formats=tar" option type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 21:52:58 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Jan 2008 20:52:58 -0000 Subject: [issue1715] Make pydoc list submodules In-Reply-To: <1199145132.63.0.00647784499418.issue1715@psf.upfronthosting.co.za> Message-ID: <1200948778.2.0.533868807111.issue1715@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, HtmlDoc already lists all module members in the inspected module (regardless of whether they are modules imported from outside or submodules defined inline). You can try it with the updated pydocfodder: >>> import pydoc >>> from test import pydocfodder >>> pydoc.writedoc(pydocfodder) wrote test.pydocfodder.html ... and check that test.pydocfodder.html contains a reference to test.pydocfodder.submodule. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 21:53:33 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Mon, 21 Jan 2008 20:53:33 -0000 Subject: [issue1878] class attribute cache failure (regression) In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za> Message-ID: <1200948813.56.0.0527175620509.issue1878@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: I personally think that this bug is a showstopper for the caching patch in 2.6. Well, the problem can be deemed insignificant, but it is sure a break of backward compatibility and, worse yet, it results in _very_ obscure fails. Even if type dictionary changes are not all that common, I'm sure there are extensions out there that do it. For Py3k things can be different. I'm not sure what would be the best way, but at least Py3k is not required to be compatible with 2.x in all aspects. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 22:03:29 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 21 Jan 2008 21:03:29 -0000 Subject: [issue1720595] Allow T_BOOL in PyMemberDef definitions Message-ID: <1200949409.91.0.793473697834.issue1720595@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I can't see anything wrong with the feature. Of course, the patch itself lacks changes to the test suite. Ideally, there would also be changes to the documentation, but as PyMemberDef seems to be undocumented currently, it's unfair to ask for documentation with this patch. If documentation was made, it should list for each T_ constant what the corresponding C type should be. I think the cast to long (in PyBool_FromLong) is redundant. ---------- assignee: loewis -> _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 22:06:04 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 21:06:04 -0000 Subject: [issue1715] Make pydoc list submodules In-Reply-To: <1199145132.63.0.00647784499418.issue1715@psf.upfronthosting.co.za> Message-ID: <1200949564.78.0.974051508573.issue1715@psf.upfronthosting.co.za> Georg Brandl added the comment: Well, I believe you. :) Committed r60178. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 22:24:24 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 21:24:24 -0000 Subject: [issue1720595] Allow T_BOOL in PyMemberDef definitions Message-ID: <1200950663.25.0.222280322838.issue1720595@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, added tests, removed the cast and committed in r60181. If I find time, I'll add docs for PyMemberDef in the next few days. ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 22:28:40 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 21 Jan 2008 21:28:40 -0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': Currently creating tar, gztar, bztar source distributions using the "--formats=tar,gztar,bztar" distutils option requires external utilities (tar and possibly one of gzip, bzip2, or compress) to be installed on the system since distutils uses them. This is not a problem on most UNIX systems which provide these utilities by default. On all other systems (e.g. Windows) it is required to install such utilities separately and have the executables available in a directory on your PATH in order to have them work. I discussed this on distutils mailing list [1] and tried to fix this hassle. The patch in attachment permit to use the distutils "--formats=tar,gztar,bztar" option without need of having tar/gzip/bzip2 utilities installed by using the tarfile module instead of os.spawn(). It also fixes bug #1885 [2]. [1] http://mail.python.org/pipermail/distutils-sig/2008-January/008654.html [2] http://bugs.python.org/issue1885 ---------- components: Distutils files: file.diff messages: 61451 nosy: giampaolo.rodola severity: normal status: open title: Permit to easily use distutils "--formats=tar,gztar,bztar" on all systems versions: Python 2.5 Added file: http://bugs.python.org/file9253/file.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 22:30:37 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 21 Jan 2008 21:30:37 -0000 Subject: [issue1885] [distutils] - error when processing the "--formats=tar" option In-Reply-To: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za> Message-ID: <1200951037.31.0.209876060717.issue1885@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I provided a patch here: http://bugs.python.org/issue1886 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 22:36:44 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 21 Jan 2008 21:36:44 -0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1200951404.34.0.246745774923.issue1706039@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: ---------- nosy: -draghuram _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 22:42:37 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Mon, 21 Jan 2008 21:42:37 -0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1200951757.79.0.168687724061.issue1886@psf.upfronthosting.co.za> Phillip J. Eby added the comment: On systems where the gzip or bz2 modules aren't installed, this patch can raise a tarfile.CompressionError, which should be caught and handled correctly. The import of tarfile should also be inside the relevant function (as is done for make_zipfile) instead of at the top level. Other than those two points, the patch looks great. ---------- nosy: +pje __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 22:57:29 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 21 Jan 2008 21:57:29 -0000 Subject: [issue479195] Put Demo/rpc/rpc.py into standard lib Message-ID: <1200952649.77.0.095653240403.issue479195@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I started looking at the bugs in chronological order in the hope that I can close some issues that don't make sense any more. Can I close this one? I am almost sure that this module is not going to be included in stdlib (I myself haven't used this module, though). ---------- nosy: +draghuram, gvanrossum ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 22:58:41 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 21:58:41 -0000 Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results Message-ID: <1200952721.7.0.906386089197.issue1678380@psf.upfronthosting.co.za> Mark Dickinson added the comment: This was fixed in the trunk in revision 57284. I've backported the fix to Python 2.5.2 in revision 60183. Leaving this open because there's still a problem for complex numbers, though I guess this is less likely to bite people: Python 2.6a0 (trunk:60158M, Jan 21 2008, 16:21:41) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0j 0j >>> -0j -0j >>> [0j, -0j] [0j, 0j] _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 22:59:43 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 21:59:43 -0000 Subject: [issue479195] Put Demo/rpc/rpc.py into standard lib Message-ID: <1200952783.79.0.84844469427.issue479195@psf.upfronthosting.co.za> Georg Brandl added the comment: Go ahead. ---------- nosy: +georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 23:02:08 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 21 Jan 2008 22:02:08 -0000 Subject: [issue479195] Put Demo/rpc/rpc.py into standard lib Message-ID: <1200952928.88.0.171964077038.issue479195@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Closing as there is no activity for long time and the request is unlikely to be accepted, anyway. ---------- resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 23:14:44 2008 From: report at bugs.python.org (Santiago Gala) Date: Mon, 21 Jan 2008 22:14:44 -0000 Subject: [issue1867] patch for pydoc to work in py3k In-Reply-To: <1200775479.14.0.705254713272.issue1867@psf.upfronthosting.co.za> Message-ID: <1200953678.32580.140.camel@localhost> Santiago Gala added the comment: El s?b, 19-01-2008 a las 20:44 +0000, Georg Brandl escribi?: > Georg Brandl added the comment: > > Fixed in r60100. > If the problem with the output of filter is solved at the call site I'd suggest the second hunk of: $ svn diff Lib/pydoc.py Index: Lib/pydoc.py =================================================================== --- Lib/pydoc.py (revisi?n: 60126) +++ Lib/pydoc.py (copia de trabajo) @@ -1192,7 +1192,7 @@ else: tag = "inherited from %s" % classname(thisclass, object.__module__) - filter(lambda t: not t[0].startswith('_'), attrs) + #filter(lambda t: not t[0].startswith('_'), attrs) # Sort attrs by name. attrs.sort() @@ -1972,9 +1972,8 @@ '#ffffff', '#7799ee') def bltinlink(name): return '%s' % (name, name) - names = filter(lambda x: x != '__main__', - sys.builtin_module_names) - contents = html.multicolumn(list(names), bltinlink) + names = [x for x in sys.builtin_module_names if x != '__main__'] + contents = html.multicolumn(names, bltinlink) indices = ['

' + html.bigsection( 'Built-in Modules', '#ffffff', '#ee77aa', contents)] instead, i.e. use a simple list comprehension instead of the filter expression (ugly) and list(names). The first hunk removes a useles expression, I'm not sure why it is there, but filter has no side effects. It looks like attrs = filter... is intended, but then, again a list comprehension would be clearer. Regards Santiago > ---------- > nosy: +georg.brandl > resolution: -> fixed > status: open -> closed > > __________________________________ > Tracker > > __________________________________ __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 21 23:15:49 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 21 Jan 2008 22:15:49 -0000 Subject: [issue491331] request sys.required_version Message-ID: <1200953749.68.0.12599419674.issue491331@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: should have been closed long time back :-). ---------- nosy: +draghuram resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 21 23:42:21 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Jan 2008 22:42:21 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200955341.43.0.434816178537.issue1703448@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure about the implications of Amaury's proposal, but in any case here is a patch which contains an unit test as well. (it seems to me swapping __stop() and __delete() can do no harm as there is no way for user code to be executed synchronously between both calls - unless you override one of these private methods) Added file: http://bugs.python.org/file9254/thrbug.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 23:48:35 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 21 Jan 2008 22:48:35 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200955715.66.0.833386318115.issue1703448@psf.upfronthosting.co.za> Georg Brandl added the comment: Guido, you wrote that code... ---------- assignee: rhettinger -> gvanrossum nosy: +georg.brandl, gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 21 23:58:31 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 22:58:31 -0000 Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results Message-ID: <1200956311.42.0.49777107844.issue1678380@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a patch, against the trunk, that imitates Alex's fix for the complex case. ---------- keywords: +patch Added file: http://bugs.python.org/file9255/plus_minus_0j.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 00:16:10 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 21 Jan 2008 23:16:10 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za> Message-ID: <1200957370.7.0.526246311448.issue1327@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: What is the length of the response? in verbose mode, you must read a line like: header: Content-length: 623329 Note that I managed to produce the same kind of output as the one you showed, with a size of ~600Kb. And the whole request takes less that 1 second. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 00:19:33 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 21 Jan 2008 23:19:33 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200957573.64.0.369256652362.issue1703448@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Hm, this is multithreading. There is still the possibility of a switch between the two calls. In this case the thread is not marked as stopped, but enumerate() does not return it. Not easy to reproduce, though. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 00:22:31 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Jan 2008 23:22:31 -0000 Subject: [issue1678668] fix a bug mixing up 0.0 and-0.0 Message-ID: <1200957751.23.0.885531878988.issue1678668@psf.upfronthosting.co.za> Mark Dickinson added the comment: This can be closed, I think: it's already been fixed in the trunk (with a different fix, also due to Alex, from the one given here) and the fix has been backported to 2.5.2. Not sure what the appropriate resolution is here; plumping for 'out of date'. ---------- resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 00:34:21 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Jan 2008 23:34:21 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200958461.66.0.7919579363.issue1703448@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > There is still the possibility of a switch > between the two calls. In this case the thread is not marked as stopped, > but enumerate() does not return it. But user code is unlikely to rely on this because in most cases the thread *will* be marked as stopped ;) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 00:42:06 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Jan 2008 23:42:06 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200958926.18.0.777130992937.issue1703448@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oops, sorry Amaury, I got your remark backwards. Nevermind... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 00:42:51 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 21 Jan 2008 23:42:51 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200958971.74.0.73456978355.issue1703448@psf.upfronthosting.co.za> Gregory P. Smith added the comment: why not just do this? finally: with _active_limbo_lock: self.__stop() try: self.__delete() except: pass (i believe with works on locks? if not turn that into an acquire, try: finally: release) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 00:48:54 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 21 Jan 2008 23:48:54 -0000 Subject: [issue1221598] ftplib storbinary/storlines callback function Message-ID: <1200959334.28.0.328892440273.issue1221598@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 01:05:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2008 00:05:35 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200960335.08.0.080846315856.issue1703448@psf.upfronthosting.co.za> Antoine Pitrou added the comment: __delete() already acquires _active_limbo_lock so your proposal must be changed for the following: with _active_limbo_lock: self.__stop() try: del _active[_get_ident()] except: pass However, with this slight correction it seems to work. I was worrying whether another thread could hold __block (which is acquired in __stop()) while waiting for _active_limbo_lock to be released, but AFAICT there doesn't seem to be a code path where it can happen... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 01:12:19 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2008 00:12:19 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200960739.76.0.0611219477765.issue1703448@psf.upfronthosting.co.za> Changes by Antoine Pitrou: Added file: http://bugs.python.org/file9256/thrbug2.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 01:20:22 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 22 Jan 2008 00:20:22 -0000 Subject: [issue1221598] ftplib storbinary/storlines callback function Message-ID: <1200961221.99.0.163982615852.issue1221598@psf.upfronthosting.co.za> Gregory P. Smith added the comment: accepted, committed as svn r60188 for 2.6. I also cleaned up the retr* and stor* doc strings. ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 01:31:59 2008 From: report at bugs.python.org (Monty Taylor) Date: Tue, 22 Jan 2008 00:31:59 -0000 Subject: [issue1887] distutils doesn't support out-of-source builds In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za> Message-ID: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za> New submission from Monty Taylor: I've been using distutils as part of a larger automake-managed project. One of the functions that automake provides is "make distcheck" which it has been especially hard to get distutils to play along with. So I added a src-dir option to allow for passing src dir to the build. ---------- components: Distutils files: distutils.patch messages: 61471 nosy: sdirector severity: normal status: open title: distutils doesn't support out-of-source builds versions: Python 2.5 Added file: http://bugs.python.org/file9257/distutils.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 01:57:14 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 00:57:14 -0000 Subject: [issue1887] distutils doesn't support out-of-source builds In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za> Message-ID: <1200963434.16.0.851201407361.issue1887@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch priority: -> normal type: -> rfe versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 01:57:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 00:57:58 -0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1200963478.58.0.20814934958.issue1886@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch priority: -> normal type: -> rfe versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 01:59:30 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 00:59:30 -0000 Subject: [issue1885] [distutils] - error when processing the "--formats=tar" option In-Reply-To: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za> Message-ID: <1200963570.51.0.247011486814.issue1885@psf.upfronthosting.co.za> Christian Heimes added the comment: No need to keep two buss open. ---------- nosy: +tiran priority: -> normal resolution: -> duplicate status: open -> closed superseder: -> Permit to easily use distutils "--formats=tar,gztar,bztar" on all systems versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 02:00:36 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 01:00:36 -0000 Subject: [issue1884] msilib.SetProperty(msilib.PID_CODEPAGE, '1252') raises 0x65d = type mismatch In-Reply-To: <1200942846.08.0.229949051028.issue1884@psf.upfronthosting.co.za> Message-ID: <1200963636.32.0.0647649169789.issue1884@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> loewis components: +Windows nosy: +loewis priority: -> low type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 02:29:21 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 22 Jan 2008 01:29:21 -0000 Subject: [issue1703448] "t.join(); assert t not in threading.enumerate()" fails Message-ID: <1200965361.87.0.942929906246.issue1703448@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Looks good. Fixed in r60190 (2.6). And r60191 for release25-maint (2.5.2). ---------- assignee: gvanrossum -> gregory.p.smith keywords: +patch resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 02:42:01 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 01:42:01 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1200948135.63.0.0562083307068.issue1640@psf.upfronthosting.co.za> Message-ID: <479549E4.9060900@cheimes.de> Christian Heimes added the comment: Mark Dickinson wrote: > - it doesn't touch errno, but lets the platform decide how to handle errors (i.e. produce a > special value/set errno/signal a floating-point exception/some combination of these). This will > make the asinh, acosh, atanh functions behave in the same way that the regular libm functions > behave on any platform. So e.g. if a particular platform is used to setting errno for domain > errors like sqrt(-1), it'll do so for atanh/asinh/acosh. And another platform that signals a > floating-point exception for sqrt(-1) will do the same for atanh(3). I tried your patch. It fixes the problem with atanh0022 and 0023 test but it breaks in other places. math.acosh(0) returns NaN and does NOT raise an exception. math.atanh(1) raises OverflowError instead of ValueError. The libm of uclibc *does* set errno for signaling NaN. The relevant code is in w_acos.c and k_standard.c. I don't know how emit a signal for a NaN but setting errno sounds reasonable for me and it gives the desired output. w_acosh.c: double acosh(double x) /* wrapper acosh */ { #ifdef _IEEE_LIBM return __ieee754_acosh(x); #else double z; z = __ieee754_acosh(x); if(_LIB_VERSION == _IEEE_ || isnan(x)) return z; if(x<1.0) { return __kernel_standard(x,x,29); /* acosh(x<1) */ } else return z; #endif } kernel_standard: case 129: /* acosh(x<1) */ exc.type = DOMAIN; exc.name = type < 100 ? "acosh" : "acoshf"; exc.retval = zero/zero; if (_LIB_VERSION == _POSIX_) errno = EDOM; else if (!matherr(&exc)) { if (_LIB_VERSION == _SVID_) { (void) WRITE2("acosh: DOMAIN error\n", 20); } errno = EDOM; } break; __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 02:53:47 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 01:53:47 -0000 Subject: [issue614557] LookupError etc. need API to get the key Message-ID: <1200966827.89.0.874328922304.issue614557@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think it would be a good idea to revisit this for py3k, but I'm out of round tuits. Anyone else want to tackle this? It should ideally be done in such a way that non-core object types can also easily raise these exceptions with the appropriate attributes, both from C and from Python. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Jan 22 02:58:18 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 01:58:18 -0000 Subject: [issue1473257] Add a gi_code attr to generators Message-ID: <1200967098.49.0.49352366655.issue1473257@psf.upfronthosting.co.za> Guido van Rossum added the comment: I noticed some whitespace issues in the patch, but apart from that I have no objection. (Not any particular enthusiasm, I have to admit -- I don't quite get the use case, but as Georg remarks, it seems harmless.) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 03:00:09 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 02:00:09 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za> Message-ID: <1200967209.5.0.945554560522.issue1336@psf.upfronthosting.co.za> Guido van Rossum added the comment: Was this a security fix? We aren't supposed to backport non-security fixes to 2.4, and Martin is actually planning to *reverse* the non-security patches applied to 2.4 since 2.4.4 was released, to make it easier to release a "pure security" source tree. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 03:01:48 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 02:01:48 -0000 Subject: [issue1124] Webchecker not parsing css "@import url" In-Reply-To: <1189128543.92.0.989336234213.issue1124@psf.upfronthosting.co.za> Message-ID: <1200967308.56.0.198053144333.issue1124@psf.upfronthosting.co.za> Guido van Rossum added the comment: If someone is still interested in webchecker, they should start a fork. Let's remove it from 3.0. At this point it's so old, it's probably dangerous. ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 03:10:30 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 22 Jan 2008 02:10:30 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za> Message-ID: <1200967830.3.0.445190926477.issue1640@psf.upfronthosting.co.za> Mark Dickinson added the comment: Hmmm. For atanh(1): raising OverflowError is actually consistent with what currently happens. The only singularity that's already present in math is log(0), and it seems that that raises OverflowError on OS X, Linux and Windows... I wonder whether this is what Tim meant to say? For acosh(0): you're right, and I'm wrong---this should definitely return a NaN and set errno. I guess that dividing 0 by 0 doesn't set errno on Windows. Okay: let's set it directly there. I do still think that asinh(nan), atanh(nan) and acosh(nan) should return nan and not raise any exceptions, just for the sake of consistency with Linux/OS X and with the other libm functions. I guess I don't really care about asinh(+/-inf), etc: an infinite return value will be caught by the stuff in math_1 anyway. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 03:22:45 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 22 Jan 2008 02:22:45 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za> Message-ID: <1200968565.94.0.704404043133.issue1336@psf.upfronthosting.co.za> Gregory P. Smith added the comment: oh, whoops. not a security issue. should i undo it or let Martin? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 04:04:23 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 03:04:23 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za> Message-ID: <1200971063.62.0.693330412468.issue1336@psf.upfronthosting.co.za> Guido van Rossum added the comment: Martin can do it all in one fell sweep. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 04:12:43 2008 From: report at bugs.python.org (Lee June) Date: Tue, 22 Jan 2008 03:12:43 -0000 Subject: [issue1888] strange 'global' In-Reply-To: <1200971563.65.0.992284576383.issue1888@psf.upfronthosting.co.za> Message-ID: <1200971563.65.0.992284576383.issue1888@psf.upfronthosting.co.za> New submission from Lee June: hi, all. my friend found a strange behave with 'global', I posted it in the 'python-list at python.org' as this: [quote] why the following 2 prg give different results? a.py is ok, but b.py is 'undefiend a' I am using Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 #a.py def run(): if 1==2: # note, it always False global a a=1 run() a #b.py def run(): a=1 run() a [/quote] I believe that is bug which breaks the consistency of python syntax and common english langauge sense- just like we can do '1>None' in python2.x, but not in python 3.x. So please fix this bug. If you do think that is the feature of python and refuse to fix it, please at least mention the craziness in the document. Uhm, maybe I can do the later, but I don't think it is good. btw, there are some replies(you can search them in the archive), I think the other users met more questions, for example From: "Gabriel Genellina" To: python-list at python.org Date: Mon, 21 Jan 2008 18:36:19 -0200 Subject: Re: problem with 'global' En Mon, 21 Jan 2008 17:36:29 -0200, Duncan Booth escribi?: > Marc 'BlackJack' Rintsch wrote: > >> On Mon, 21 Jan 2008 17:08:46 -0200, Gabriel Genellina wrote: >> >>> The future statement is another example, even worse: >>> >>> if 0: >>> from __future__ import with_statement >>> >>> with open("xxx") as f: >>> print f >> >> In Python >=2.5 it's a compile time error if that import is not the very >> first statement in a source file. >> > That doesn't appear to be the case. With Python 2.5.1 the example > Gabriel quoted will compile and run. Yes, but now I've noticed that the 0 has some magic. The code above works with 0, 0.0, 0j and ''. Using None, False, () or [] as the condition, will trigger the (expected) syntax error. Mmm, it may be the peephole optimizer, eliminating the dead branch. This function has an empty body: def f(): if 0: print "0" if 0.0: print "0.0" if 0j: print "0j" if '': print "empty" py> dis.dis(f) 5 0 LOAD_CONST 0 (None) 3 RETURN_VALUE The other false values tested (False, None, () and []) aren't optimized out. -- Gabriel Genellina ---------- components: Interpreter Core messages: 61482 nosy: oyster severity: major status: open title: strange 'global' type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 04:24:28 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 03:24:28 -0000 Subject: [issue1888] strange 'global' In-Reply-To: <1200971563.65.0.992284576383.issue1888@psf.upfronthosting.co.za> Message-ID: <1200972268.9.0.719447613277.issue1888@psf.upfronthosting.co.za> Guido van Rossum added the comment: This isn't going to change. 'global' is one of those rare pieces of syntax that are not executed by the interpreter but detected by the parser. Note that there are other things like this, e.g. the presence of 'yield' in a function makes it a generator. FWIW, the "if 0:" issue is different; that's a genuine bug, see issue #1875. ---------- nosy: +gvanrossum resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 04:28:41 2008 From: report at bugs.python.org (Andrew Dalke) Date: Tue, 22 Jan 2008 03:28:41 -0000 Subject: [issue1889] string literal documentation differs from implementation In-Reply-To: <1200972521.05.0.240928400296.issue1889@psf.upfronthosting.co.za> Message-ID: <1200972521.05.0.240928400296.issue1889@psf.upfronthosting.co.za> New submission from Andrew Dalke: The reference manual documentation for raw string literals says """Note also that a single backslash followed by a newline is interpreted as those two characters as part of the string, *not* as a line continuation.""" This is not the observed behavior. >>> s = """ABC\ ... 123""" >>> s 'ABC123' >>> Line continuations are ignored by triple quoted strings. In addition, the reference manual documentation for "\x" escapes says | ``\xhh`` | Character with hex value *hh* | (4,5) | where footnote (4) stays Unlike in Standard C, at most two hex digits are accepted. However, the implementation requires exactly two hex digits: >>> "\x41" 'A' >>> "\x4." ValueError: invalid \x escape >>> "\x4" ValueError: invalid \x escape >>> ---------- components: Documentation messages: 61484 nosy: dalke severity: minor status: open title: string literal documentation differs from implementation versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 05:19:17 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 04:19:17 -0000 Subject: [issue1889] string literal documentation differs from implementation In-Reply-To: <1200972521.05.0.240928400296.issue1889@psf.upfronthosting.co.za> Message-ID: <1200975557.54.0.463247414032.issue1889@psf.upfronthosting.co.za> Guido van Rossum added the comment: Your example does not use a "raw" string -- a raw string has an 'r' in front of the opening string quotes. Try this instead: >>> s = r"""a\ ... b""" >>> s 'a\\\nb' Your second issue is correct -- the definition of \xXX in Python has changed over the years to what you observed. I still don't think it matches the C standard though. :-) Assigning to Georg for a doc fixup. I'm assuming this is also for higher Python versions. ---------- assignee: -> georg.brandl keywords: +easy nosy: +georg.brandl, gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 08:54:42 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 22 Jan 2008 07:54:42 -0000 Subject: [issue1889] string literal documentation differs from implementation In-Reply-To: <1200972521.05.0.240928400296.issue1889@psf.upfronthosting.co.za> Message-ID: <1200988482.84.0.420268788562.issue1889@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60193, r60194 (2.5). ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 09:35:45 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 22 Jan 2008 08:35:45 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> Message-ID: <1200990945.58.0.659160992336.issue1881@psf.upfronthosting.co.za> Ralf Schmitt added the comment: yes, here it is. I've added the tests to Lib/test/test_parser. BTW, is it possible to trigger a segfault by constructing a parser.st object and calling compile on it? Added file: http://bugs.python.org/file9258/up-maxstack+tests.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 09:37:36 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 22 Jan 2008 08:37:36 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> Message-ID: <1200991056.33.0.553743411437.issue1881@psf.upfronthosting.co.za> Ralf Schmitt added the comment: one more. this program seems to leak memory: x=1000 e="["*x+"]"*x while 1: try: eval(e) except MemoryError: pass __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 09:43:43 2008 From: report at bugs.python.org (Maciek Fijalkowski) Date: Tue, 22 Jan 2008 08:43:43 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> Message-ID: <1200991423.88.0.0793636542752.issue1881@psf.upfronthosting.co.za> Maciek Fijalkowski added the comment: Attached file that handles stack overflow slightly better (from pypy). It really measures stack size, not some arbitrary limit of python calls. Yes, this have slightly bigger overhead than just passing around number, but as a side effect solves Lib/test/crashers/recursion_limit_too_high.py ---------- nosy: +fijal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 09:55:16 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 08:55:16 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200991423.88.0.0793636542752.issue1881@psf.upfronthosting.co.za> Message-ID: <4795AF70.40209@cheimes.de> Christian Heimes added the comment: Maciek Fijalkowski wrote: > Maciek Fijalkowski added the comment: > > Attached file that handles stack overflow slightly better (from pypy). > It really measures stack size, not some arbitrary limit of python calls. > Yes, this have slightly bigger overhead than just passing around number, > but as a side effect solves Lib/test/crashers/recursion_limit_too_high.py Where is the file? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 09:57:49 2008 From: report at bugs.python.org (Maciek Fijalkowski) Date: Tue, 22 Jan 2008 08:57:49 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za> Message-ID: <1200992269.45.0.0469496144108.issue1881@psf.upfronthosting.co.za> Maciek Fijalkowski added the comment: Wuaaa, sorry Added file: http://bugs.python.org/file9259/stack.h __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 11:12:35 2008 From: report at bugs.python.org (Steve Purcell) Date: Tue, 22 Jan 2008 10:12:35 -0000 Subject: [issue1034053] unittest.py patch: add skipped test functionality Message-ID: <1200996755.5.0.901580593584.issue1034053@psf.upfronthosting.co.za> Steve Purcell added the comment: The status of this ticket is unchanged. I'm somewhat removed from the Python scene in recent times, and I'm not in a position to apply this patch or a variation of it. I still believe this would be a beneficial change to the unittest module, though, and perhaps someone else would be willing to apply Remy's patch (updated if necessary to apply cleanly). There's a minor typo in there ("tuble" instead of "tuple"), but otherwise it looks acceptable to me. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 11:16:21 2008 From: report at bugs.python.org (Steve Purcell) Date: Tue, 22 Jan 2008 10:16:21 -0000 Subject: [issue1705520] pyunit should allow __unittest in locals to trim stackframes Message-ID: <1200996981.54.0.729702405429.issue1705520@psf.upfronthosting.co.za> Steve Purcell added the comment: This is a good idea, but slightly messy. A better solution would be for unittest to provide a decorator that could be used to mark assertion functions. Internally, that decorator may well work the way you describe. Given a corresponding patch, someone with more time than myself may well be willing to commit it. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 11:32:12 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 22 Jan 2008 10:32:12 -0000 Subject: [issue1883] Adapt pydoc to new doc system In-Reply-To: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za> Message-ID: <1200997932.67.0.807514015449.issue1883@psf.upfronthosting.co.za> Changes by Guilherme Polo: ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 11:32:20 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 22 Jan 2008 10:32:20 -0000 Subject: [issue1883] Adapt pydoc to new doc system In-Reply-To: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za> Message-ID: <1200997940.98.0.76697117449.issue1883@psf.upfronthosting.co.za> Changes by Guilherme Polo: ---------- type: behavior -> __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 11:47:00 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 10:47:00 -0000 Subject: [issue1902] Test In-Reply-To: <1200998820.47.0.13912653563.issue1902@psf.upfronthosting.co.za> Message-ID: <1200998820.47.0.13912653563.issue1902@psf.upfronthosting.co.za> New submission from Christian Heimes: ggpolo has reported an issue with the bug tracker ---------- messages: 61494 nosy: tiran severity: normal status: open title: Test __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 11:47:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 10:47:15 -0000 Subject: [issue1902] Test In-Reply-To: <1200998820.47.0.13912653563.issue1902@psf.upfronthosting.co.za> Message-ID: <1200998835.79.0.802717479518.issue1902@psf.upfronthosting.co.za> Christian Heimes added the comment: Works for me ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 11:54:03 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 22 Jan 2008 10:54:03 -0000 Subject: [issue1904] Add key argument to heapq functions In-Reply-To: <1200999243.33.0.342848472968.issue1904@psf.upfronthosting.co.za> Message-ID: <1200999243.33.0.342848472968.issue1904@psf.upfronthosting.co.za> New submission from Guilherme Polo: Wouldn't it be useful to add a "key" argument to some heapq functions ? So you could construct a heap from dict items list based on the second item of each tuple, for example. ---------- components: Library (Lib) messages: 61496 nosy: gpolo severity: normal status: open title: Add key argument to heapq functions type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 12:09:30 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 22 Jan 2008 11:09:30 -0000 Subject: [issue1904] Add key argument to heapq functions In-Reply-To: <1200999243.33.0.342848472968.issue1904@psf.upfronthosting.co.za> Message-ID: <1201000170.27.0.282307703485.issue1904@psf.upfronthosting.co.za> Guilherme Polo added the comment: Adding a simple patch that adds the "key" argument. To test this you need to comment lines where it tries to import the C version of heapq. Added file: http://bugs.python.org/file9260/heapq_key.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 12:10:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 11:10:56 -0000 Subject: [issue1640] Enhancements for mathmodule In-Reply-To: <1200967830.3.0.445190926477.issue1640@psf.upfronthosting.co.za> Message-ID: <4795CF3B.9090405@cheimes.de> Christian Heimes added the comment: Mark Dickinson wrote: > For atanh(1): raising OverflowError is actually consistent with what currently happens. > The only singularity that's already present in math is log(0), and it seems that that > raises OverflowError on OS X, Linux and Windows... I wonder whether this is what Tim > meant to say? But on Linux atanh(1) sets errno = EDOM and raises a ValueError. Either the outcome is not consistent or the libm developers have a different philosophy than Time and you. *g* > For acosh(0): you're right, and I'm wrong---this should definitely return a NaN and set > errno. I guess that dividing 0 by 0 doesn't set errno on Windows. Okay: let's set it > directly there. I'm not an expert on IEEE754 and NaN but I guess "Signaling NaN" also means it sets errno. Personally I'm not interested in reimplementing or fixing Windows' mathematical library (although it's tempting *g*) but to get the results right for our purpose. You are right, we should try to mimic the C99 standard whenever it is possible. But it's more important to get the functions of our math module right. > I do still think that asinh(nan), atanh(nan) and acosh(nan) should return nan and not > raise any exceptions, just for the sake of consistency with Linux/OS X and with the other > libm functions. Yes, it makes perfectly sense and glibc's libm already does the right thing. However Windows screws up again so I've to fix the function call manually. Damn you Windows! I inserted the four lines in mathmodule.c:math_1() and something similar in math_2() to fix Windows. #ifndef __GNUC__ /* Windows et al */ if (Py_IS_NAN(x)) return PyFloat_FromDouble(x+x); #endif > I guess I don't really care about asinh(+/-inf), etc: an infinite return value will be > caught by the stuff in math_1 anyway. Are you fine with OverflowError? I'm going to create a branch for your work. It's getting tedious sending large patches back and forth. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 12:17:01 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 11:17:01 -0000 Subject: [issue1381] cmath is numerically unsound In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za> Message-ID: <1201000621.69.0.0213787286103.issue1381@psf.upfronthosting.co.za> Christian Heimes added the comment: See #1640 and svn+ssh://pythondev at svn.python.org/python/branches/trunk-math ---------- components: +Extension Modules -Library (Lib) keywords: +patch priority: -> normal versions: +Python 3.0 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 12:20:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 11:20:21 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <1200992269.45.0.0469496144108.issue1881@psf.upfronthosting.co.za> Message-ID: <4795D172.7070709@cheimes.de> Christian Heimes added the comment: Maciek Fijalkowski wrote: > Wuaaa, sorry > > Added file: http://bugs.python.org/file9259/stack.h Can you provide a working patch, please? The file doesn't explain how it should be plugged into the parser. What's the license of the file? We can't just add code from another project. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 12:29:14 2008 From: report at bugs.python.org (Maciek Fijalkowski) Date: Tue, 22 Jan 2008 11:29:14 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <4795D172.7070709@cheimes.de> Message-ID: <4795D37E.5010201@genesilico.pl> Maciek Fijalkowski added the comment: PyPy is all MIT, no problem at license. This should not be plugged into the parser, this is not a patch (especially not a patch for the parser). This file is rather to illustrate possible solution to solve the problem of sys.setrecursionlimit not being a robust solution, but just a quick hack. Instead of having a counter (which is sometimes too big, sometimes too small, depending on amount of C code in between the stack checks), it provides a way of measuring the size of a stack actually used. The idea is to store the address of local variable somewhere in the beginning and compare it to addresses of local variables in consecutive calls to LL_stack_too_big (all stored per-thread). This seems to be a better solution (ie pypy does not segfault on any of Lib/test/crashers, particularly not on ones involving unevident C infinite loop). Yes, it has some performance penalty (hard to tell exactly what without trying). Hum, this indeed might be not a best place to have such discussion, what about moving this to another, more general issue? Cheers, fijal :. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 12:47:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 11:47:08 -0000 Subject: [issue1881] increase parser stack limit In-Reply-To: <4795D37E.5010201@genesilico.pl> Message-ID: <4795D7B4.2020304@cheimes.de> Christian Heimes added the comment: Maciek Fijalkowski wrote: > Hum, this indeed might be not a best place to have such discussion, what > about moving this to another, more general issue? Ah! :) It took me a while to understand your intention but now I get you! The python-dev mailing list is probably a better place than the bug tracker. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 14:25:30 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 22 Jan 2008 13:25:30 -0000 Subject: [issue1087741] subclassable mmap Message-ID: <1201008330.13.0.467229349464.issue1087741@psf.upfronthosting.co.za> Ralf Schmitt added the comment: sorry, I somehow managed to introduce a segfault: ~/pydev/trunk/ cat t.py ralf at red ok from mmap import mmap class anon_mmap(mmap): def __new__(klass, *args, **kwargs): res = mmap.__new__(klass, -1, *args, **kwargs) print "NEW:", res return res anon_mmap(4096) ~/pydev/trunk/ ./python t.py ralf at red ok NEW: <__main__.anon_mmap object at 0x866b10> Debug memory block at address p=0x866b10: 18374686479671623679 bytes originally requested The 8 pad bytes at p-8 are not all FORBIDDENBYTE (0xfb): at p-8: 0xcb *** OUCH at p-7: 0xcb *** OUCH at p-6: 0xcb *** OUCH at p-5: 0xcb *** OUCH at p-4: 0xcb *** OUCH at p-3: 0xcb *** OUCH at p-2: 0xcb *** OUCH at p-1: 0xcb *** OUCH Because memory is corrupted at the start, the count of bytes requested may be bogus, and checking the trailing pad bytes may segfault. The 8 pad bytes at tail=0xff00000000866b0f are zsh: segmentation fault ./python t.py The following fixes it for me: ~/pydev/trunk/ cat patch ralf at red failed 139 diff --git a/Modules/mmapmodule.c b/Modules/mmapmodule.c --- a/Modules/mmapmodule.c +++ b/Modules/mmapmodule.c @@ -129,7 +129,7 @@ mmap_object_dealloc(mmap_object *m_obj) } #endif /* UNIX */ - PyObject_Del(m_obj); + m_obj->ob_type->tp_free((PyObject*)m_obj); } static PyObject * I'll write a test for this issue and will attach a complete patch. Sorry again. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 14:34:12 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 22 Jan 2008 13:34:12 -0000 Subject: [issue1087741] subclassable mmap Message-ID: <1201008852.92.0.275811439257.issue1087741@psf.upfronthosting.co.za> Changes by Ralf Schmitt: Added file: http://bugs.python.org/file9261/subclass_mmap_patch.txt _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 14:35:36 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 22 Jan 2008 13:35:36 -0000 Subject: [issue1087741] subclassable mmap Message-ID: <1201008936.66.0.871614815836.issue1087741@psf.upfronthosting.co.za> Ralf Schmitt added the comment: ./python Lib/test/test_mmap.py works with a debug build with this patch. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 15:08:34 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 22 Jan 2008 14:08:34 -0000 Subject: [issue487738] weaklist Message-ID: <1201010914.92.0.635996124703.issue487738@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Facundo: Agreed as well; since the use case isn't strong, let's avoid adding this. ---------- resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Jan 22 15:35:01 2008 From: report at bugs.python.org (Kevin Walzer) Date: Tue, 22 Jan 2008 14:35:01 -0000 Subject: [issue1905] PythonLauncher not working correctly on OS X 10.5/Leopad In-Reply-To: <1201012501.41.0.744457037048.issue1905@psf.upfronthosting.co.za> Message-ID: <1201012501.41.0.744457037048.issue1905@psf.upfronthosting.co.za> New submission from Kevin Walzer: On Mac OS X 10.5 (Leopard), using Python 2.5.1, double-clicking on a Python script in the Finder does not produce the expected behavior, i.e. launch a terminal session and then execute the script. These errors are logged in the console: 1/22/08 9:28:56 AM Python Launcher[53692] doscript: Could not activate Terminal 1/22/08 9:28:56 AM Python Launcher[53692] doscript: AESend(activate): error -600 1/22/08 9:28:56 AM Python Launcher[53692] Exit status: -600 1/22/08 9:28:56 AM com.apple.launchd[118] ([0x0- 0x434434].org.python.PythonLauncher[53692]) Stray process with PGID equal to this dead job: PID 53694 PPID 1 Terminal I did not observe these behaviors on OS X 10.4. ---------- components: Macintosh messages: 61506 nosy: wordtech severity: major status: open title: PythonLauncher not working correctly on OS X 10.5/Leopad type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 15:47:57 2008 From: report at bugs.python.org (Eric Sammons) Date: Tue, 22 Jan 2008 14:47:57 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za> Message-ID: <1201013277.49.0.498413272506.issue1327@psf.upfronthosting.co.za> Eric Sammons added the comment: Here is the header information that I get: reply: 'HTTP/1.1 200 OK\r\n' header: Date: Tue, 22 Jan 2008 14:42:54 GMT header: Server: Apache header: Content-Length: 183 header: Content-Type: text/xml;charset=UTF-8 Then I get addition send followed by more header info: reply: 'HTTP/1.1 200 OK\r\n' header: Date: Tue, 22 Jan 2008 14:42:54 GMT header: Server: Apache header: Content-Length: 399191 header: Content-Type: text/xml;charset=UTF-8 header: X-Pad: avoid browser bug I am looking for additional Content-Length data. Also, the above was done using Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11). Thank you! __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 15:52:36 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Jan 2008 14:52:36 -0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1201013556.16.0.861673060139.issue1886@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Both things fixed. The new patch is in attachment. Just one thing: I tried a diff between a tar.gz file generated by tarfile module and another one generated by the UNIX tar utility and it seems there are some differences. I don't know if this could represent a problem for distributions generated by distutils and eventually easy_install.py integration. Maybe someone who knows the tarfile implementation could clarify this point. ---------- nosy: +lars.gustaebel, nnorwitz Added file: http://bugs.python.org/file9262/patch.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 15:58:21 2008 From: report at bugs.python.org (Eric Sammons) Date: Tue, 22 Jan 2008 14:58:21 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za> Message-ID: <1201013901.23.0.447891790503.issue1327@psf.upfronthosting.co.za> Eric Sammons added the comment: Some strace data: WORKS: strace -cf ./test.py >/tmp/out Process 9439 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 33.10 0.009125 8 1086 956 open 23.47 0.006469 7 930 recvfrom 9.67 0.002667 9 311 278 stat 8.10 0.002234 14 165 read 3.40 0.000936 7 133 mmap 3.25 0.000896 6 144 close 3.24 0.000892 45 20 poll 2.97 0.000818 5 173 fstat 2.83 0.000780 15 53 munmap 2.13 0.000588 118 5 3 execve 1.34 0.000369 9 39 mprotect 1.13 0.000312 4 72 rt_sigaction 0.66 0.000183 5 35 futex 0.64 0.000176 10 17 brk 0.61 0.000169 12 14 sendto 0.57 0.000158 26 6 write 0.50 0.000139 4 34 fcntl 0.49 0.000134 10 14 socket 0.40 0.000111 4 25 lseek 0.36 0.000100 7 14 2 connect 0.34 0.000093 23 4 getdents64 0.27 0.000074 5 14 2 ioctl 0.17 0.000048 4 11 gettimeofday 0.06 0.000016 8 2 2 access 0.05 0.000014 7 2 2 readlink 0.04 0.000010 5 2 arch_prctl 0.04 0.000010 5 2 time 0.03 0.000009 9 1 _sysctl 0.03 0.000008 8 1 lstat 0.03 0.000008 4 2 uname 0.02 0.000006 6 1 rt_sigprocmask 0.02 0.000006 6 1 getcwd 0.01 0.000004 4 1 getrlimit 0.01 0.000004 4 1 set_tid_address ------ ----------- ----------- --------- --------- ---------------- 100.00 0.027566 3335 1245 total I am still compiling the same data for Python 2.4.3 (#1, Dec 11 2006, 11:39:03). However, this could take hours... as 2.4+ seem to be problematic. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 16:06:20 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 22 Jan 2008 15:06:20 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za> Message-ID: <1201014380.63.0.785119080662.issue1327@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Please, could you use the python profiler instead? Since most of the time is spent in the bytecode interpreter, the results are much more meaningful. Something like: #!/usr/bin/env python import xmlrpclib import profile u = 'someuser' p = 'password' server_url = 'http://rhn.redhat.com/rpc/api' def f(): server = xmlrpclib.Server(server_url) session = server.auth.login(u,p) l = server.channel.listSoftwareChannels(session) for a in l: print a['channel_label'] def g(): try: f() except: pass profile.run("g()") __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 16:19:30 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 15:19:30 -0000 Subject: [issue1906] Distinguish between cfunction, cvar and cmacro In-Reply-To: <1201015170.0.0.526066716057.issue1906@psf.upfronthosting.co.za> Message-ID: <1201015170.0.0.526066716057.issue1906@psf.upfronthosting.co.za> New submission from Christian Heimes: The new doc system has cmacro but the html output for cmacro is not distinguishable from cfunction. I also noticed that the docs use cfunction instead of cmacro on several occasions. ---------- assignee: georg.brandl components: Documentation messages: 61511 nosy: georg.brandl, tiran priority: normal severity: normal status: open title: Distinguish between cfunction, cvar and cmacro type: rfe versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 16:37:36 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 15:37:36 -0000 Subject: [issue1904] Add key argument to heapq functions In-Reply-To: <1200999243.33.0.342848472968.issue1904@psf.upfronthosting.co.za> Message-ID: <1201016256.99.0.361842354638.issue1904@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> rhettinger keywords: +patch nosy: +rhettinger priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 16:57:57 2008 From: report at bugs.python.org (Guillaume Nourry-Marquis) Date: Tue, 22 Jan 2008 15:57:57 -0000 Subject: [issue1907] Httplib.py not supporting timeout - Propose Fix attached In-Reply-To: <1201017477.23.0.0342238589364.issue1907@psf.upfronthosting.co.za> Message-ID: <1201017477.23.0.0342238589364.issue1907@psf.upfronthosting.co.za> New submission from Guillaume Nourry-Marquis: The httplib file wasn'T supporting a timeout feature which was essential for my load testing application I built. In order to do that, I had to append a parameter to the connect function, which takes a socket timeout value integer in seconds. def connect(self,timeout=None): """Connect to the host and port specified in __init__.""" msg = "getaddrinfo returns an empty list" for res in socket.getaddrinfo(self.host, self.port, 0, socket.SOCK_STREAM): af, socktype, proto, canonname, sa = res try: self.sock = socket.socket(af, socktype, proto) #Guillaume's timeout self.sock.settimeout(timeout) if self.debuglevel > 0: print "connect: (%s, %s)" % (self.host, self.port) self.sock.connect(sa) except socket.error, msg: if self.debuglevel > 0: print 'connect fail:', (self.host, self.port) if self.sock: self.sock.close() self.sock = None continue break if not self.sock: raise socket.error, msg Simple patch, but it was essential for my work. ---------- components: Library (Lib) files: httplib.py messages: 61512 nosy: xlash severity: minor status: open title: Httplib.py not supporting timeout - Propose Fix attached type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9263/httplib.py __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 16:59:49 2008 From: report at bugs.python.org (Facundo Batista) Date: Tue, 22 Jan 2008 15:59:49 -0000 Subject: [issue1907] Httplib.py not supporting timeout - Propose Fix attached In-Reply-To: <1201017477.23.0.0342238589364.issue1907@psf.upfronthosting.co.za> Message-ID: <1201017589.41.0.0800802018146.issue1907@psf.upfronthosting.co.za> Facundo Batista added the comment: It's already fixed in the trunk (2.6 will have timeout for httplib and other TCP libraries). ---------- nosy: +facundobatista resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 17:02:11 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Tue, 22 Jan 2008 16:02:11 -0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1201017731.26.0.0842990592212.issue1886@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I just did some tests and could not find any major difference. Which are the differences you found? BTW, in your patch the "dist" directory is not automatically created. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 17:39:46 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Jan 2008 16:39:46 -0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1201019986.15.0.19403724875.issue1886@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > I just did some tests and could not find any major difference. > Which are the differences you found? diff utility doesn't provide any output since the compared files are binary. As far as I can tell the two files have a different size (tarfile generates a little bigger file). Moreover, by using 7zip on Windows I notice that the archive generated by tarfile module looks different. Once I open it I see the following structure: dist (directory) -> archive_name.tar -> archive_name (directory) -> other subfiles ...while the archive generated with the UNIX tar utility looks like this: archive_name.tar -> archive_name (directory) -> other subfiles > BTW, in your patch the "dist" directory is not automatically created. You're right. patch2.zip file in attachment fixes that. Added file: http://bugs.python.org/file9264/patch2.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 18:33:12 2008 From: report at bugs.python.org (Facundo Batista) Date: Tue, 22 Jan 2008 17:33:12 -0000 Subject: [issue1872] change the bool struct format code from 't' to '?' In-Reply-To: <1200759352.1.0.256938962764.issue1872@psf.upfronthosting.co.za> Message-ID: <1201023192.03.0.363605659639.issue1872@psf.upfronthosting.co.za> Facundo Batista added the comment: Boosted priority: if changed, we should do it *before* 2.6 hits the street. ---------- nosy: +facundobatista priority: -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 19:09:24 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 22 Jan 2008 18:09:24 -0000 Subject: [issue1034053] unittest.py patch: add skipped test functionality Message-ID: <1201025364.87.0.940120273817.issue1034053@psf.upfronthosting.co.za> Georg Brandl added the comment: I'll take it. ---------- assignee: purcell -> georg.brandl nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 19:33:35 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Tue, 22 Jan 2008 18:33:35 -0000 Subject: [issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za> Message-ID: <1201026815.0.0.186776379713.issue1886@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Hm, on my Linux box both files are more or less identical. Sorry, I cannot reproduce your problem. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 19:47:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 18:47:10 -0000 Subject: [issue1908] make html fails - patchlevel is missing In-Reply-To: <1201027630.32.0.368466766809.issue1908@psf.upfronthosting.co.za> Message-ID: <1201027630.32.0.368466766809.issue1908@psf.upfronthosting.co.za> New submission from Christian Heimes: This happens after $ cd Docs $ rm -rf tools $ svn up $ make update $ make html mkdir -p build/html build/doctrees python tools/sphinx-build.py -b html -d build/doctrees -D latex_paper_size= . build/html Traceback (most recent call last): File "tools/sphinx-build.py", line 23, in from sphinx import main File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/__init__.py", line 19, in from sphinx.builder import builders File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/builder.py", line 34, in from sphinx.patchlevel import get_version_info, get_sys_version_info ImportError: No module named patchlevel make: *** [build] Fehler 1 patchlevel is no longer in spinx but I found one in sphinxext. ---------- assignee: georg.brandl components: Documentation messages: 61519 nosy: georg.brandl, tiran priority: urgent severity: normal status: open title: make html fails - patchlevel is missing versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 19:57:59 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 22 Jan 2008 18:57:59 -0000 Subject: [issue609824] traceback.print_stack extension Message-ID: <1201028279.92.0.732327684059.issue609824@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I can't think of a use case for this feature and as there is no activity for long time, I am closing it. ---------- nosy: +draghuram resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Jan 22 20:03:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 22 Jan 2008 19:03:08 -0000 Subject: [issue1908] make html fails - patchlevel is missing In-Reply-To: <1201027630.32.0.368466766809.issue1908@psf.upfronthosting.co.za> Message-ID: <1201028588.86.0.91538433268.issue1908@psf.upfronthosting.co.za> Georg Brandl added the comment: Silly me, left a lone .pyc file around. Fixed in r60200. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 20:05:17 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 22 Jan 2008 19:05:17 -0000 Subject: [issue1862] Error on "Save As" in IDLE (Vista 32-bit) In-Reply-To: <1200588984.34.0.741777378011.issue1862@psf.upfronthosting.co.za> Message-ID: <1201028717.33.0.322331484999.issue1862@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I've studied the problem with Process Monitor. If a file is hidden, open(f, "w") fails, whereas os.open(f, os.W_OK|os.O_CREAT) succeeds. In the succeeding call, process monitor reports Desired Access: Generic Read/Write Disposition: OpenIf Options: Synchronous IO Non-Alert, Non-Directory File Attributes: N ShareMode: Read, Write AllocationSize: 0 OpenResult: Opened In the failing call, it reports Desired Access: Generic Write, Read Attributes Disposition: OverwriteIf Options: Synchronous IO Non-Alert, Non-Directory File Attributes: N ShareMode: Read, Write AllocationSize: 0 I then tried os.open(f, os.W_OK|os.CREAT|os.O_TRUNC) which also fails, giving Desired Access: Generic Read/Write Disposition: OverwriteIf Options: Synchronous IO Non-Alert, Non-Directory File Attributes: N ShareMode: Read, Write AllocationSize: 0 So it fails for FILE_OVERWRITE_IF, but succeeds for FILE_OPEN_IF. These map back to CREATE_ALWAYS and OPEN_ALWAYS - apparently, you can't truncate a hidden file on Vista. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 20:26:01 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Jan 2008 19:26:01 -0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1201029961.71.0.540107831731.issue1818@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Barry, any thoughts on this? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 20:37:06 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 22 Jan 2008 19:37:06 -0000 Subject: [issue462716] sys.settrace inheritance Message-ID: <1201030626.47.0.204512732889.issue462716@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I haven't used settrace() functionality myself but a quick test using latest python shows that trace function set with sys.settrace() is not inherited by newly created threads. I am closing this as there is no activity for long time. ---------- nosy: +draghuram resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Jan 22 20:40:59 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2008 19:40:59 -0000 Subject: [issue1646068] Dict lookups fail if sizeof(Py_ssize_t) < sizeof(long) Message-ID: <1201030859.54.0.164925610959.issue1646068@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch looks fine, but why isn't an union used instead of trying to figure out the longest of both types? ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 20:46:57 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2008 19:46:57 -0000 Subject: [issue1621660] this module (Zen of Python) docs list broken URL Message-ID: <1201031217.58.0.381338145472.issue1621660@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think the original poster alludes to the fact that when doing `import this; help(this)`, the "module docs" section points to the autogenerated URL `http://www.python.org/doc/current/lib/module-this.html`, which doesn't exist. Probably nothing very annoying though :-) I had never thought of asking for help about the `this` module before... ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 20:50:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 19:50:53 -0000 Subject: [issue1621660] this module (Zen of Python) docs list broken URL Message-ID: <1201031453.93.0.848488513429.issue1621660@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't see a link with Python 2.6 or an url in the this code. ---------- nosy: +tiran resolution: -> invalid status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 20:56:28 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 22 Jan 2008 19:56:28 -0000 Subject: [issue1087741] subclassable mmap Message-ID: <1201031788.36.0.00925948296088.issue1087741@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed as r60202. Thanks for the care! _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 21:00:24 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Jan 2008 20:00:24 -0000 Subject: [issue1221598] ftplib storbinary/storlines callback function Message-ID: <1201032024.38.0.621285302111.issue1221598@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Could I propose the following docstring corrections? @@ -313,7 +313,7 @@ expected size may be None if it could not be determined. Optional `rest' argument can be a string that is sent as the - argument to a RESTART command. This is essentially a server + argument to a REST(art) command. This is essentially a server marker used to tell the server to skip over any data up to the given marker. """ @@ -403,7 +403,7 @@ """Retrieve data in line mode. A new port is created for you. Args: - cmd: A RETR or LIST command. + cmd: A RETR, LIST, NLST or MLSD command. callback: An optional single parameter callable that is called for each line with the trailing CRLF stripped. [default: print_line()] ---------- nosy: +giampaolo.rodola _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 21:04:33 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Jan 2008 20:04:33 -0000 Subject: [issue1909] Backport: Mixing default keyword arguments with *args In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za> Message-ID: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Need to backport Py3.0's functionality so that the following is valid syntax: def f(a, *args, v=None): . . . ---------- assignee: tiran components: Interpreter Core messages: 61530 nosy: rhettinger, tiran severity: normal status: open title: Backport: Mixing default keyword arguments with *args versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 21:12:44 2008 From: report at bugs.python.org (phil) Date: Tue, 22 Jan 2008 20:12:44 -0000 Subject: [issue1866] const arg for PyInt_FromString In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za> Message-ID: <1201032764.93.0.430910594477.issue1866@psf.upfronthosting.co.za> phil added the comment: Oh, all right. Just don't tell my boss -- he thinks I'm doing "real" work. :-) I haven't thoroughly studied the test harness, but it looked like /bin/python /lib/python2.5/test/autotest.py was what I should do? The output generated before/after the patch was identical. Added file: http://bugs.python.org/file9265/Python-2.5.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 21:12:43 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 22 Jan 2008 20:12:43 -0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1201032763.2.0.503115361135.issue1818@psf.upfronthosting.co.za> Skip Montanaro added the comment: I'd personally be kind of surprised if Barry had any thoughts on this. Is there any reason this couldn't be pushed down into the C code and replace the normal tuple output completely? In the absence of any fieldnames you could just dream some up, like "field001", "field002", etc. Skip ---------- nosy: +skip.montanaro __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 21:13:27 2008 From: report at bugs.python.org (phil) Date: Tue, 22 Jan 2008 20:13:27 -0000 Subject: [issue1866] const arg for PyInt_FromString In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za> Message-ID: <1201032807.24.0.0309508653184.issue1866@psf.upfronthosting.co.za> Changes by phil: Added file: http://bugs.python.org/file9266/autotest.out.after __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 21:19:34 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Jan 2008 20:19:34 -0000 Subject: [issue1121416] zip incorrectly and incompletely documented Message-ID: <1201033174.72.0.509256446242.issue1121416@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Added wording to guarantee left-to-right evaluation. See revision 60203. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 21:24:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 20:24:19 -0000 Subject: [issue1909] Backport: Mixing default keyword arguments with *args In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za> Message-ID: <1201033459.18.0.896587854822.issue1909@psf.upfronthosting.co.za> Christian Heimes added the comment: Why have you assigned the bug to me? I ain't no grammar expert. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 21:26:41 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Jan 2008 20:26:41 -0000 Subject: [issue1909] Backport: Mixing default keyword arguments with *args In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za> Message-ID: <1201033601.55.0.686562895629.issue1909@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I mistakenly thought you had done this for Py3.0. ---------- assignee: tiran -> __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 21:32:12 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2008 20:32:12 -0000 Subject: [issue1909] Backport: Mixing default keyword arguments with *args In-Reply-To: <1201033601.55.0.686562895629.issue1909@psf.upfronthosting.co.za> Message-ID: <479652C6.4040003@cheimes.de> Christian Heimes added the comment: Raymond Hettinger wrote: > Raymond Hettinger added the comment: > > I mistakenly thought you had done this for Py3.0. You're welcome, pal! :) I've created a backport of the kw only functions for 2.6 but that doesn't make me an expert on grammar. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 21:42:03 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 22 Jan 2008 20:42:03 -0000 Subject: [issue1221598] ftplib storbinary/storlines callback function In-Reply-To: <1201032024.38.0.621285302111.issue1221598@psf.upfronthosting.co.za> Message-ID: <52dc1c820801221241i126d990bs9aa29563dc9749d9@mail.gmail.com> Gregory P. Smith added the comment: thanks. applied (well, they will be when svn.python.org comes back) On 1/22/08, Giampaolo Rodola' wrote: > > > Giampaolo Rodola' added the comment: > > Could I propose the following docstring corrections? > > Added file: http://bugs.python.org/file9267/unnamed _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080122/5dbda697/attachment.txt From report at bugs.python.org Tue Jan 22 21:55:55 2008 From: report at bugs.python.org (Martin Rinehart) Date: Tue, 22 Jan 2008 20:55:55 -0000 Subject: [issue1679] tokenizer permits invalid hex integer In-Reply-To: <1200761766.67.0.300112321396.issue1679@psf.upfronthosting.co.za> Message-ID: <257be0950801221255k5062550cv76714e2eb88e8e31@mail.gmail.com> Martin Rinehart added the comment: re 0x == 0 Thanks! Added file: http://bugs.python.org/file9268/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080122/044c8385/attachment.txt From report at bugs.python.org Tue Jan 22 23:05:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2008 22:05:12 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201039512.64.0.73465428804.issue1577@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't see where there is a change in semantics. Today, `shutil.move(source_file, destination_dir)` already moves source_file inside the destination_dir (it doesn't replace the latter with the former). Is there a misunderstanding? ---------- nosy: +pitrou versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 23:19:20 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 22 Jan 2008 22:19:20 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201040360.36.0.772364098597.issue1577@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: `shutil.move(source_file, destination_dir)` does move source_file to destination_dir but the point is that even when source and destinations are on the same file system, it still "copies" the data when there is no need for it. The reason is explained in the very first comment. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 23:26:13 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2008 22:26:13 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201040773.34.0.870983346579.issue1577@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Raghuram, I had understood that, I was answering Guido's objection :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 23:28:35 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Jan 2008 22:28:35 -0000 Subject: [issue1221598] ftplib storbinary/storlines callback function Message-ID: <1201040915.72.0.859970729949.issue1221598@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Another one. On line 542: - # Note that the RFC doesn't say anything about 'SIZE' + # SIZE command is defined in RFC-3659 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 22 23:32:58 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 22 Jan 2008 22:32:58 -0000 Subject: [issue1906] Distinguish between cfunction, cvar and cmacro In-Reply-To: <1201015170.0.0.526066716057.issue1906@psf.upfronthosting.co.za> Message-ID: <1201041178.78.0.06986534606.issue1906@psf.upfronthosting.co.za> Georg Brandl added the comment: "cmacro" is only for non-function-like macros, see the docs. ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 23:33:07 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 22:33:07 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201041186.99.0.985335900288.issue1577@psf.upfronthosting.co.za> Guido van Rossum added the comment: Antoine: please just ignore me, even though I may once have written this code, I clearly don't understand it any more. :-) All we need now is a patch and someone to review it, right? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 23:38:12 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 22 Jan 2008 22:38:12 -0000 Subject: [issue1743] IDLE fails to launch In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za> Message-ID: <1201041492.71.0.488717213985.issue1743@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I've studied the problem with Process Monitor. If a file is hidden, open(f, "w") fails, whereas os.open(f, os.W_OK|os.O_CREAT) succeeds. In the succeeding call, process monitor reports Desired Access: Generic Read/Write Disposition: OpenIf Options: Synchronous IO Non-Alert, Non-Directory File Attributes: N ShareMode: Read, Write AllocationSize: 0 OpenResult: Opened In the failing call, it reports Desired Access: Generic Write, Read Attributes Disposition: OverwriteIf Options: Synchronous IO Non-Alert, Non-Directory File Attributes: N ShareMode: Read, Write AllocationSize: 0 I then tried os.open(f, os.W_OK|os.CREAT|os.O_TRUNC) which also fails, giving Desired Access: Generic Read/Write Disposition: OverwriteIf Options: Synchronous IO Non-Alert, Non-Directory File Attributes: N ShareMode: Read, Write AllocationSize: 0 So it fails for FILE_OVERWRITE_IF, but succeeds for FILE_OPEN_IF. These map back to CREATE_ALWAYS and OPEN_ALWAYS - apparently, you can't truncate a hidden file on Vista. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 22 23:43:59 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 22 Jan 2008 22:43:59 -0000 Subject: [issue1743] IDLE fails to launch In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za> Message-ID: <1201041839.12.0.8568059188.issue1743@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As a follow-up, it appears that Windows didn't allow truncating hidden or system files since Windows 2000. If you change the flags on .idlerc to hidden in (say) W2k3, IDLE will also fail to start - so it's not a Vista issue. The question is why the folder "sudenly" became hidden - Python has no API to make it so. In any case, the proper solution is to delete the file rather than overwriting it, perhaps like so def save_overwrite_open(fname): try: return open(fname,"w") except IOError: os.unlink(fname) return open(fname,"w") __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 00:02:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2008 23:02:12 -0000 Subject: [issue1651] Limit the max size of PyUnicodeObject->defenc? In-Reply-To: <1197980020.78.0.710337047822.issue1651@psf.upfronthosting.co.za> Message-ID: <1201042932.94.0.464342108122.issue1651@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The default encoding version is generated lazily, and only from a couple of places (if I believe my grepping through the py3k sources). So we can: * choose not to care, as the conversion looks rather rare * incref the return value of _PyUnicode_AsDefaultEncodedString(), and convert the 20 or so places in which that function is used to properly decref the value when done ---------- nosy: +pitrou __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 00:05:24 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 23:05:24 -0000 Subject: [issue1651] Limit the max size of PyUnicodeObject->defenc? In-Reply-To: <1197980020.78.0.710337047822.issue1651@psf.upfronthosting.co.za> Message-ID: <1201043124.79.0.860437474309.issue1651@psf.upfronthosting.co.za> Guido van Rossum added the comment: > * choose not to care, as the conversion looks rather rare Yes. > * incref the return value of _PyUnicode_AsDefaultEncodedString(), > and convert the 20 or so places in which that function is used to > properly decref the value when done No. I suspect you'll find it quite difficult to pick a place where to do the decref in some cases. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 00:30:27 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Jan 2008 23:30:27 -0000 Subject: [issue1034053] unittest.py patch: add skipped test functionality Message-ID: <1201044627.09.0.623026041006.issue1034053@psf.upfronthosting.co.za> Changes by Giampaolo Rodola': ---------- nosy: +giampaolo.rodola _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 00:41:33 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 22 Jan 2008 23:41:33 -0000 Subject: [issue1651] Limit the max size of PyUnicodeObject->defenc? In-Reply-To: <1197980020.78.0.710337047822.issue1651@psf.upfronthosting.co.za> Message-ID: <1201045292.98.0.251331774539.issue1651@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: For Py3k you can get rid of the cached default encoded version of the Unicode object altogether: This was only needed to make the Unicode/string auto-coercion mechanism efficient in Python 2.x. In Py3k, you'll only do such conversions at the IO-boundaries and explicitly, so caching the converted value is no longer necessary. ---------- nosy: +lemburg __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 00:49:22 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2008 23:49:22 -0000 Subject: [issue1651] Limit the max size of PyUnicodeObject->defenc? In-Reply-To: <1197980020.78.0.710337047822.issue1651@psf.upfronthosting.co.za> Message-ID: <1201045762.37.0.820594924315.issue1651@psf.upfronthosting.co.za> Guido van Rossum added the comment: You wish. In practice (unfortunately) it's still used quite a bit. It would be a good project to eradicate the need, but I see it as low priority. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 00:58:44 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 22 Jan 2008 23:58:44 -0000 Subject: [issue1910] _threading_local should use with In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> Message-ID: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> New submission from Benjamin Peterson: I was reading _threading_local and noticed it didn't use the with statment, yet. So, I cooked up this trivial patch. I hope this isn't to small. Thanks for your time. ---------- components: Library (Lib) files: _threading_local-with-stmt.diff messages: 61551 nosy: gutworth severity: normal status: open title: _threading_local should use with versions: Python 2.6 Added file: http://bugs.python.org/file9269/_threading_local-with-stmt.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 02:29:31 2008 From: report at bugs.python.org (Jon Wilson) Date: Wed, 23 Jan 2008 01:29:31 -0000 Subject: [issue1911] webbrowser.open firefox 3 issues In-Reply-To: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za> Message-ID: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za> New submission from Jon Wilson: webbrowser.open('http://example.com') opens something like: file:///path/to/home/directory/"http://example.com" in firefox 3 beta 2. this behavior of firefox will most like not change in the stable release. ---------- components: Extension Modules messages: 61552 nosy: elessar severity: normal status: open title: webbrowser.open firefox 3 issues versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 02:35:37 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 01:35:37 -0000 Subject: [issue1911] webbrowser.open firefox 3 issues In-Reply-To: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za> Message-ID: <1201052137.14.0.926839131026.issue1911@psf.upfronthosting.co.za> Guido van Rossum added the comment: What platform? How come? Got a fix that doesn't break for other browsers? There's a 1-2 week window at most for getting fixes into 2.5.2! ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 04:04:05 2008 From: report at bugs.python.org (Jon Wilson) Date: Wed, 23 Jan 2008 03:04:05 -0000 Subject: [issue1911] webbrowser.open firefox 3 issues In-Reply-To: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za> Message-ID: <1201057445.76.0.125574722867.issue1911@psf.upfronthosting.co.za> Jon Wilson added the comment: I'm running 2.6.23.9 linux kernel fedora 8. I've gone ahead and downloaded the subversion checkout of the webbrowser.py file to see the differences. The svn version fixes the issue, so then I went a hunting as to why. In the 2.5 version, with a version of firefox running out of my home directory (but still in my path) webbrowser calles BackgroundBrowser instead of UnixBrowser. BackgroundBrowser calls subprocess.Popen(cmdline), where cmdline is a tuble in form ['/browser/path', '"http://example.com"'], and subprocess doesn't use/like the double quotes (probably legacy os.popen format) The difference in the two webbrowser scripts that fixes it is thus: 446a445,455 > # The default Gnome browser > if _iscommand("gconftool-2"): > # get the web browser string from gconftool > gc = 'gconftool-2 -g /desktop/gnome/url-handlers/http/command 2>/dev/n ull' > out = os.popen(gc) > commd = out.read().strip() > retncode = out.close() > > # if successful, register it > if retncode is None and commd: > register("gnome", None, BackgroundBrowser(commd.split())) 448,456c457 < # The default GNOME browser < if "GNOME_DESKTOP_SESSION_ID" in os.environ and _iscommand("gnome-open"): < register("gnome-open", None, BackgroundBrowser("gnome-open")) < < # The default KDE browser < if "KDE_FULL_SESSION" in os.environ and _iscommand("kfmclient"): < register("kfmclient", Konqueror, Konqueror("kfmclient")) < < # The Mozilla/Netscape browsers so it appears to be a problem with gconf that python has to work around. see: https://bugs.launchpad.net/ubuntu/+source/python2.5/+bug/83974 So as long as it is in trunk 2.5.2 should fix it! (the patch is not in 2.5.1). thanks. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 04:52:54 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 03:52:54 -0000 Subject: [issue1911] webbrowser.open firefox 3 issues In-Reply-To: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za> Message-ID: <1201060374.17.0.0883322562226.issue1911@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, since it's so simple I'll take it if noone else does. But anyone else who feels like backporting this please go ahead! ---------- assignee: -> gvanrossum keywords: +easy, patch priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 05:48:43 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 04:48:43 -0000 Subject: [issue1819] Speed hack for function calls with named parameters In-Reply-To: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za> Message-ID: <1201063722.96.0.78373250333.issue1819@psf.upfronthosting.co.za> Guido van Rossum added the comment: Nice idea, but why set the priority to high? I have no immediate time to review this and probably won't for a while. ---------- priority: high -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 07:05:26 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 23 Jan 2008 06:05:26 -0000 Subject: [issue1736] Three bugs of FCICreate (PC/_msi.c) In-Reply-To: <1199458428.92.0.688794479817.issue1736@psf.upfronthosting.co.za> Message-ID: <1201068326.76.0.323407874039.issue1736@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Sorry, I lied. What I said in bug 2 was totally wrong. Meaning of 'i' was changed from original code and my patch. There is no problem about buffer length. Thank you. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 07:06:48 2008 From: report at bugs.python.org (Matti Punkeri) Date: Wed, 23 Jan 2008 06:06:48 -0000 Subject: [issue1912] Segmentation fault In-Reply-To: <1201068408.15.0.769067205132.issue1912@psf.upfronthosting.co.za> Message-ID: <1201068408.15.0.769067205132.issue1912@psf.upfronthosting.co.za> New submission from Matti Punkeri: Python seg faults after 20-30 hours. The running Python application is a Qt based user interface which handles several SSH threads. Backtrace is attached. ---------- files: backtrace.txt messages: 61558 nosy: mpunkeri severity: major status: open title: Segmentation fault type: crash versions: Python 2.4 Added file: http://bugs.python.org/file9270/backtrace.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 07:08:59 2008 From: report at bugs.python.org (Matti Punkeri) Date: Wed, 23 Jan 2008 06:08:59 -0000 Subject: [issue1912] Segmentation fault In-Reply-To: <1201068408.15.0.769067205132.issue1912@psf.upfronthosting.co.za> Message-ID: <1201068539.64.0.772646130851.issue1912@psf.upfronthosting.co.za> Matti Punkeri added the comment: And the program is running on SuSE Linux, 2.6.11.4-20a-default, gcc version 3.3.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 07:11:40 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 23 Jan 2008 06:11:40 -0000 Subject: [issue1736] Two bugs of FCICreate (PC/_msi.c) In-Reply-To: <1199458428.92.0.688794479817.issue1736@psf.upfronthosting.co.za> Message-ID: <1201068700.98.0.441128808863.issue1736@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto: ---------- title: Three bugs of FCICreate (PC/_msi.c) -> Two bugs of FCICreate (PC/_msi.c) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 08:03:07 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 07:03:07 -0000 Subject: [issue1912] Segmentation fault In-Reply-To: <1201068408.15.0.769067205132.issue1912@psf.upfronthosting.co.za> Message-ID: <1201071787.39.0.0594045322858.issue1912@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't think it's a bug in Python. The crash occurs inside the sip or qt module, which means it's either a bug in sip, qt or pyqt. Please take the bug to riverbank computing. Their code might have a memory leak or reference counting issue. ---------- nosy: +tiran resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 08:04:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 07:04:02 -0000 Subject: [issue1910] _threading_local should use with In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> Message-ID: <1201071842.82.0.242334689656.issue1910@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks! :) Lot's of code doesn't use the with statement yet. Feel free to contribute more fixes. ---------- keywords: +easy, patch nosy: +tiran priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 08:09:24 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 23 Jan 2008 07:09:24 -0000 Subject: [issue1910] _threading_local should use with In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> Message-ID: <1201072164.63.0.874996007764.issue1910@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I appreciate the patch submission but am going to reject it. The try/finally form is faster. In general, I think we only want to do this in code that isn't performance critical and that would be made much cleaner. ---------- nosy: +rhettinger resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 08:20:06 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 07:20:06 -0000 Subject: [issue1571754] Building using Sleepycat db 4.5.20 is broken Message-ID: <1201072806.8.0.938156844695.issue1571754@psf.upfronthosting.co.za> Gregory P. Smith added the comment: 4.5 support was put in a while back ---------- nosy: +gregory.p.smith resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 08:26:49 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 07:26:49 -0000 Subject: [issue1541671] bsddb can't use unicode filenames Message-ID: <1201073209.49.0.893927106375.issue1541671@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- priority: normal -> low resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 08:35:55 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 07:35:55 -0000 Subject: [issue1516078] dbhash __len__ not reliable Message-ID: <1201073755.54.0.418979240028.issue1516078@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Works for me in 2.5 and 2.4 isn't getting bug fixes anymore. >>> import dbhash >>> d = dbhash.open('x.db', 'w') >>> d['e'] = 'Eee' >>> d['f'] = 'Ffff' >>> len(d) 2 >>> len(d) 2 It was likely fixed by this: ------------------------------------------------------------------------ r46684 | gregory.p.smith | 2006-06-05 16:59:37 -0700 (Mon, 05 Jun 2006) | 5 line s - bsddb: the __len__ method of a DB object has been fixed to return correct results. It could previously incorrectly return 0 in some cases. Fixes SF bug 1493322 (pybsddb bug 1184012). ---------- nosy: +gregory.p.smith resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 09:01:54 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 08:01:54 -0000 Subject: [issue1191] bsddb does not build with bsddb lib v3.1. In-Reply-To: <1190503722.68.0.665728858894.issue1191@psf.upfronthosting.co.za> Message-ID: <1201075314.46.0.680159708117.issue1191@psf.upfronthosting.co.za> Gregory P. Smith added the comment: BerkeleyDB 3.3 through 4.5 are supported. 4.6 support has been checked in and 4.7 (not yet released) support is supposedly on its way from someone at oracle. Versions older than 3.3 are too difficult (and too buggy) to support. You're on your own if you want to use them. Yes there are many lines of legacy code in _bsddb.c that have the old 3.1 and 3.2 feature ifdefs. Cleaning them up is very low priority and would just interfere with other peoples patches. They will be cleaned up out of the _bsddb.c module in the python 3000 branch. ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 09:22:59 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 08:22:59 -0000 Subject: [issue730938] Python bsddb docs need update Message-ID: <1201076579.63.0.275610611133.issue730938@psf.upfronthosting.co.za> Gregory P. Smith added the comment: ReST format docs that cover what is actually implemented and wrapped in python would be good. We need a volunteer willing to go through and do it. ---------- assignee: gregory.p.smith -> nosy: +jcea title: Python 2.3 bsddb docs need update -> Python bsddb docs need update ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Jan 23 09:25:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 08:25:28 -0000 Subject: [issue1913] test_pep263 fails In-Reply-To: <1201076728.2.0.475967660638.issue1913@psf.upfronthosting.co.za> Message-ID: <1201076728.2.0.475967660638.issue1913@psf.upfronthosting.co.za> New submission from Christian Heimes: $ ./python Lib/test/regrtest.py -v test_pep263 test_pep263 test_compilestring (test.test_pep263.PEP263Test) ... FAIL test_pep263 (test.test_pep263.PEP263Test) ... ok ====================================================================== FAIL: test_compilestring (test.test_pep263.PEP263Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/py3k/Lib/test/test_pep263.py", line 25, in test_compilestring AssertionError: '\xc3\xb3' != '\xf3' ---------------------------------------------------------------------- Ran 2 tests in 0.035s FAILED (failures=1) test test_pep263 failed -- Traceback (most recent call last): File "/home/heimes/dev/python/py3k/Lib/test/test_pep263.py", line 25, in test_compilestring AssertionError: '\xc3\xb3' != '\xf3' 1 test failed: test_pep263 ---------- components: Interpreter Core, Tests messages: 61567 nosy: tiran priority: high severity: normal status: open title: test_pep263 fails type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 09:34:23 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 08:34:23 -0000 Subject: [issue1202] zlib.crc32() and adler32() return value In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> Message-ID: <1201077263.11.0.271496203572.issue1202@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- assignee: -> gregory.p.smith keywords: +64bit, easy nosy: +gregory.p.smith priority: -> normal versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 09:35:49 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 08:35:49 -0000 Subject: [issue1223] httplib does not handle ssl end of file properly In-Reply-To: <1191199809.02.0.233978380017.issue1223@psf.upfronthosting.co.za> Message-ID: <1201077349.09.0.106442754243.issue1223@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- assignee: -> janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 09:48:51 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 08:48:51 -0000 Subject: [issue1789] incorrect assumption about unsigned long byte size In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za> Message-ID: <1201078131.6.0.991592020125.issue1789@psf.upfronthosting.co.za> Gregory P. Smith added the comment: the docs I see in the URL you give are correct as it states 'two and four byte unsigned integer respectively' for H and L. However the example is missing the < for little-endian; I'll add that. Also, I notice that the struct module documentation itself incorrectly uses the C terms 'int' and 'long' to assume 32bit and long long when it means 64bit. I'll fix that. ---------- assignee: -> gregory.p.smith keywords: +easy nosy: +gregory.p.smith priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 09:51:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 08:51:28 -0000 Subject: [issue1223] httplib does not handle ssl end of file properly In-Reply-To: <1191199809.02.0.233978380017.issue1223@psf.upfronthosting.co.za> Message-ID: <1201078288.08.0.58757567872.issue1223@psf.upfronthosting.co.za> Christian Heimes added the comment: I've set version to 2.6 and priority to high so we don't forget it. ---------- nosy: +tiran priority: -> high versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 10:03:50 2008 From: report at bugs.python.org (Christopher Yeleighton) Date: Wed, 23 Jan 2008 09:03:50 -0000 Subject: [issue1789] incorrect assumption about unsigned long byte size In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za> Message-ID: <1201079030.16.0.228673621213.issue1789@psf.upfronthosting.co.za> Christopher Yeleighton added the comment: Python 2.5.1 (r251:54863, Oct 5 2007, 13:50:07) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import struct >>> g_f = open('/dev/null') >>> struct.unpack('L', g_f.read(04)) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/struct.py", line 87, in unpack return o.unpack(s) struct.error: unpack requires a string argument of length 8 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 10:22:14 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 09:22:14 -0000 Subject: [issue1910] Document that with is slower than try/finally In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> Message-ID: <1201080134.84.0.226801990128.issue1910@psf.upfronthosting.co.za> Christian Heimes added the comment: Oh, I didn't know that with is slower than try/finally. It should get documented that try/finally is better suited than with for performance critical code. ---------- assignee: -> georg.brandl components: +Documentation -Library (Lib) keywords: -patch nosy: +georg.brandl status: closed -> pending title: _threading_local should use with -> Document that with is slower than try/finally __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 10:23:45 2008 From: report at bugs.python.org (Song Ma) Date: Wed, 23 Jan 2008 09:23:45 -0000 Subject: [issue1915] Python 2.5.1 compile failed with configure option "--enable-unicode=no" In-Reply-To: <1201080225.38.0.120364938513.issue1915@psf.upfronthosting.co.za> Message-ID: <1201080225.38.0.120364938513.issue1915@psf.upfronthosting.co.za> New submission from Song Ma: In my platform I have to disable Unicode support in Python 2.5.1. The "configure" file provided a option "--enable-unicode=no" to allow me to do so. However, If I ran the configure with that option and then make, the following error showed: Python/ast.c:3168: undefined reference to `PyUnicode_DecodeRawUnicodeEscape' Python/ast.c:3170: undefined reference to `PyUnicode_DecodeUnicodeEscape' collect2: ld returned 1 exit status make: *** [python] Error 1 Python 2.4.4 can be compiled with this option and works well. Since "ast.c" was newly introduced in 2.5.1. Maybe we need put MACRO "Py_USING_UNICODE" in ast.c for function "decode_unicode()". Otherwise it needs to modify the "configure" file to forbid "--enable-unicode=no". However in ast.c "decode_utf8()" is using "Py_USING_UNICODE" to make it "pluggable" for not supporting utf8. Why not do the same thing for "decode_unicode()"? ---------- components: Build, Unicode messages: 61573 nosy: songma severity: urgent status: open title: Python 2.5.1 compile failed with configure option "--enable-unicode=no" type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 10:31:13 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 23 Jan 2008 09:31:13 -0000 Subject: [issue1910] Document that with is slower than try/finally In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> Message-ID: <1201080673.09.0.721596357768.issue1910@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Raymond, does your comment also apply to change at r60189 ? It is exactly the same thing, in threading.py... OTOH, _threading_local.py is not used by the standard library, except by the dummy_threading module; threading.local normally comes from threadmodule.c. I don't think this module is performance critical. Maybe we can teach "good practices" there. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 10:35:16 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 23 Jan 2008 09:35:16 -0000 Subject: [issue1910] Document that with is slower than try/finally In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> Message-ID: <1201080916.52.0.229195299717.issue1910@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: In ceval.c, the "case WITH_CLEANUP" contains the following lines: /* XXX Not the fastest way to call it... */ x = PyObject_CallFunctionObjArgs(x, u, v, w, NULL); Maybe this is something not too difficult to improve? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 10:37:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 09:37:15 -0000 Subject: [issue1915] Python 2.5.1 compile failed with configure option "--enable-unicode=no" In-Reply-To: <1201080225.38.0.120364938513.issue1915@psf.upfronthosting.co.za> Message-ID: <1201081035.39.0.186536465488.issue1915@psf.upfronthosting.co.za> Christian Heimes added the comment: Python/ast.c has been fixed but more code needs to be fixed: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Parser/tokenizer.o Parser/tokenizer.c Parser/tokenizer.c: In function 'decode_str': Parser/tokenizer.c:607: warning: assignment discards qualifiers from pointer target type Parser/tokenizer.c: In function 'dec_utf8': Parser/tokenizer.c:1550: warning: implicit declaration of function 'PyUnicode_DecodeUTF8' Parser/tokenizer.c:1550: warning: initialization makes pointer from integer without a cast Parser/tokenizer.c:1552: warning: implicit declaration of function 'PyUnicode_AsEncodedString' Parser/tokenizer.c:1552: warning: assignment makes pointer from integer without a cast /home/heimes/dev/python/release25-maint/Parser/tokenizer.c:1550: undefined reference to `PyUnicode_DecodeUTF8' /home/heimes/dev/python/release25-maint/Parser/tokenizer.c:1552: undefined reference to `PyUnicode_AsEncodedString' /home/heimes/dev/python/release25-maint/Parser/tokenizer.c:1550: undefined reference to `PyUnicode_DecodeUTF8' /home/heimes/dev/python/release25-maint/Parser/tokenizer.c:1552: undefined reference to `PyUnicode_AsEncodedString' ---------- components: +Interpreter Core -Unicode nosy: +tiran priority: -> high versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 11:41:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 10:41:39 -0000 Subject: [issue1916] Add inspect.isgenerator In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za> Message-ID: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za> New submission from Christian Heimes: The inspect module has no function isgenerator. ---------- components: Documentation, Library (Lib) keywords: easy messages: 61577 nosy: tiran priority: low severity: normal status: open title: Add inspect.isgenerator type: rfe versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 11:55:34 2008 From: report at bugs.python.org (Ben Bass) Date: Wed, 23 Jan 2008 10:55:34 -0000 Subject: [issue1767511] SocketServer.DatagramRequestHandler Message-ID: <1201085734.6.0.627384112106.issue1767511@psf.upfronthosting.co.za> Ben Bass added the comment: I've just bumped into this issue. In my opinion the finish() method should only do anything if wfile is not empty, i.e: temp = self.wfile.getvalue() if temp: self.socket.sendto(temp, self.client_address) ---------- nosy: +bpb _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 12:07:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 11:07:10 -0000 Subject: [issue1767511] SocketServer.DatagramRequestHandler Message-ID: <1201086430.45.0.605883064965.issue1767511@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you provide a working patch with a unit test and doc updates? ---------- nosy: +tiran type: -> behavior versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 15:07:50 2008 From: report at bugs.python.org (Armin Rigo) Date: Wed, 23 Jan 2008 14:07:50 -0000 Subject: [issue1754489] Non-portable address length calculation for AF_UNIX sockets Message-ID: <1201097270.52.0.677350177767.issue1754489@psf.upfronthosting.co.za> Armin Rigo added the comment: Checked in as r60214. ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 15:26:31 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 23 Jan 2008 14:26:31 -0000 Subject: [issue1736] Three bugs of FCICreate (PC/_msi.c) In-Reply-To: <1199458428.92.0.688794479817.issue1736@psf.upfronthosting.co.za> Message-ID: <1201098391.22.0.883134579542.issue1736@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Umm, please forget previous comment. >>> msilib.FCICreate("a" * 256 + "/" + "b" * 255, []) crashed on debug build. (CB_MAX_CAB_PATH == 256) ---------- title: Two bugs of FCICreate (PC/_msi.c) -> Three bugs of FCICreate (PC/_msi.c) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 15:32:28 2008 From: report at bugs.python.org (Ben Bass) Date: Wed, 23 Jan 2008 14:32:28 -0000 Subject: [issue1767511] SocketServer.DatagramRequestHandler Message-ID: <1201098748.56.0.637093086815.issue1767511@psf.upfronthosting.co.za> Ben Bass added the comment: Main issue here (as I see it) is that StreamRequestHandler and DatagramRequestHandler should behave in the same way. This is not the case in Python 2.5.1 for the case where the handle method does not respond to the request socket (e.g. in my case it is forwarding data to a different socket). While handler methods in StreamRequestHandler need not send any data back to the request socket, in DatagramRequestHandlers an attempt will be made to send data whether any is available or not. This causes a socket hang (for several minutes) on Windows with a '10040 Message too long' error. By only sending data back to the request if the handler has written to wfile, this is avoided, giving the twin fixes of avoiding a nasty socket error and providing compatibilty with StreamRequestHandler behaviour. Test has been updated to add tests of handlers which do not respond to the request; this causes a hang in Python2.5.1 stock (not sure how to avoid this and cleanly fail), test passes with changed SocketServer. p.s. this is my first patch submission to anything, so go easy :-) Added file: http://bugs.python.org/file9271/DatagramServer.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 15:34:40 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 14:34:40 -0000 Subject: [issue1915] Python 2.5.1 compile failed with configure option "--enable-unicode=no" In-Reply-To: <1201080225.38.0.120364938513.issue1915@psf.upfronthosting.co.za> Message-ID: <1201098880.54.0.124353586546.issue1915@psf.upfronthosting.co.za> Christian Heimes added the comment: I fixed it for Python 2.5 and 2.6. However several extensions and modules don't work w/o unicode support. Please contribute fixes if you need more support. r60215 r60216 ---------- priority: high -> normal resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 15:46:25 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2008 14:46:25 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201099585.88.0.373241749138.issue1577@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Before tackling this, I'd like a precision on os.rename(src, dst) semantics. The documentation says "If dst is a directory, OSError will be raised". However, under Linux, if src is a directory and dst is an empty directory, dst is overwritten with src: $ mkdir src dst $ touch dst/t $ ./python -c "import os; os.rename('src', 'dst')" Traceback (most recent call last): File "", line 1, in OSError: [Errno 39] Directory not empty $ rm dst/t $ ./python -c "import os; os.rename('src', 'dst')" $ Is this a bug, a misfeature, or just an imprecision in the documentation? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 16:17:10 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 23 Jan 2008 15:17:10 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1201099585.88.0.373241749138.issue1577@psf.upfronthosting.co.za> Message-ID: <2c51ecee0801230717l55130366ldc39968e9a7bd1c8@mail.gmail.com> Raghuram Devarakonda added the comment: > Before tackling this, I'd like a precision on os.rename(src, dst) > semantics. The documentation says "If dst is a directory, OSError will > be raised". However, under Linux, if src is a directory and dst is an > empty directory, dst is overwritten with src: I think the doc is incorrect. The rename() man page doesn't explicitly say that destination can not be directory. In fact, a small C program directly calling rename() (on SuSE 10) behaves exactly as your python script. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 16:29:09 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2008 15:29:09 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201102149.36.0.378003683274.issue1577@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Does this mean we should preserve this behaviour for shutil.move() as well? Right now, shutil.move(src_dir, dst_dir) replaces dst_dir with src_dir if dst_dir is empty, but moves src_dir inside dst_dir otherwise. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 17:04:22 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2008 16:04:22 -0000 Subject: [issue1180193] broken pyc files Message-ID: <1201104262.36.0.756925790255.issue1180193@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If code objects grew a __module__ attribute (which functions already have), wouldn't it be just a matter of falling back on sys.modules[my_code_object.__module__].__file__ when my_code_object.co_filename points to a non-existent file? ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 17:07:03 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 23 Jan 2008 16:07:03 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1201102149.36.0.378003683274.issue1577@psf.upfronthosting.co.za> Message-ID: <2c51ecee0801230806n7b9bd5ddtaea6c1f6eecd6968@mail.gmail.com> Raghuram Devarakonda added the comment: > Does this mean we should preserve this behaviour for shutil.move() as well? I don't think so. The key is to remember that shutil.move() is os.rename() with some additional benefits (as stated by Guido in an earlier comment). Also, changing the behaviour of shutil.move() may break backwards compatibility. I thought this issue has reached a conclusion that all one need is a doc update. Some thing like (copying from my previous comment): ""If the destination is a fiile and is on same filesystem as that of src, then simply use rename." In fact, even the issue's component has been changed to "Documentation". __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 18:01:39 2008 From: report at bugs.python.org (Graeme Smecher) Date: Wed, 23 Jan 2008 17:01:39 -0000 Subject: [issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c In-Reply-To: <1201107699.6.0.65670529647.issue1917@psf.upfronthosting.co.za> Message-ID: <1201107699.6.0.65670529647.issue1917@psf.upfronthosting.co.za> New submission from Graeme Smecher: On a BFLT (microblaze-uclinux) build of vanilla Python 2.5.1, "startup -v" produces the following: # python -v Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] # installing zipimport hook import zipimport # builtin # installed zipimport hook # /usr/local/lib/python2.5/site.pyc has bad mtime import site # from /usr/local/lib/python2.5/site.py # can't create /usr/local/lib/python2.5/site.pyc # /usr/local/lib/python2.5/os.pyc has bad mtime import os # from /usr/local/lib/python2.5/os.py # can't create /usr/local/lib/python2.5/os.pyc import posix # builtin # /usr/local/lib/python2.5/posixpath.pyc has bad mtime import posixpath # from /usr/local/lib/python2.5/posixpath.py # can't create /usr/local/lib/python2.5/posixpath.pyc # /usr/local/lib/python2.5/stat.pyc has bad mtime import stat # from /usr/local/lib/python2.5/stat.py # can't create /usr/local/lib/python2.5/stat.pyc # /usr/local/lib/python2.5/UserDict.pyc has bad mtime import UserDict # from /usr/local/lib/python2.5/UserDict.py # can't create /usr/local/lib/python2.5/UserDict.pyc # /usr/local/lib/python2.5/copy_reg.pyc has bad mtime import copy_reg # from /usr/local/lib/python2.5/copy_reg.py # can't create /usr/local/lib/python2.5/copy_reg.pyc # /usr/local/lib/python2.5/types.pyc has bad mtime import types # from /usr/local/lib/python2.5/types.py # can't create /usr/local/lib/python2.5/types.pyc import _types # builtin 'import site' failed; traceback: Traceback (most recent call last): File "/usr/local/lib/python2.5/site.py", line 62, in import os File "/usr/local/lib/python2.5/os.py", line 696, in import copy_reg as _copy_reg File "/usr/local/lib/python2.5/copy_reg.py", line 7, in from types import ClassType as _ClassType File "/usr/local/lib/python2.5/types.py", line 93, in import _types SystemError: _PyImport_FixupExtension: module _types not loaded # /usr/local/lib/python2.5/warnings.pyc has bad mtime import warnings # from /usr/local/lib/python2.5/warnings.py # can't create /usr/local/lib/python2.5/warnings.pyc # /usr/local/lib/python2.5/types.pyc has bad mtime import types # from /usr/local/lib/python2.5/types.py # can't create /usr/local/lib/python2.5/types.pyc import _types # builtin import encodings # directory /usr/local/lib/python2.5/encodings # /usr/local/lib/python2.5/encodings/__init__.pyc has bad mtime import encodings # from /usr/local/lib/python2.5/encodings/__init__.py # can't create /usr/local/lib/python2.5/encodings/__init__.pyc # /usr/local/lib/python2.5/codecs.pyc has bad mtime import codecs # from /usr/local/lib/python2.5/codecs.py # can't create /usr/local/lib/python2.5/codecs.pyc import _codecs # builtin # /usr/local/lib/python2.5/types.pyc has bad mtime import types # from /usr/local/lib/python2.5/types.py # can't create /usr/local/lib/python2.5/types.pyc import _types # builtin Python 2.5.1 (r251:54863, Jan 23 2008, 09:07:29) [GCC 3.4.1 ( PetaLinux 0.20 Build -rc1 050607 )] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> This is happening because the autogenerated _PyImport_Inittab in "Modules/config.c" (sensibly) contains the following startup definition: /* This lives in Python/_types.c */ {"_types", init_types}, The problem is that two distinct init_types() exist, and the microblaze-uclinux-gcc toolchain is picking up the wrong one. On x86 GCC producing ELF binaries, the linker picks up the correct init_types() defined in "Modules/_typesmodule.c". The above behaviour does not occur, and the interpreter starts up successfully. On Microblaze GCC producing BFLT binaries, the linker instead picks up init_types() defined in "Python/Python-ast.c", which is autogenerated from "Parser/asdl_c.py". The obvious fix is to change one of the init_types() to something else. I suspect this bug is related to Issue 1568243, which has been closed (apparently a different fix was in order for PCs.) The doubly-defined init_types() appears to still be present in the Subversion repository. For reference, my cross-compiler is configured as follows: $ microblaze-uclinux-gcc -v Reading specs from /lhome/gsmecher/petalinux-public/tools/linux-i386/microblaze-uclinux-tools/bin/../lib/gcc/microblaze-uclinux/3.4.1/specs Configured with: /home/jwilliams/PetaLogix/petalinux-test/toolchains/microblaze-uclinux/srcs/gcc/configure --target=microblaze-uclinux --prefix=/home/jwilliams/PetaLogix/petalinux-test/toolchains/microblaze-uclinux/microblaze-uclinux-tools --enable-languages=c,c++ --enable-multilib --enable-target-optspace --with-gnu-ld --disable-nls --disable-__cxa_atexit --disable-c99 --disable-clocale --disable-c-mbchar --disable-long-long --enable-threads=posix --enable-cxx-flags=-D_ISOC99_SOURCE -D_BSD_SOURCE Thread model: posix gcc version 3.4.1 ( PetaLinux 0.20 Build -rc1 050607 ) ---------- components: Build messages: 61589 nosy: gsmecher severity: minor status: open title: init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 18:10:51 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 23 Jan 2008 17:10:51 -0000 Subject: [issue1913] test_pep263 fails In-Reply-To: <1201076728.2.0.475967660638.issue1913@psf.upfronthosting.co.za> Message-ID: <1201108251.89.0.18813666136.issue1913@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60220. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 18:15:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 17:15:29 -0000 Subject: [issue1069410] import on Windows: please call SetErrorMode first Message-ID: <1201108529.11.0.52310925833.issue1069410@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied in 60221 ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 18:30:09 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 23 Jan 2008 17:30:09 -0000 Subject: [issue618633] sys.execpthook not used in threads Message-ID: <1201109409.25.0.665493797065.issue618633@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: This is a duplicate of a more recently opened #1230540. ---------- nosy: +draghuram resolution: -> duplicate status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Jan 23 18:55:22 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 17:55:22 -0000 Subject: [issue1789] incorrect assumption about unsigned long byte size In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za> Message-ID: <1201110922.22.0.637286597831.issue1789@psf.upfronthosting.co.za> Gregory P. Smith added the comment: eew, so the struct module does map as documented to the C types listed in the docs. yuck. regardless, changing the Ls to Is will fix the tutorial document code. I'll do that. I believe there are also other instances of wrong uses of L in struct in the code such as the zipfile module that will fail on LP64 platforms. I'll look for those (and why they weren't caught by unit tests). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 19:12:24 2008 From: report at bugs.python.org (Matt Kraai) Date: Wed, 23 Jan 2008 18:12:24 -0000 Subject: [issue1722225] Build on QNX 6 Message-ID: <1201111943.96.0.109677266251.issue1722225@psf.upfronthosting.co.za> Matt Kraai added the comment: If they're defined, TCGETA, TCSETA, TCSETAW, and TCSETAF are used on lines 702, 714, 717, and 720 of Modules/termios.c as of r60219. They are defined by sys/ioctl.h as #define TCGETA _IOR('T', 1, struct termio) #define TCSETA _IOW('T', 2, struct termio) #define TCSETAW _IOW('T', 3, struct termio) #define TCSETAF _IOW('T', 4, struct termio) These macro definitions expand to ( 0x40000000 | (( sizeof( struct termio ) & 0x3fff ) << 16) | (( ( 'T' ) ) << 8) | ( ( 1 ) )) ( 0x80000000 | (( sizeof( struct termio ) & 0x3fff ) << 16) | (( ( 'T' ) ) << 8) | ( ( 2 ) )) ( 0x80000000 | (( sizeof( struct termio ) & 0x3fff ) << 16) | (( ( 'T' ) ) << 8) | ( ( 3 ) )) ( 0x80000000 | (( sizeof( struct termio ) & 0x3fff ) << 16) | (( ( 'T' ) ) << 8) | ( ( 4 ) )) respectively, so struct termio must be declared if any of these macros are used. struct termio is declared in sys/termio.h. Since sys/termio.h isn't included, Modules/termios.c fails to compile with the following error messages: /home/m_kraai/src/python/Modules/termios.c:702: sizeof applied to an incomplete type /home/m_kraai/src/python/Modules/termios.c:714: sizeof applied to an incomplete type /home/m_kraai/src/python/Modules/termios.c:717: sizeof applied to an incomplete type /home/m_kraai/src/python/Modules/termios.c:720: sizeof applied to an incomplete type sys/termio.h checks that it's included before termios.h is first included. If it's not included first, it produces the following error message: /usr/qnx630/target/qnx6/usr/include/sys/termio.h:109: #error termio/termios incompatibility What should configure test for? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 19:12:26 2008 From: report at bugs.python.org (Neil Toronto) Date: Wed, 23 Jan 2008 18:12:26 -0000 Subject: [issue1568] PATCH: Armin's attribute lookup caching for 3.0 In-Reply-To: <1197034097.09.0.871896219058.issue1568@psf.upfronthosting.co.za> Message-ID: <1201111946.63.0.349641391369.issue1568@psf.upfronthosting.co.za> Neil Toronto added the comment: There's nothing it tests that standard unit tests don't, so it shouldn't stick around as a unit test. I used it to time different types of attribute lookups and left it in as an optimization aid. The main test groups are '.' access, successful hasattr (returns True), and failing hasattr (returns False). For each group it prints a header and then four test cases for each test class: metaclass attribute access (class.__class__), class attribute access (class.__init__), class attribute access via an instance (class().__class__), and instance attribute access (class().__init__). The test classes include a few built-ins and the classes of a made-up deep hierarchy. The main thing to notice is that, when you run this using the patched source, every number is no larger than when you run it using the trunk, and most are smaller. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 19:32:24 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 18:32:24 -0000 Subject: [issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c In-Reply-To: <1201107699.6.0.65670529647.issue1917@psf.upfronthosting.co.za> Message-ID: <1201113144.12.0.352351380233.issue1917@psf.upfronthosting.co.za> Christian Heimes added the comment: The compiler should not pick up the init_types function in Python/Python-ast.c. It's declared as static. The init_types function in Modules/_typesmodule.c is declared as extern so that's the real deal. It sounds more like a compiler or linker bug in the tool chain than a Python bug. ---------- nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 19:34:16 2008 From: report at bugs.python.org (Jeff Foran) Date: Wed, 23 Jan 2008 18:34:16 -0000 Subject: [issue1918] weak references are removed before __del__ is called. In-Reply-To: <1201113256.5.0.101842324307.issue1918@psf.upfronthosting.co.za> Message-ID: <1201113256.5.0.101842324307.issue1918@psf.upfronthosting.co.za> New submission from Jeff Foran: Not sure where to put example code, but here it goes: import weakref class MyObj(object): def __init__(self): self.ref = weakref.ref(self) def __del__(self): print "HERE123", self.ref() o = MyObj() o = None ---------- components: Interpreter Core messages: 61597 nosy: jforan severity: normal status: open title: weak references are removed before __del__ is called. type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 19:54:36 2008 From: report at bugs.python.org (Graeme Smecher) Date: Wed, 23 Jan 2008 18:54:36 -0000 Subject: [issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c In-Reply-To: <1201107699.6.0.65670529647.issue1917@psf.upfronthosting.co.za> Message-ID: <1201114476.41.0.313941385006.issue1917@psf.upfronthosting.co.za> Graeme Smecher added the comment: Hm, sorry for the static -- you're absolutely correct, this has to be a compiler/linker/elf2flt bug. I'll patch my build instead of whining here. Thanks -- Feel free to close the report. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 20:08:03 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 23 Jan 2008 19:08:03 -0000 Subject: [issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c In-Reply-To: <1201107699.6.0.65670529647.issue1917@psf.upfronthosting.co.za> Message-ID: <1201115283.38.0.629473506239.issue1917@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 20:13:20 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 23 Jan 2008 19:13:20 -0000 Subject: [issue1745035] DoS smtpd vulnerability Message-ID: <1201115600.7.0.805107416505.issue1745035@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I update this bug as GvR requested here: http://groups.google.it/group/python-dev2/browse_thread/thread/33cad7b7c1cdb19f?hl=it The patch in attachment fixes what discussed before. In addition it sets a smaller timeout for asyncore.loop() for permitting to stop the daemon via KeyboardInterrupt immediately. ---------- versions: +Python 2.5 Added file: http://bugs.python.org/file9272/smtpd.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 20:16:58 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 23 Jan 2008 19:16:58 -0000 Subject: [issue1736190] asyncore/asynchat patches Message-ID: <1201115818.85.0.452388365454.issue1736190@psf.upfronthosting.co.za> Changes by Giampaolo Rodola': ---------- severity: normal -> urgent type: -> security versions: +Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 20:17:37 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 23 Jan 2008 19:17:37 -0000 Subject: [issue1736190] asyncore/asynchat patches Message-ID: <1201115857.65.0.360688649491.issue1736190@psf.upfronthosting.co.za> Changes by Giampaolo Rodola': ---------- severity: urgent -> normal type: security -> versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 21:21:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2008 20:21:41 -0000 Subject: [issue1918] weak references are removed before __del__ is called. In-Reply-To: <1201113256.5.0.101842324307.issue1918@psf.upfronthosting.co.za> Message-ID: <1201119701.61.0.468606800793.issue1918@psf.upfronthosting.co.za> Christian Heimes added the comment: The behavior is documented in the C code. I don't know how it is described in the docs. Objects/typeobject.c around line 820 says: /* If we added a weaklist, we clear it. Do this *before* calling the finalizer (__del__), clearing slots, or clearing the instance dict. */ ---------- nosy: +tiran priority: -> normal resolution: -> wont fix status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 21:22:50 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 23 Jan 2008 20:22:50 -0000 Subject: [issue1722225] Build on QNX 6 Message-ID: <1201119770.1.0.22931951873.issue1722225@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the explanation; that makes sense (I didn't expect that the value of these constants depends on the size of some structure, normally, they are "truly" constant, e.g. 0x5405 on Linux). The autoconf test should check whether the header (sys/termio.h) is present, and then a conditional include of termio.h should be made under HAVE_SYS_TERMIO_H, with the a comment "for TCGETA" or some such. This would fix the problem for any other system that has the same approach to ioctl codes. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 21:38:01 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 20:38:01 -0000 Subject: [issue1789] incorrect assumption about unsigned long byte size In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za> Message-ID: <1201120681.89.0.643799410299.issue1789@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The documentation for the struct module says: "short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows) is 8 bytes" and lists 'l' and 'L' as the pack code for a C long. As it is implemented today, the documentation is incorrect. On an LP64 host (pretty much any 64-bit linux, bsd or unixish OS; not windows) a long is 8 bytes. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 21:49:57 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 20:49:57 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness Message-ID: <1201121397.34.0.925450852689.issue1303614@psf.upfronthosting.co.za> Guido van Rossum added the comment: Reopening, since test67.py still causes a segfault in the trunk. It is represented as Lib/test/crashers/loosing_dict_ref.py [sic]. ---------- nosy: +gvanrossum priority: normal -> urgent status: closed -> open _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 21:56:29 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 20:56:29 -0000 Subject: [issue1918] weak references are removed before __del__ is called. In-Reply-To: <1201113256.5.0.101842324307.issue1918@psf.upfronthosting.co.za> Message-ID: <1201121789.35.0.868313876398.issue1918@psf.upfronthosting.co.za> Guido van Rossum added the comment: Georg, can you update the docs? Weak references *to* an object are cleared before the object's __del__ is called, to ensure that the weak reference callback (if any) finds the object healthy. ---------- assignee: -> georg.brandl nosy: +georg.brandl, gvanrossum status: pending -> open versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 21:59:14 2008 From: report at bugs.python.org (Matt Kraai) Date: Wed, 23 Jan 2008 20:59:14 -0000 Subject: [issue1722225] Build on QNX 6 Message-ID: <1201121954.46.0.587465232116.issue1722225@psf.upfronthosting.co.za> Matt Kraai added the comment: This patch contains two improvements over the previous version: * it uses configure to check whether sys/termio.h is available and uses the result to determine whether to include it and * it makes malloc_closure.c use _SC_PAGESIZE instead of getpagesize if it's available. I believe there are two unresolved issues at this point, the wchar_t definition and the stack size. [n]curses.h defines wchar_t if _XOPEN_SOURCE_EXTENDED is defined and if _WCHAR_T is not defined: #ifdef _XOPEN_SOURCE_EXTENDED #ifndef _WCHAR_T typedef unsigned long wchar_t; #endif /* _WCHAR_T */ #ifndef _WINT_T typedef long int wint_t; #endif /* _WINT_T */ stdlib.h defines wchar_t if __WCHAR_T is defined: #if defined(__WCHAR_T) typedef __WCHAR_T wchar_t; #undef __WCHAR_T #endif I'm afraid I don't quite understand what configure should test for in this case either. Please help! Regarding the stack size, how can I test whether 2MiB is sufficient for the default recursion limit? Added file: http://bugs.python.org/file9273/patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 22:28:21 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 21:28:21 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1201099585.88.0.373241749138.issue1577@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Before tackling this, I'd like a precision on os.rename(src, dst) > semantics. The documentation says "If dst is a directory, OSError will > be raised". However, under Linux, if src is a directory and dst is an > empty directory, dst is overwritten with src: > > $ mkdir src dst > $ touch dst/t > $ ./python -c "import os; os.rename('src', 'dst')" > Traceback (most recent call last): > File "", line 1, in > OSError: [Errno 39] Directory not empty > $ rm dst/t > $ ./python -c "import os; os.rename('src', 'dst')" > $ > > Is this a bug, a misfeature, or just an imprecision in the documentation? To be honest, I wasn't aware of this behavior of the rename() system call for directories on Unix. It is most certainly a feature (of the system call) that should be maintained (for the system call wrapper). shutil.move() should not mimic this though -- it should more closely approximate the "mv" utility's behavior, which doesn't differentiate between empty and non-empty destination directories, and always moves *into* the target when it is a directory (and complains if the resulting destination path already exists). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 22:33:15 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 21:33:15 -0000 Subject: [issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c In-Reply-To: <1201107699.6.0.65670529647.issue1917@psf.upfronthosting.co.za> Message-ID: <1201123995.19.0.814344858919.issue1917@psf.upfronthosting.co.za> Guido van Rossum added the comment: The comment in config.c is wrong. If you still have a Python/_typesmodule.c file, something's wrong on your end! ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 22:33:54 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 21:33:54 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness Message-ID: <1201124034.13.0.214083283956.issue1303614@psf.upfronthosting.co.za> Guido van Rossum added the comment: Armin, what do you think of the attached patch (deldict.diff)? Added file: http://bugs.python.org/file9274/deldict.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 22:37:43 2008 From: report at bugs.python.org (Graeme Smecher) Date: Wed, 23 Jan 2008 21:37:43 -0000 Subject: [issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c In-Reply-To: <1201107699.6.0.65670529647.issue1917@psf.upfronthosting.co.za> Message-ID: <1201124263.52.0.276047994697.issue1917@psf.upfronthosting.co.za> Graeme Smecher added the comment: Hi Guido, Yup! From the tarball (Python-2.5.1.tgz), the actual comment (in Modules/config.c.in) reads: /* This lives in Python/_types.c */ {"_types", init_types}, ...which is different from the snippet I posted here (I hand-reverted my modifications, but got the comment wrong), but still incorrect (should be "Modules/_types.c".) cheers, Graeme __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 22:45:12 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 21:45:12 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness Message-ID: <1201124712.89.0.033803480246.issue1303614@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a better fix, which also fixes the similar code path in GenericSetAttr(). As a bonus, I reviewed all uses of _PyObject_GetDictPtr() and found one questionable place where the dict at *dictptr was DECREF'ed before that location was set to NULL. I think we're better off setting it to NULL and *then* DECREF'ing the dict. ---------- resolution: fixed -> versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 22:45:35 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 21:45:35 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness Message-ID: <1201124735.49.0.752885366948.issue1303614@psf.upfronthosting.co.za> Changes by Guido van Rossum: Added file: http://bugs.python.org/file9275/deldict.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 22:45:52 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 21:45:52 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness Message-ID: <1201124752.74.0.332453875102.issue1303614@psf.upfronthosting.co.za> Changes by Guido van Rossum: Removed file: http://bugs.python.org/file9274/deldict.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 22:49:49 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Jan 2008 21:49:49 -0000 Subject: [issue1789] assumption about unsigned long byte size in struct module usage In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za> Message-ID: <1201124989.81.0.935921615698.issue1789@psf.upfronthosting.co.za> Gregory P. Smith added the comment: A significant portion of the python standard library is broken due to incorrect use of the struct module on LP64 platforms. I'm attaching a patch that should clean it up. I need Mac OS X people to confirm that the Mac changes are sane. Its possible that the Lib/posixfile.py change could be a candidate for a 2.4 security backport if it turns out the _posixfile_.lock() implementation is indeed broken when a 64bit python is used on some platforms. I'll leave that up to the 2.4 releaser to decide. ---------- components: +Library (Lib) keywords: +64bit, patch -easy priority: normal -> high severity: normal -> major title: incorrect assumption about unsigned long byte size -> assumption about unsigned long byte size in struct module usage versions: +Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9276/struct-long-nuke-01.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 23:14:10 2008 From: report at bugs.python.org (Neal Norwitz) Date: Wed, 23 Jan 2008 22:14:10 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness Message-ID: <1201126450.98.0.157899127447.issue1303614@psf.upfronthosting.co.za> Changes by Neal Norwitz: ---------- nosy: +nnorwitz _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 23 23:20:55 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 23 Jan 2008 22:20:55 -0000 Subject: [issue1743] IDLE fails to launch In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za> Message-ID: <1201126855.78.0.863255323075.issue1743@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Thanks for the fix. r60225. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 23:21:56 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 23 Jan 2008 22:21:56 -0000 Subject: [issue1862] Error on "Save As" in IDLE (Vista 32-bit) In-Reply-To: <1200588984.34.0.741777378011.issue1862@psf.upfronthosting.co.za> Message-ID: <1201126916.78.0.891751780231.issue1862@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r60225. Dup of Issue 1743. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 23:27:17 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 23 Jan 2008 22:27:17 -0000 Subject: [issue1789] assumption about unsigned long byte size in struct module usage In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za> Message-ID: <1201127237.22.0.0529334587343.issue1789@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- priority: high -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 23:30:09 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 23 Jan 2008 22:30:09 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1201127409.09.0.345705340629.issue1794@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 23:30:44 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 23 Jan 2008 22:30:44 -0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1201127444.84.0.766373096283.issue1794@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: ---------- components: -IDLE __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 23:36:33 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 23 Jan 2008 22:36:33 -0000 Subject: [issue1599] IDLE hangs if os.spwanv command is given In-Reply-To: <1198817915.6.0.119772685048.issue1599@psf.upfronthosting.co.za> Message-ID: <1201127793.11.0.112393242368.issue1599@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: Removed file: http://bugs.python.org/file9032/unnamed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 23:37:40 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 23 Jan 2008 22:37:40 -0000 Subject: [issue1599] IDLE hangs if os.spwanv command is given In-Reply-To: <1198817915.6.0.119772685048.issue1599@psf.upfronthosting.co.za> Message-ID: <1201127860.6.0.0481558112747.issue1599@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Does it fail for foo.py: def foo(): pass >>> import os >>> os.spawnv(os.P_NOWAIT, 'foo.py', '') 5026 >>> __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 23 23:56:55 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 23 Jan 2008 22:56:55 -0000 Subject: [issue1647] IDLE messes around with sys.exitfunc In-Reply-To: <1197948552.45.0.790109797324.issue1647@psf.upfronthosting.co.za> Message-ID: <1201129015.38.0.451037503484.issue1647@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: And yet some people were seeing this error. I was not, on Linux, and I don't know why. Fixed at r60227. ---------- resolution: works for me -> fixed versions: -Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 00:02:15 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2008 23:02:15 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness Message-ID: <1201129335.0.0.914035461832.issue1303614@psf.upfronthosting.co.za> Guido van Rossum added the comment: The more i think about it, I don't think the issue in typeobject.c can ever occur, so I'm skipping that part of the fix. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 24 03:57:22 2008 From: report at bugs.python.org (Adam Olsen) Date: Thu, 24 Jan 2008 02:57:22 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness Message-ID: <1201143442.26.0.0737443393219.issue1303614@psf.upfronthosting.co.za> Changes by Adam Olsen: ---------- nosy: +Rhamphoryncus _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 24 04:08:04 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 24 Jan 2008 03:08:04 -0000 Subject: [issue1910] Document that with is slower than try/finally In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> Message-ID: <1201144084.43.0.601986255171.issue1910@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Most platforms use the faster thread.LockType. Correct? Perhaps, since this module is more a reference implementation and it is pointed to by the threading docs (http://docs.python.org/lib/module-threading.html), we should elect to take the more pythonic route on this. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 04:54:16 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 24 Jan 2008 03:54:16 -0000 Subject: [issue1910] Document that with is slower than try/finally In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> Message-ID: <1201146856.54.0.695410557129.issue1910@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Generally we don't document the speed differences between various alternatives. One reason is that relative performance varies across releases and platforms. Another reason is that the rule in this case is somewhat generic (inlined code is typically faster than making a call to the same code without in-lining. Us developers are supposed to know that sort of thing or time it if we don't. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 05:06:17 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 24 Jan 2008 04:06:17 -0000 Subject: [issue1910] Document that with is slower than try/finally In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> Message-ID: <1201147577.93.0.63876235717.issue1910@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Amaury, please do revert 60189. There is no reason to destabalize this code, slow it down, and introduce new dependencies. Use of the with-statement is not in and of itself a "best practice". Where it really shines is in factoring-away repeated setup/teardown code. Modules that serve as elemental building blocks (like threading, Queue, heapq, etc) need to have fast, clean code with as few dependencies as possible. Also, we should change/modernize something like asyncore or threading with a great deal of care and restraint. It is too easy to introduce hard to find bugs in this code. It took a long time for this code to stabalize and we should enjoy the benefits of its maturity. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 08:12:12 2008 From: report at bugs.python.org (Neal Norwitz) Date: Thu, 24 Jan 2008 07:12:12 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness In-Reply-To: <1201143442.37.0.111260340717.issue1303614@psf.upfronthosting.co.za> Message-ID: Neal Norwitz added the comment: I looked at Guido's latest deldict.diff patch--the one to Objects/object.c only. It seems good. I can't convince myself either way about the change to Objects/typeobject.c. I can't think of a way to cause a problem. It seems safer to use Py_CLEAR in this case though. There are several other uses of _PyObject_GetDictPtr in Objects/typeobject.c. It was pretty much the same--I can't convince myself either way. Can Py_VISIT cause any Python code to execute that might lead to a problem? The other uses of _PyObject_GetDictPtr in Objects/typeobject.c seemed safer. Not a very useful review. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 24 08:46:26 2008 From: report at bugs.python.org (Neal Norwitz) Date: Thu, 24 Jan 2008 07:46:26 -0000 Subject: [issue1617] Rare exception in test_urllib2net In-Reply-To: <1197580068.32.0.710021018285.issue1617@psf.upfronthosting.co.za> Message-ID: <1201160786.73.0.036509465177.issue1617@psf.upfronthosting.co.za> Neal Norwitz added the comment: This started happening consistently on my box and I was able to reproduce it. Revision 60233 should fix this problem. I forwarded the checkin to Greg. Hopefully he can comment if there is a problem. (Also cc'd him on this bug report that I'm now closing.) ---------- assignee: -> nnorwitz nosy: +gregory.p.smith resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 10:40:19 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 24 Jan 2008 09:40:19 -0000 Subject: [issue1789] assumption about unsigned long byte size in struct module usage In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za> Message-ID: <1201167619.08.0.225378423031.issue1789@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Anders J. Munch on python-dev correctly says: You overlooked the words "Standard size and alignment are as follows" that start the quoted paragraph. It's a little confusing because standard size is not the default. The default is platform-specific sizes. Only if you start the format string with >, <, ! or = do you get standard sizes. The reference documentation is correct as it stands, and, I suspect, so is the LP64 implementation. Doesn't struct.pack('>l',42) produce a 4-byte string on LP64? The tutorial at http://docs.python.org/tut/node13.html#SECTION0013300000000000000000%3E has a bug though: the format string should use '<'. I believe zipfile.py correctly uses '<' throughout. ---------- keywords: +easy -patch priority: urgent -> normal severity: major -> normal versions: -Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 10:45:13 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 24 Jan 2008 09:45:13 -0000 Subject: [issue1789] assumption about unsigned long byte size in struct module usage In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za> Message-ID: <1201167913.71.0.193435100356.issue1789@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The giant patch was unnecessary, I misread what the struct module was actually doing. Auditing all uses of struct in the standard library the only ones that look suspicious to me are: Lib/posixfile.py and all of the uses in Lib/plat-mac/ posixfile is probably fine, but it wouldn't surprise me if there are bugs on some platforms in there due to using 'l' to decode off_t and 'h' to decode pid_t within a fcntl structure. The plat-mac stuff might break assuming those APIs are even available to 64bit programs. I'll leave that up to the mac porting folks, as it is its difficult if not impossible to even build a 64-bit Python under OS X. Fixed in trunk r60234. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 11:06:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 24 Jan 2008 10:06:18 -0000 Subject: [issue1576] [Patch] Working post import hook and lazy modules In-Reply-To: <1197230661.71.0.762361261009.issue1576@psf.upfronthosting.co.za> Message-ID: <1201169178.69.0.70417947707.issue1576@psf.upfronthosting.co.za> Christian Heimes added the comment: The post import hook patch is in my pep 369 branch. ---------- resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 11:06:38 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 24 Jan 2008 10:06:38 -0000 Subject: [issue1795] PEP 754 update In-Reply-To: <1200076052.83.0.229945394685.issue1795@psf.upfronthosting.co.za> Message-ID: <1201169198.19.0.352242133338.issue1795@psf.upfronthosting.co.za> Christian Heimes added the comment: I've updated the PEP last week. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 12:41:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 24 Jan 2008 11:41:41 -0000 Subject: [issue1919] Backport of io.py In-Reply-To: <1201174901.71.0.122218114057.issue1919@psf.upfronthosting.co.za> Message-ID: <1201174901.71.0.122218114057.issue1919@psf.upfronthosting.co.za> New submission from Christian Heimes: I've started on a back port of Python 3.0's io.py to Python 2.6. First results are promising. cd trunk svn cp ../py3k/Include/bytes_methods.h Include/ svn cp ../py3k/Objects/bytes_methods.c Objects/ svn cp ../py3k/Lib/io.py Lib/ svn cp ../py3k/Lib/test/test_io.py Lib/test/ svn cp ../py3k/Modules/_fileio.c Modules/ patch -p0 < trunk_io.patch I'm not sure how to proceed with the missing bytearray type: * backport bytearray and the new buffer interface from 3.0 * write a replacement for 2.6 * replace the bytearray code with new code ---------- components: Interpreter Core, Library (Lib) files: trunk_io.patch messages: 61626 nosy: tiran priority: normal severity: normal status: open title: Backport of io.py type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9277/trunk_io.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 13:24:36 2008 From: report at bugs.python.org (Maciek Fijalkowski) Date: Thu, 24 Jan 2008 12:24:36 -0000 Subject: [issue1326] "internal" zipimport.zipimporter feature untested In-Reply-To: <1193317680.83.0.000309828654595.issue1326@psf.upfronthosting.co.za> Message-ID: <1201177476.18.0.0246872541936.issue1326@psf.upfronthosting.co.za> Maciek Fijalkowski added the comment: There is another untested and undocumented attribute called prefix on zipimporter objects. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 13:44:54 2008 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 24 Jan 2008 12:44:54 -0000 Subject: [issue1765140] logging: delay_fh option and configuration kwargs Message-ID: <1201178694.69.0.528795611688.issue1765140@psf.upfronthosting.co.za> Vinay Sajip added the comment: Added optional delay argument to FileHandler and subclasses. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 24 14:22:49 2008 From: report at bugs.python.org (Mark Summerfield) Date: Thu, 24 Jan 2008 13:22:49 -0000 Subject: [issue1920] while else loop seems to behave incorrectly In-Reply-To: <1201180969.36.0.961933968615.issue1920@psf.upfronthosting.co.za> Message-ID: <1201180969.36.0.961933968615.issue1920@psf.upfronthosting.co.za> New submission from Mark Summerfield: I am using: Python 3.0a2 (r30a2:59382, Dec 17 2007, 08:47:22) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 IDLE 3.0a1 This seems wrong: >>> while False: print("no") else: print("yes") >>> I expected it to print "yes" because the docs say that the else suite is executed if present and if the loop terminated normally (no break), and this is the case here. This works though: >>> x = False >>> while x: print("no") else: print("yes") yes >>> So it seems that "while False" and "while variable" are giving different behaviour. ---------- components: Interpreter Core messages: 61629 nosy: mark severity: normal status: open title: while else loop seems to behave incorrectly type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 14:33:21 2008 From: report at bugs.python.org (Thomas Heller) Date: Thu, 24 Jan 2008 13:33:21 -0000 Subject: [issue1919] Backport of io.py In-Reply-To: <1201174901.71.0.122218114057.issue1919@psf.upfronthosting.co.za> Message-ID: <1201181601.2.0.458730014357.issue1919@psf.upfronthosting.co.za> Thomas Heller added the comment: > * backport bytearray and the new buffer interface from 3.0 backport of the new buffer interface is required for PEP 3118 which is marked accepted: " It is intended that this PEP will be back-ported to Python 2.6 by adding the C-API and the two functions to the existing buffer protocol. " ---------- nosy: +theller __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 14:35:47 2008 From: report at bugs.python.org (Antti Rasinen) Date: Thu, 24 Jan 2008 13:35:47 -0000 Subject: [issue1921] Confusing Descrintro example In-Reply-To: <1201181747.66.0.31684496906.issue1921@psf.upfronthosting.co.za> Message-ID: <1201181747.66.0.31684496906.issue1921@psf.upfronthosting.co.za> New submission from Antti Rasinen: Guido's document "Unifying types and classes in Python 2.2" (descrintro) contains a confusing example for metaclass newbies. The example in question is autoprop, which uses the variable "name" in three different contexts. First, it is the name of the class being created. Second, it is used in a for loop to denote the keys of the class dict. And thirdly, it is used to denote substrings of a subset of those keys. Upon my first encounter with the example, I found myself staring at the getattr and setattr lines in disbelief. I associated "name" as the parameter given to the __init__ function. I'd propose changing the first for-loop name to "member" or similar and the second to "propname" or "prop". Furthermore, a modern version of the same example could use sets and set comprehensions instead of dict.keys(): props = {member[5:] for member in dict if member.startswith...} ---------- components: Documentation messages: 61631 nosy: arsatiki severity: minor status: open title: Confusing Descrintro example type: rfe versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 14:42:46 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 24 Jan 2008 13:42:46 -0000 Subject: [issue1920] while else loop seems to behave incorrectly In-Reply-To: <1201180969.36.0.961933968615.issue1920@psf.upfronthosting.co.za> Message-ID: <1201182166.72.0.951521116017.issue1920@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: python 2.5 has the same behaviour, if you use "while 0:" instead. In compiler.c, there is code that optimizes away blocks like "if 0", "while 0". 'if' correctly emit the else clause, 'while' does not... ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 16:44:01 2008 From: report at bugs.python.org (Stephen Emslie) Date: Thu, 24 Jan 2008 15:44:01 -0000 Subject: [issue1923] meaningful whitespace can be lost in rfc822_escape In-Reply-To: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za> Message-ID: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za> New submission from Stephen Emslie: distutils.util.rfc822_escape strips each line of its whitespace before indenting, but this can mean losing meaningful whitespace, such as in reStructuredText. distutils uses rfc822_escape to escape fields in metadata, such as PKG-INFO. This unfortunately means that you cant use reStructuredText formatting in your long description (suggested in PEP345), or are limited to a set that doesn't require indentation (no block quotes, etc.). for example: >>> rest = """ ... a literal python block:: ... >>> import this ... """ >>> print distutils.util.rfc822_escape(rest) a literal python block:: >>> import this I would be expecting this to look something like: a literal python block:: >>> import this It looks like this behavior was intentionally added in rev 20099, but that was about 7 years ago - before reStructuredText and eggs. I wonder if it makes sense to re-think that implementation with this sort of metadata in mind, assuming this behavior isn't required to be rfc822 compliant. I think it would certainly be a shame to miss out on a good thing like proper (renderable) reST in our metadata. Is distutils being over-cautious in flattening out all whitespace? A w3c discussion on multiple lines in rfc822 [1] seems to suggest that whitespace can be 'unfolded' safely, so it seems a shame to be throwing it away when it can have important meaning. http://www.w3.org/Protocols/rfc822/3_Lexical.html ---------- components: Library (Lib) messages: 61633 nosy: stephenemslie severity: normal status: open title: meaningful whitespace can be lost in rfc822_escape type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 17:00:53 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 24 Jan 2008 16:00:53 -0000 Subject: [issue1920] while else loop seems to behave incorrectly In-Reply-To: <1201180969.36.0.961933968615.issue1920@psf.upfronthosting.co.za> Message-ID: <1201190453.84.0.213141084443.issue1920@psf.upfronthosting.co.za> Mark Dickinson added the comment: This bug is also present in the trunk, with while 0 instead of while False. This appears closely related to issue #1875. In my opinion this is a serious bug in the core language. I'm not sure whether it's serious enough to be considered a showstopper for 2.5.2. In any case, I'm raising the priority to get more eyes on this before 2.5.2. ---------- nosy: +marketdickinson priority: -> urgent versions: +Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 17:14:50 2008 From: report at bugs.python.org (David Goodger) Date: Thu, 24 Jan 2008 16:14:50 -0000 Subject: [issue1924] %i string format breaks for large floats (incomplete int conversion) In-Reply-To: <1201191290.86.0.944658382949.issue1924@psf.upfronthosting.co.za> Message-ID: <1201191290.86.0.944658382949.issue1924@psf.upfronthosting.co.za> New submission from David Goodger: I ran across this bug in some legacy production code when numbers got high: >>> '%i' % 2e9 '2000000000' >>> '%i' % 3e9 Traceback (most recent call last): File "", line 1, in ? TypeError: int argument required It looks like the float is being automatically converted to an int, but floats > sys.maxint cause an error. However, >>> int(3e9) 3000000000L So the implicit float-to-int conversion is imperfect; large floats are not being converted to long ints. Same error in Python 2.3 through 2.6a0 (as of 2007-12-28). In Python 2.1.3 & 2.2.3 the error is "OverflowError: float too large to convert". The same error is triggered by int(3e9) though. While it's arguably not-quite-sane to have code that triggers this error, the inconsistency is what concerns me. ---------- components: Interpreter Core messages: 61635 nosy: goodger severity: normal status: open title: %i string format breaks for large floats (incomplete int conversion) type: behavior versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 17:22:43 2008 From: report at bugs.python.org (Facundo Batista) Date: Thu, 24 Jan 2008 16:22:43 -0000 Subject: [issue1742669] "%d" format handling for long values Message-ID: <1201191763.24.0.523567293622.issue1742669@psf.upfronthosting.co.za> Facundo Batista added the comment: Closed issue 1924 as duplicate of this one, but I'm copying here the text from David, as it's very explanative: """ I ran across this bug in some legacy production code when numbers got high: >>> '%i' % 2e9 '2000000000' >>> '%i' % 3e9 Traceback (most recent call last): File "", line 1, in ? TypeError: int argument required It looks like the float is being automatically converted to an int, but floats > sys.maxint cause an error. However, >>> int(3e9) 3000000000L So the implicit float-to-int conversion is imperfect; large floats are not being converted to long ints. Same error in Python 2.3 through 2.6a0 (as of 2007-12-28). In Python 2.1.3 & 2.2.3 the error is "OverflowError: float too large to convert". The same error is triggered by int(3e9) though. While it's arguably not-quite-sane to have code that triggers this error, the inconsistency is what concerns me. """ ---------- nosy: +goodger _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 24 17:23:18 2008 From: report at bugs.python.org (Facundo Batista) Date: Thu, 24 Jan 2008 16:23:18 -0000 Subject: [issue1924] %i string format breaks for large floats (incomplete int conversion) In-Reply-To: <1201191290.86.0.944658382949.issue1924@psf.upfronthosting.co.za> Message-ID: <1201191798.16.0.422309908988.issue1924@psf.upfronthosting.co.za> Facundo Batista added the comment: Duplicates #1742669 (copied this text to there) ---------- nosy: +facundobatista resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 17:24:27 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 24 Jan 2008 16:24:27 -0000 Subject: [issue1875] "if 0: return" not raising SyntaxError In-Reply-To: <1200768950.55.0.245752373825.issue1875@psf.upfronthosting.co.za> Message-ID: <1201191867.12.0.852704564612.issue1875@psf.upfronthosting.co.za> Mark Dickinson added the comment: See also issue #1920 ---------- nosy: +marketdickinson __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 17:41:31 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 24 Jan 2008 16:41:31 -0000 Subject: [issue1920] while else loop seems to behave incorrectly In-Reply-To: <1201180969.36.0.961933968615.issue1920@psf.upfronthosting.co.za> Message-ID: <1201192891.38.0.853398623517.issue1920@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Here is a patch, made against py3k; it should apply cleanly to the trunk. On the 2.5 branch, compile.c seems identical, but test_grammar.py looks very different; the conversion should be easy. Can someone review and apply it? I don't have svn access at the moment. Added file: http://bugs.python.org/file9279/while.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 18:05:15 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Jan 2008 17:05:15 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness In-Reply-To: Message-ID: Guido van Rossum added the comment: On Jan 23, 2008 11:12 PM, Neal Norwitz wrote: > > Neal Norwitz added the comment: > > I looked at Guido's latest deldict.diff patch--the one to > Objects/object.c only. It seems good. I can't convince myself either > way about the change to Objects/typeobject.c. I can't think of a way > to cause a problem. It seems safer to use Py_CLEAR in this case > though. Here's my reasoning: the object whose dict is being cleared itself has a refcount of zero at this point. So it is truly unreachable from Python code. So I'm not going to submit that part of the change. > There are several other uses of _PyObject_GetDictPtr in > Objects/typeobject.c. It was pretty much the same--I can't convince > myself either way. Can Py_VISIT cause any Python code to execute that > might lead to a problem? The answer lies in the gc module which does all the visiting. A quick scan of all the traverse() calls there indicates that none of them call back into Python -- not a DECREF in sight. > The other uses of _PyObject_GetDictPtr in > Objects/typeobject.c seemed safer. Not a very useful review. I reviewed those too and found them safe. I'll submit the change now. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 24 18:34:19 2008 From: report at bugs.python.org (Egon Frerich) Date: Thu, 24 Jan 2008 17:34:19 -0000 Subject: [issue1925] TypeError in deepcopy In-Reply-To: <1201196058.93.0.571748952585.issue1925@psf.upfronthosting.co.za> Message-ID: <1201196058.93.0.571748952585.issue1925@psf.upfronthosting.co.za> New submission from Egon Frerich: Traceback (most recent call last): File "/home/egon/Entwicklung/notes/gui/uicommand.py", line 645, in doCommand self.controller.copyItemID() File "/home/egon/Entwicklung/notes/gui/navicontroller.py", line 306, in copyItemID id_copy = self.Sammlung.kopiereEintrag(id) File "/home/egon/Entwicklung/notes/domain/note.py", line 185, in kopiereEintrag EintragKopie = copy.deepcopy(Eintrag) File "/usr/lib/python2.5/copy.py", line 189, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/usr/lib/python2.5/copy.py", line 337, in _reconstruct state = deepcopy(state, memo) File "/usr/lib/python2.5/copy.py", line 162, in deepcopy y = copier(x, memo) File "/usr/lib/python2.5/copy.py", line 254, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/usr/lib/python2.5/copy.py", line 189, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/usr/lib/python2.5/copy.py", line 337, in _reconstruct state = deepcopy(state, memo) File "/usr/lib/python2.5/copy.py", line 162, in deepcopy y = copier(x, memo) File "/usr/lib/python2.5/copy.py", line 254, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/usr/lib/python2.5/copy.py", line 189, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/usr/lib/python2.5/copy.py", line 322, in _reconstruct y = callable(*args) File "/usr/lib/python2.5/copy_reg.py", line 92, in __newobj__ return cls.__new__(cls, *args) TypeError: object.__new__(PySwigObject) is not safe, use PySwigObject.__new__() ---------- components: Library (Lib) messages: 61641 nosy: efrerich severity: normal status: open title: TypeError in deepcopy type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 18:42:02 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 24 Jan 2008 17:42:02 -0000 Subject: [issue784443] test_repr failure on m68k-linux Message-ID: <1201196522.21.0.173749885981.issue784443@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Considering that there is no activity for long time, is it worthwhile to keep this open? ---------- nosy: +draghuram ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 24 18:45:28 2008 From: report at bugs.python.org (Facundo Batista) Date: Thu, 24 Jan 2008 17:45:28 -0000 Subject: [issue784443] test_repr failure on m68k-linux Message-ID: <1201196728.55.0.558392517554.issue784443@psf.upfronthosting.co.za> Facundo Batista added the comment: Can anybody reproduce this in 2.5? If yes, update the "version"; otherwise we can close it. ---------- nosy: +facundobatista ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 24 18:47:36 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 24 Jan 2008 17:47:36 -0000 Subject: [issue817920] select behavior undefined for empty lists Message-ID: <1201196856.53.0.541264008924.issue817920@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: no activity. closing it. ---------- nosy: +draghuram resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 24 18:56:44 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 24 Jan 2008 17:56:44 -0000 Subject: [issue835338] [2.3.2] test_socket failure on IRIX 6.5 Message-ID: <1201197404.05.0.29620238583.issue835338@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Please reopen if the problem can be reproduced with latest version. ---------- nosy: +draghuram resolution: -> works for me status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 24 19:11:02 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Jan 2008 18:11:02 -0000 Subject: [issue1919] Backport of io.py In-Reply-To: <1201174901.71.0.122218114057.issue1919@psf.upfronthosting.co.za> Message-ID: <1201198262.15.0.178620684674.issue1919@psf.upfronthosting.co.za> Guido van Rossum added the comment: Backporting bytearray should be relatively clean since it's a brand new type right? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 19:30:08 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Jan 2008 18:30:08 -0000 Subject: [issue1925] TypeError in deepcopy In-Reply-To: <1201196058.93.0.571748952585.issue1925@psf.upfronthosting.co.za> Message-ID: <1201199408.69.0.563829100732.issue1925@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, we're not able to help with SWIG errors in this bug tracker. ---------- nosy: +gvanrossum resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 19:41:35 2008 From: report at bugs.python.org (Ray Chason) Date: Thu, 24 Jan 2008 18:41:35 -0000 Subject: [issue1926] NNTPS support in nntplib In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za> Message-ID: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za> New submission from Ray Chason: This patch adds SSL support to nntplib. It is a followup to issue #1535659 and addresses the objections raised in the comments to that issue; it also changes the default port to 563 (nntps) rather than 119 if SSL is requested. ---------- components: Library (Lib) files: python-nntps-patch-1.txt messages: 61648 nosy: chasonr severity: normal status: open title: NNTPS support in nntplib type: rfe versions: Python 2.5 Added file: http://bugs.python.org/file9280/python-nntps-patch-1.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 19:57:55 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Jan 2008 18:57:55 -0000 Subject: [issue1303614] Bypassing __dict__ readonlyness Message-ID: <1201201075.82.0.57764538015.issue1303614@psf.upfronthosting.co.za> Guido van Rossum added the comment: r60247 (2.5.2 branch), r60246 (2.6 trunk). ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 24 19:59:44 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Jan 2008 18:59:44 -0000 Subject: [issue1377858] segfaults when using __del__ and weakrefs Message-ID: <1201201184.92.0.430861241616.issue1377858@psf.upfronthosting.co.za> Guido van Rossum added the comment: This got fixed for classic classes in r60057, and backported to 2.5.2 in 60056. ---------- nosy: +gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 24 20:25:39 2008 From: report at bugs.python.org (Richard Cooper) Date: Thu, 24 Jan 2008 19:25:39 -0000 Subject: [issue1389051] imaplib causes excessive fragmentation for large documents Message-ID: <1201202739.11.0.985062722857.issue1389051@psf.upfronthosting.co.za> Richard Cooper added the comment: I think I was just bitten by the non-SSL version of this bug on Python 2.5.1 (r251:54863) on Mac OS 10.5. It manifested itself as a "malloc error: can't allocate region" while downloading a message using imaplib. As suggested by effbot I changed "data = self._sock.recv(recv_size)" to "data = self._sock.recv(min(recv_size, 16384))" in both places that line appears in socket.py. Making that change fixed the problem for me. Note that http://bugs.python.org/issue1092502 seems to be a duplicate of this issue. That issue contains a slightly different fix proposed by a_lauer, which I've not tried. ---------- nosy: +rich _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 24 21:21:19 2008 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 24 Jan 2008 20:21:19 -0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> New submission from Skip Montanaro: >From a thread on python-dev... http://mail.python.org/pipermail/python-dev/2008-January/076446.html Mike Kent mike.kent at sage.com Thu Jan 24 16:33:47 CET 2008 Recently I was trying to debug an old python program who's maintenance I inherited. I was using the quick-and-dirty method of putting some 'print >>sys.stderr' statements in the code, and then running the command with '2>filename' appended to the end of the command line. Imagine my surprise to see that all of the prompt text from the program's raw_input calls were also disappearing from the screen output, and appearing in the stderr output routed to the file. The latest documentation for raw_input states "If the prompt argument is present, it is written to standard output without a trailing newline." I posted a question regarding the observed behavior to comp.lang.python and Gabriel Genellina (thanks Gabriel!) pointed out that despite the documentation, raw_input was hard-coded to always output its prompt text to stderr. This raises two questions: 1. Shouldn't the current documentation be corrected to state that raw_input writes its prompt to standard error? 2. Is this really the hard-coded behavior we want? I don't think my use-case is that odd; in fact, what I find very odd is that the prompt output is send to stderr. I mean, I'm printing the prompt for a question, not some error message. Can there not at least be an optional parameter to indicate that you want the output sent to stdout rather than stderr? ... after a few responses ... Guido van Rossum guido at python.org Thu Jan 24 21:09:12 CET 2008 On Jan 24, 2008 11:41 AM, Mike Kent wrote: ... > Interesting point about whether GNU readline is installed. My setup is RedHat > Linux, with Python 2.5 that I built and installed myself. GNU readline is not, > in fact, installed. If you look at Python2.5/Parser/myreadline.c, function > PyOS_StdioReadline, line 125, you will see that prompt output is being sent to > stderr. As best as my Python-fu can determine, this is the code used to output > a raw_input prompt (thanks again to Gabriel Genellina for pointing me in the > right direction.) > > It's entirely likely that the difference in what I am seeing and what you guys > are seeing is caused by my not having GNU readline installed. Nevertheless, > the behavior without it seems wrong, and is certainly different from the > documentation. Agreed. ---------- components: Interpreter Core messages: 61652 nosy: skip.montanaro severity: normal status: open title: raw_input behavior incorrect if readline not enabled versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 21:21:28 2008 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 24 Jan 2008 20:21:28 -0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1201206088.89.0.816251517818.issue1927@psf.upfronthosting.co.za> Changes by Skip Montanaro: ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 21:33:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 24 Jan 2008 20:33:44 -0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1201206824.25.0.300067761304.issue1927@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 21:38:00 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 24 Jan 2008 20:38:00 -0000 Subject: [issue1923] meaningful whitespace can be lost in rfc822_escape In-Reply-To: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za> Message-ID: <1201207080.7.0.449544108531.issue1923@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you provide a patch with doc updates and an unit test? ---------- keywords: +easy nosy: +tiran priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 21:38:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 24 Jan 2008 20:38:57 -0000 Subject: [issue1926] NNTPS support in nntplib In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za> Message-ID: <1201207137.34.0.361557383903.issue1926@psf.upfronthosting.co.za> Christian Heimes added the comment: I assign it to janssens. He is our SSL expert. I also set the version to 2.6. New features get into the next major release. ---------- assignee: -> janssen keywords: +patch nosy: +janssen, tiran priority: -> normal versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 21:39:56 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 24 Jan 2008 20:39:56 -0000 Subject: [issue1921] Confusing Descrintro example In-Reply-To: <1201181747.66.0.31684496906.issue1921@psf.upfronthosting.co.za> Message-ID: <1201207196.05.0.584524519069.issue1921@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: -> low versions: -Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 24 23:32:02 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Thu, 24 Jan 2008 22:32:02 -0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1201213922.0.0.446883112906.issue1927@psf.upfronthosting.co.za> Gabriel Genellina added the comment: GNU readline is configured as to prompt the user using standard output, and read input from standard input; if this is the desired behavior it would be easy to provide a simple patch so input/raw_input behave that way even when readline is not used. ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 00:19:11 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 24 Jan 2008 23:19:11 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201216751.24.0.991733548858.issue1577@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch, which also contains additional unit tests for shutil.move(). It would be nice if people tested it under various configurations, to see if there are any problems. Added file: http://bugs.python.org/file9281/shutilmove.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 00:46:16 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Jan 2008 23:46:16 -0000 Subject: [issue1928] test_urllib fails In-Reply-To: <1201218376.09.0.323845254483.issue1928@psf.upfronthosting.co.za> Message-ID: <1201218376.09.0.323845254483.issue1928@psf.upfronthosting.co.za> New submission from Guido van Rossum: FAIL: test_read (__main__.urlopen_HttpTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_urllib.py", line 130, in test_read self.assertEqual(fp.getcode(), 200) AssertionError: None != 200 It works in the trunk though. Georg, didn't you touch this last, adding the code-getting API in the trunk? Perhaps it's a merge glitch? ---------- components: Library (Lib) messages: 61657 nosy: gvanrossum severity: normal status: open title: test_urllib fails type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 00:49:48 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 24 Jan 2008 23:49:48 -0000 Subject: [issue1910] Document that with is slower than try/finally In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za> Message-ID: <1201218588.85.0.0481624364475.issue1910@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Ok, I see your reasoning. I'm going to start going to through the rest of the library for places with should be used. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 01:03:28 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Fri, 25 Jan 2008 00:03:28 -0000 Subject: [issue1929] httplib _read_chunked TypeError ||| i = line.find(";") In-Reply-To: <1201219408.32.0.189148181518.issue1929@psf.upfronthosting.co.za> Message-ID: <1201219408.32.0.189148181518.issue1929@psf.upfronthosting.co.za> New submission from Georgij Kondratjev: (With current python3-svn) While trying to response.read() got this: --- File "/usr/lib/python3.0/httplib.py", line 533, in read return self._read_chunked(amt) File "/usr/lib/python3.0/httplib.py", line 573, in _read_chunked i = line.find(";") TypeError: expected an object with the buffer interface --- To debug I did this: --- line = self.fp.readline() +print(' ***', line) i = line.find(b";") --- and got "*** b'2e6d\r\n'" followed by those TypeError exception. I did this: --- def _read_chunked(self, amt): assert self.chunked != _UNKNOWN chunk_left = self.chunk_left - value = "" + value = b"" if chunk_left is None: line = self.fp.readline() - i = line.find(";") + i = line.find(b";") --- And it seems to work. ---------- components: Library (Lib) messages: 61659 nosy: orivej severity: normal status: open title: httplib _read_chunked TypeError ||| i = line.find(";") versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 01:05:42 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Fri, 25 Jan 2008 00:05:42 -0000 Subject: [issue1929] httplib _read_chunked TypeError ||| i = line.find(";") In-Reply-To: <1201219408.32.0.189148181518.issue1929@psf.upfronthosting.co.za> Message-ID: <1201219542.82.0.169690948866.issue1929@psf.upfronthosting.co.za> Georgij Kondratjev added the comment: Sorry, while debugging there was no 'b': --- line = self.fp.readline() +print(' ***', line) i = line.find(";") --- __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 01:10:08 2008 From: report at bugs.python.org (Robert Clark) Date: Fri, 25 Jan 2008 00:10:08 -0000 Subject: [issue1930] sys.maxint not found in Python 3.0a2 In-Reply-To: <1201219807.95.0.419145218607.issue1930@psf.upfronthosting.co.za> Message-ID: <1201219807.95.0.419145218607.issue1930@psf.upfronthosting.co.za> New submission from Robert Clark: File "/home/rclark/lib/src/python/pyparsing/pyparsing-1.3.1/pyparsing.py", line 971, in __init__ self.maxLen = sys.maxint AttributeError: 'module' object has no attribute 'maxint' ---------- messages: 61661 nosy: rclark severity: normal status: open title: sys.maxint not found in Python 3.0a2 type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 01:11:40 2008 From: report at bugs.python.org (Robert Clark) Date: Fri, 25 Jan 2008 00:11:40 -0000 Subject: [issue1931] NameError: global name 'basestring' is not defined In-Reply-To: <1201219900.17.0.974915003457.issue1931@psf.upfronthosting.co.za> Message-ID: <1201219900.17.0.974915003457.issue1931@psf.upfronthosting.co.za> New submission from Robert Clark: File "/home/rclark/lib/src/python/pyparsing/pyparsing-1.3.1/pyparsing.py", line 1511, in __init__ if isinstance( expr, basestring ): NameError: global name 'basestring' is not defined ---------- messages: 61662 nosy: rclark severity: normal status: open title: NameError: global name 'basestring' is not defined type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 01:15:11 2008 From: report at bugs.python.org (Robert Clark) Date: Fri, 25 Jan 2008 00:15:11 -0000 Subject: [issue1930] sys.maxint not found in Python 3.0a2 In-Reply-To: <1201219807.95.0.419145218607.issue1930@psf.upfronthosting.co.za> Message-ID: <1201220111.78.0.488580441674.issue1930@psf.upfronthosting.co.za> Robert Clark added the comment: sys.maxint was changed to sys.maxsize, but this was not noted in the documentation. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 01:19:09 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Fri, 25 Jan 2008 00:19:09 -0000 Subject: [issue1930] sys.maxint not found in Python 3.0a2 In-Reply-To: <1201219807.95.0.419145218607.issue1930@psf.upfronthosting.co.za> Message-ID: <1201220349.15.0.320928124158.issue1930@psf.upfronthosting.co.za> Georgij Kondratjev added the comment: Maybe it was not noted, but it is documented: http://docs.python.org/dev/3.0/library/sys.html ---------- nosy: +orivej __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 01:37:24 2008 From: report at bugs.python.org (Robert Clark) Date: Fri, 25 Jan 2008 00:37:24 -0000 Subject: [issue1931] NameError: global name 'basestring' is not defined In-Reply-To: <1201219900.17.0.974915003457.issue1931@psf.upfronthosting.co.za> Message-ID: <1201221444.1.0.0478909028816.issue1931@psf.upfronthosting.co.za> Robert Clark added the comment: basestring is in the builtins library for 2.5.1, but is not there in 3.0a2 Linux: RHEL40 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 02:34:44 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 25 Jan 2008 01:34:44 -0000 Subject: [issue1930] sys.maxint not found in Python 3.0a2 In-Reply-To: <1201219807.95.0.419145218607.issue1930@psf.upfronthosting.co.za> Message-ID: <1201224884.2.0.559810484898.issue1930@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- components: +Documentation __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 02:35:32 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 25 Jan 2008 01:35:32 -0000 Subject: [issue1931] NameError: global name 'basestring' is not defined In-Reply-To: <1201219900.17.0.974915003457.issue1931@psf.upfronthosting.co.za> Message-ID: <1201224932.52.0.792020074904.issue1931@psf.upfronthosting.co.za> Guido van Rossum added the comment: It's been deleted. Use 2to3; it will replace it with 'str'. ---------- components: +Documentation nosy: +gvanrossum type: compile error -> __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 03:27:54 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 25 Jan 2008 02:27:54 -0000 Subject: [issue1920] while else loop seems to behave incorrectly In-Reply-To: <1201180969.36.0.961933968615.issue1920@psf.upfronthosting.co.za> Message-ID: <1201228074.09.0.762317906747.issue1920@psf.upfronthosting.co.za> Mark Dickinson added the comment: Looks like Amaury found his svn access. Is it okay to close this now? ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 03:52:03 2008 From: report at bugs.python.org (Bill Janssen) Date: Fri, 25 Jan 2008 02:52:03 -0000 Subject: [issue1926] NNTPS support in nntplib In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za> Message-ID: <1201229523.6.0.596846794434.issue1926@psf.upfronthosting.co.za> Bill Janssen added the comment: Unfortunately, it uses the deprecated socket.ssl calls. Re-worked to use the new SSL module, it would be OK. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 04:15:14 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 25 Jan 2008 03:15:14 -0000 Subject: [issue1932] Cosmetic patch to supress compiler warning In-Reply-To: <1201230914.81.0.163994833625.issue1932@psf.upfronthosting.co.za> Message-ID: <1201230914.81.0.163994833625.issue1932@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto: This is not compile error, but I cannot find more proper tag than this. ---------- components: Build files: const.patch messages: 61669 nosy: ocean-city severity: minor status: open title: Cosmetic patch to supress compiler warning type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file9282/const.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 04:59:34 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 25 Jan 2008 03:59:34 -0000 Subject: [issue1920] while else loop seems to behave incorrectly In-Reply-To: <1201180969.36.0.961933968615.issue1920@psf.upfronthosting.co.za> Message-ID: <1201233574.2.0.386405846162.issue1920@psf.upfronthosting.co.za> Mark Dickinson added the comment: Forgot to say: Amaury checked his fix in in revision #60265 (trunk) and revision #60268 (Python 2.5). Thanks for the bug report, Mark! __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 06:45:16 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 25 Jan 2008 05:45:16 -0000 Subject: [issue1930] sys.maxint not found in Python 3.0a2 In-Reply-To: <1201219807.95.0.419145218607.issue1930@psf.upfronthosting.co.za> Message-ID: <1201239916.71.0.907170535634.issue1930@psf.upfronthosting.co.za> Martin v. L?wis added the comment: sys.maxint was *not* changed to sys.maxsize - it was simply removed. pyparsing apparently hasn't been ported to Python 3; please bring this up with the pyparsing authors (but then, Python 3 hasn't been released, so they might decide not to take any action for several years, until, say, Python 3.2). sys.maxint used to indicate the maximum value that an int could have. In Python 3, the int type has no maximum value anymore. The only place where this might need some notice is the whatsnew text. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 06:47:15 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 25 Jan 2008 05:47:15 -0000 Subject: [issue1931] NameError: global name 'basestring' is not defined In-Reply-To: <1201219900.17.0.974915003457.issue1931@psf.upfronthosting.co.za> Message-ID: <1201240035.57.0.843473801928.issue1931@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Robert, can you please explain why you consider this as a bug? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 06:49:09 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 25 Jan 2008 05:49:09 -0000 Subject: [issue1932] Cosmetic patch to supress compiler warning In-Reply-To: <1201230914.81.0.163994833625.issue1932@psf.upfronthosting.co.za> Message-ID: <1201240149.97.0.680886438863.issue1932@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please explain what compiler you are using and what warning it produces? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 07:19:24 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 25 Jan 2008 06:19:24 -0000 Subject: [issue1932] Cosmetic patch to supress compiler warning In-Reply-To: <1201230914.81.0.163994833625.issue1932@psf.upfronthosting.co.za> Message-ID: <1201241964.33.0.0746839490626.issue1932@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: VisualC++6 (this is only VC compiler I have) Compiler Warning (level 1) C4090 '=' : different 'const' qualifiers http://msdn2.microsoft.com/en-us/library/k77bkb8d(VS.71).aspx __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 08:15:59 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 25 Jan 2008 07:15:59 -0000 Subject: [issue1928] test_urllib fails In-Reply-To: <1201218376.09.0.323845254483.issue1928@psf.upfronthosting.co.za> Message-ID: <1201245358.96.0.878481669017.issue1928@psf.upfronthosting.co.za> Georg Brandl added the comment: I'll fix that this weekend. ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 09:19:22 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 25 Jan 2008 08:19:22 -0000 Subject: [issue1722225] Build on QNX 6 Message-ID: <1201249162.23.0.255088428544.issue1722225@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't understand the ncurses issue: you already disable the definition of _XOPEN_SOURCE in the patch, hence _XOPEN_SOURCE_EXTENDED does not get defined, hence ncurses should not define wchar_t. So what's the actual problem that this fragment solves? As for stdlib.h: *Is* __WCHAR_T defined on your system, normally? Re stack size: maybe I misunderstood what the patch does. Is it the case that, with the patch, the interpreter won't crash, but gives a RuntimeError instead? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 25 09:35:30 2008 From: report at bugs.python.org (Vladimir Konjkov) Date: Fri, 25 Jan 2008 08:35:30 -0000 Subject: [issue1722225] Build on QNX 6 Message-ID: <1201250130.44.0.454258350282.issue1722225@psf.upfronthosting.co.za> Vladimir Konjkov added the comment: For _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED look this http://opengroup.org/onlinepubs/007908775/xcurses/implement.html _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 25 10:14:34 2008 From: report at bugs.python.org (Vladimir Konjkov) Date: Fri, 25 Jan 2008 09:14:34 -0000 Subject: [issue1722225] Build on QNX 6 Message-ID: <1201252474.93.0.500088287485.issue1722225@psf.upfronthosting.co.za> Vladimir Konjkov added the comment: there is script Misk/find_recursionlimit.py that can help to find real recursion limit for QNX4 for one recursion used ~900 kb of stack thus 1Mb sufficient for default recursion limit = 1000. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 25 12:03:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 25 Jan 2008 11:03:05 -0000 Subject: [issue1931] NameError: global name 'basestring' is not defined In-Reply-To: <1201219900.17.0.974915003457.issue1931@psf.upfronthosting.co.za> Message-ID: <1201258985.38.0.939912674008.issue1931@psf.upfronthosting.co.za> Christian Heimes added the comment: I've updated the whatsnew docs in r60279. ---------- nosy: +tiran priority: -> low resolution: -> invalid status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 12:12:09 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 25 Jan 2008 11:12:09 -0000 Subject: [issue1930] sys.maxint not found in Python 3.0a2 In-Reply-To: <1201219807.95.0.419145218607.issue1930@psf.upfronthosting.co.za> Message-ID: <1201259529.06.0.756011366398.issue1930@psf.upfronthosting.co.za> Christian Heimes added the comment: I've added a comment next to long -> int in r60280. Please note that Python 2.x doesn't run under 3.0. You have to port the code to 2.6 first, make arrangements and at last use the 2to3 tool. ---------- nosy: +tiran resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 12:12:37 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 25 Jan 2008 11:12:37 -0000 Subject: [issue1929] httplib _read_chunked TypeError ||| i = line.find(";") In-Reply-To: <1201219408.32.0.189148181518.issue1929@psf.upfronthosting.co.za> Message-ID: <1201259557.88.0.77375827339.issue1929@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: -> normal type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 12:13:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 25 Jan 2008 11:13:04 -0000 Subject: [issue1932] Cosmetic patch to supress compiler warning In-Reply-To: <1201230914.81.0.163994833625.issue1932@psf.upfronthosting.co.za> Message-ID: <1201259584.53.0.584234541174.issue1932@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 12:56:21 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 25 Jan 2008 11:56:21 -0000 Subject: [issue1720] VC6 build patch for release-maint25 In-Reply-To: <1199285194.09.0.0105963062735.issue1720@psf.upfronthosting.co.za> Message-ID: <1201262181.52.0.696073940715.issue1720@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Fix to build _bsddb module in Release mode. Added file: http://bugs.python.org/file9283/patch-for-release-maint25.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 14:24:18 2008 From: report at bugs.python.org (Tom Lynn) Date: Fri, 25 Jan 2008 13:24:18 -0000 Subject: [issue1631394] sre module has misleading docs Message-ID: <1201267458.4.0.750323160034.issue1631394@psf.upfronthosting.co.za> Tom Lynn added the comment: Thanks for fixing this. I now also note that (?<=...), (? _____________________________________ From report at bugs.python.org Fri Jan 25 15:45:42 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 25 Jan 2008 14:45:42 -0000 Subject: [issue784443] test_repr failure on m68k-linux Message-ID: <1201272342.12.0.371664431119.issue784443@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Please reopen if the problem can be reproduced in 2.5 or later. ---------- resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 25 15:53:58 2008 From: report at bugs.python.org (Ray Chason) Date: Fri, 25 Jan 2008 14:53:58 -0000 Subject: [issue1926] NNTPS support in nntplib In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za> Message-ID: <1201272838.18.0.971534937451.issue1926@psf.upfronthosting.co.za> Ray Chason added the comment: OK, I got a copy of the Subversion sources and the new SSL library looks like just what is needed here. Examining the other protocol modules that already support SSL, I find these things: httplib has: HTTPConnection(host[, port[, strict[, timeout]]]) HTTPSConnection(host[, port[, key_file[, cert_file[, strict[, timeout]]]]]) poplib has: POP3(host[, port[, timeout]]) POP3_SSL(host[, port[, keyfile[, certfile]]]) imaplib has: IMAP4([host[, port]]) IMAP4_SSL([host[, port[, keyfile[, certfile]]]]) smtplib has: SMTP([host[, port[, local_hostname[, timeout]]]]) SMTP_SSL([host[, port[, local_hostname[, keyfile[, certfile[, timeout]]]]]]) Now nntplib as it stands has no SSL-using variant. The existing factory method is: NNTP(host[, port[, user[, password[, readermode[, usenetrc]]]]]) What seems most consistent with the other modules is to define: NNTP_SSL(host[, port[, keyfile[, certfile[, user[, password[, readermode[, usenetrc]]]]]]]) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 18:07:06 2008 From: report at bugs.python.org (Bill Janssen) Date: Fri, 25 Jan 2008 17:07:06 -0000 Subject: [issue1926] NNTPS support in nntplib In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za> Message-ID: <1201280826.0.0.142584939506.issue1926@psf.upfronthosting.co.za> Bill Janssen added the comment: Sounds good. If you want to develop this with 2.5.1, you can get an API-compliant version of the SSL module for 2.5.1 from http://pypi.python.org/pypi/ssl/. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 18:58:34 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 25 Jan 2008 17:58:34 -0000 Subject: [issue1792] o(n*n) marshal.dumps performance for largish objects with patch In-Reply-To: <1200061286.09.0.117532205028.issue1792@psf.upfronthosting.co.za> Message-ID: <1201283914.39.0.169511558142.issue1792@psf.upfronthosting.co.za> Facundo Batista added the comment: Christian: you can not do that, as you *must* increase the size. Anyway, I think that is a good idea to not let it duplicate after some point. Which point? It's arbitrary. You suggested 512KB, but I think that is too low. *My* arbitrary point is, when the newsize if greater than 32MB, only increaase at 1MB steps. I attach the patch. Added file: http://bugs.python.org/file9285/marshal_limited.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 20:53:31 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 25 Jan 2008 19:53:31 -0000 Subject: [issue1607759] segfault in python24.dll Message-ID: <1201290811.01.0.849200653389.issue1607759@psf.upfronthosting.co.za> Guido van Rossum added the comment: Without new information we can't really help with this, sorry. ---------- nosy: +gvanrossum resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 25 21:20:15 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 25 Jan 2008 20:20:15 -0000 Subject: [issue784231] getopt_long_only() Message-ID: <1201292415.61.0.775365778716.issue784231@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I see no chance of this being accepted now that optparse is entrenched. Please do reopen if some one thinks otherwise. ---------- nosy: +draghuram resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 25 21:49:15 2008 From: report at bugs.python.org (Ray Chason) Date: Fri, 25 Jan 2008 20:49:15 -0000 Subject: [issue1926] NNTPS support in nntplib In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za> Message-ID: <1201294155.49.0.646967029662.issue1926@psf.upfronthosting.co.za> Ray Chason added the comment: Here's take 2. The pre-patch NNTP class has a long and complicated constructor. Rather than duplicate this constructor in NNTP_SSL, the patch converts most of the NNTP class to a new class, NNTPBase, which takes an already-connected socket as a parameter. NNTP and NNTP_SSL both inherit NNTPBase and create that socket in their own respective ways. Added file: http://bugs.python.org/file9286/python-nntps-patch-2.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 22:13:24 2008 From: report at bugs.python.org (Matt Kraai) Date: Fri, 25 Jan 2008 21:13:24 -0000 Subject: [issue1722225] Build on QNX 6 Message-ID: <1201295604.5.0.829155979322.issue1722225@psf.upfronthosting.co.za> Matt Kraai added the comment: Regarding the curses issue, I removed that portion of the patch and the curses module still compiled. It must have been an artifact from before I disabled _XOPEN_SOURCE. Thanks for catching that. Regarding the stack size, without the "-N 2048K" option, "make test" fails as follows: ... test_compare test_compile make: *** [test] segmentation violation (core dumped) The default recursion limit returned by sys.getrecursionlimit() is 1000, and Misc/find_recursionlimit.py says that 1100 is fine. With -N 2048K, test_compile does not produce a segmentation fault and Misc/find_recursionlimit.py says that 4700 is fine. Added file: http://bugs.python.org/file9287/patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Jan 25 22:54:12 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 25 Jan 2008 21:54:12 -0000 Subject: [issue1933] os.path.isabs documentation error In-Reply-To: <1201298051.95.0.975455145636.issue1933@psf.upfronthosting.co.za> Message-ID: <1201298051.95.0.975455145636.issue1933@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': The current os.path.isabs documentation says: > isabs(path) > Return True if path is an absolute pathname (begins with a slash). The "begins with a slash" part is incorrect since certain systems use a different pathname notation. For example, on Macintosh (where os.sep == ":") this is an absolute pathname: hardDriveName:folderName1:folderName2:fileName.ext ...and this is a relative one: :folderName1:fileName.ext Moreover, on Windows os.path.isabs('\\') returns True since '\\' is an alias for the current drive letter (e.g. C:\\) hence, independently from what said before, the documentation should include also the "backslash" term. I think it would be better removing the "(begins with a slash)" part at all. ---------- components: Documentation messages: 61691 nosy: giampaolo.rodola severity: normal status: open title: os.path.isabs documentation error versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 22:55:53 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 25 Jan 2008 21:55:53 -0000 Subject: [issue1934] os.path.isabs documentation error In-Reply-To: <1201298153.58.0.265967010684.issue1934@psf.upfronthosting.co.za> Message-ID: <1201298153.58.0.265967010684.issue1934@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': The current os.path.isabs documentation says: > isabs(path) > Return True if path is an absolute pathname (begins with a slash). The "begins with a slash" part is incorrect since certain systems use a different pathname notation. For example, on Macintosh (where os.sep == ":") this is an absolute pathname: hardDriveName:folderName1:folderName2:fileName.ext ...and this is a relative one: :folderName1:fileName.ext Moreover, on Windows os.path.isabs('\\') returns True since '\\' is an alias for the current drive letter (e.g. C:\\) hence, independently from what said before, the documentation should include also the "backslash" term. I think it would be better removing the "(begins with a slash)" part at all. ---------- components: Documentation messages: 61692 nosy: giampaolo.rodola severity: normal status: open title: os.path.isabs documentation error versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 22:59:05 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 25 Jan 2008 21:59:05 -0000 Subject: [issue874900] threading module can deadlock after fork Message-ID: <1201298344.97.0.640772879696.issue874900@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's not only the _active_limbo_lock. All global structures of the threading module should be reinitialized (including the _MainThread instance); for that purpose, reload() can be used. I attach an example which exercises this problem. Normally the script should hang in the last step (using os.fork() and launching threads while some other threads call threading.enumerate() in a loop). The safe_fork() function in the example is a replacement for os.fork() which tries to avoid any deadlock in the threading module. If it's deemed useful and bug-free, it could perhaps be added somewhere in the stdlib (in the threading module itself perhaps). ---------- nosy: +pitrou Added file: http://bugs.python.org/file9288/fork_threading.py ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Jan 25 23:00:37 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 25 Jan 2008 22:00:37 -0000 Subject: [issue1933] os.path.isabs documentation error In-Reply-To: <1201298051.95.0.975455145636.issue1933@psf.upfronthosting.co.za> Message-ID: <1201298437.59.0.909498886044.issue1933@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Sorry but I had problem with my browser and I submitted the report twice: http://bugs.python.org/issue1934 Could someone please close this one? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 23:08:46 2008 From: report at bugs.python.org (Neal Norwitz) Date: Fri, 25 Jan 2008 22:08:46 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201298926.53.0.290977236776.issue1621@psf.upfronthosting.co.za> Changes by Neal Norwitz: ---------- nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Jan 25 23:59:50 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 25 Jan 2008 22:59:50 -0000 Subject: [issue874900] threading module can deadlock after fork Message-ID: <1201301990.14.0.496361643923.issue874900@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (or perhaps we should provide an API to hook into PyOS_AfterFork) ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Jan 26 00:28:16 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 25 Jan 2008 23:28:16 -0000 Subject: [issue1935] test_descr.py converted to unittest In-Reply-To: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za> Message-ID: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This is test_descr.py converted to unittest. The diff is so large that svn diff failed! "svn: Can't write to stream: Not enough space to process this command." Anyway, I started from trunk, rev 60301. The file is very large, and some functions have more than 400 lines. I tried to group them into classes, most of the time respecting the initial sequential order, but not always. The class and function names may seem arbitrary sometimes. At least, I hope that no test was lost in the process. Feel free to reorganize stuff if you find a logic in all these tests. I removed all print statements, and converted some statements to unittest idioms, but not all: lots of "raise TestFailed" remain. svn merge into py3k will be difficult; I propose to upload a py3k version of this file, which I will make by merging differences between trunk and py3k into this new file. ---------- components: Tests files: test_descr.py keywords: patch messages: 61696 nosy: amaury.forgeotdarc severity: normal status: open title: test_descr.py converted to unittest versions: Python 2.6 Added file: http://bugs.python.org/file9289/test_descr.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 00:30:32 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 25 Jan 2008 23:30:32 -0000 Subject: [issue1935] test_descr.py converted to unittest In-Reply-To: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za> Message-ID: <1201303832.0.0.210620627128.issue1935@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc: Removed file: http://bugs.python.org/file9289/test_descr.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 00:31:16 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 25 Jan 2008 23:31:16 -0000 Subject: [issue1935] test_descr.py converted to unittest In-Reply-To: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za> Message-ID: <1201303876.71.0.852323233337.issue1935@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc: Added file: http://bugs.python.org/file9290/test_descr.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 01:50:08 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 26 Jan 2008 00:50:08 -0000 Subject: [issue1935] test_descr.py converted to unittest In-Reply-To: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za> Message-ID: <1201308608.55.0.0859694946572.issue1935@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: And here is the version for py3k! I also removed a few duplicate tests or list items, introduced by unicode->str and long->int conversions. Added file: http://bugs.python.org/file9291/test_descr.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 02:48:48 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 26 Jan 2008 01:48:48 -0000 Subject: [issue1933] os.path.isabs documentation error In-Reply-To: <1201298051.95.0.975455145636.issue1933@psf.upfronthosting.co.za> Message-ID: <1201312128.99.0.164382195945.issue1933@psf.upfronthosting.co.za> Changes by Mark Dickinson: ---------- resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 03:18:58 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 26 Jan 2008 02:18:58 -0000 Subject: [issue1938] test_zipfile failure In-Reply-To: <1201313938.37.0.0332747788012.issue1938@psf.upfronthosting.co.za> Message-ID: <1201313938.37.0.0332747788012.issue1938@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': Python 2.6.13903.msi, windows XP sp2: ====================================================================== ERROR: testExtract (__main__.TestsWithSourceFile) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\Lib\test\test_zipfile.py", line 357, in tearDown os.remove(TESTFN2) WindowsError: [Error 32] The file used by another process: '@test2' ====================================================================== FAIL: testExtract (__main__.TestsWithSourceFile) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\Lib\test\test_zipfile.py", line 320, in testExtract self.assertEqual(writtenfile, correctfile) AssertionError: 'C:\\Python26\\Lib\\test\\ziptest2dir\\_ziptest2' != 'C:\\Python 26\\Lib\\test\\ziptest2dir/_ziptest2' ---------------------------------------------------------------------- ---------- files: test_zipfile.diff messages: 61698 nosy: giampaolo.rodola severity: normal status: open title: test_zipfile failure versions: Python 2.6 Added file: http://bugs.python.org/file9292/test_zipfile.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 07:12:22 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Jan 2008 06:12:22 -0000 Subject: [issue1939] code object docstring obsolete In-Reply-To: <1201327942.59.0.0823871003306.issue1939@psf.upfronthosting.co.za> Message-ID: <1201327942.59.0.0823871003306.issue1939@psf.upfronthosting.co.za> New submission from Antoine Pitrou: The docstring for the code object mentions an obsolete signature which misses the `kwonlyargcount` parameter. Here is a patch. ---------- components: Interpreter Core files: codedoc.patch messages: 61699 nosy: pitrou severity: minor status: open title: code object docstring obsolete versions: Python 3.0 Added file: http://bugs.python.org/file9293/codedoc.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 10:39:32 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 26 Jan 2008 09:39:32 -0000 Subject: [issue1939] code object docstring obsolete In-Reply-To: <1201327942.59.0.0823871003306.issue1939@psf.upfronthosting.co.za> Message-ID: <1201340372.04.0.22823250492.issue1939@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed r60313. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 10:43:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 26 Jan 2008 09:43:53 -0000 Subject: [issue1934] os.path.isabs documentation error In-Reply-To: <1201298153.58.0.265967010684.issue1934@psf.upfronthosting.co.za> Message-ID: <1201340633.86.0.888692283673.issue1934@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60314. Thanks for the report! ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 10:44:41 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 26 Jan 2008 09:44:41 -0000 Subject: [issue1931] NameError: global name 'basestring' is not defined In-Reply-To: <1201219900.17.0.974915003457.issue1931@psf.upfronthosting.co.za> Message-ID: <1201340681.24.0.839692519451.issue1931@psf.upfronthosting.co.za> Georg Brandl added the comment: I don't see why this shouldn't be closed. ---------- nosy: +georg.brandl status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 10:46:18 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 26 Jan 2008 09:46:18 -0000 Subject: [issue1929] httplib _read_chunked TypeError ||| i = line.find(";") In-Reply-To: <1201219408.32.0.189148181518.issue1929@psf.upfronthosting.co.za> Message-ID: <1201340778.44.0.44923307986.issue1929@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60315. Thanks! ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 11:23:06 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 26 Jan 2008 10:23:06 -0000 Subject: [issue1934] os.path.isabs documentation error In-Reply-To: <1201298153.58.0.265967010684.issue1934@psf.upfronthosting.co.za> Message-ID: <1201342986.39.0.617893833729.issue1934@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > Return ``True`` if *path* is an absolute pathname. On Unix, that > means it begins with a slash, on Windows that it begins with a > backslash after chopping off a potential drive letter. Actually the Windows part is not completely true since on Windows pathnames containing slashes ('/') are also permitted and treated as if they were backslashes ('\\'). >>> os.path.isabs('/') True >>> os.path.isabs('C:/') True >>> os.path.isabs('C:\\/') True __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 12:00:43 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 26 Jan 2008 11:00:43 -0000 Subject: [issue1631394] sre module has misleading docs Message-ID: <1201345243.29.0.455709035293.issue1631394@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, committed r60136. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 26 12:03:30 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 26 Jan 2008 11:03:30 -0000 Subject: [issue1934] os.path.isabs documentation error In-Reply-To: <1201298153.58.0.265967010684.issue1934@psf.upfronthosting.co.za> Message-ID: <1201345410.61.0.201433363733.issue1934@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, fixed in r60317. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 12:24:48 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 26 Jan 2008 11:24:48 -0000 Subject: [issue1928] test_urllib fails In-Reply-To: <1201218376.09.0.323845254483.issue1928@psf.upfronthosting.co.za> Message-ID: <1201346688.86.0.512788494949.issue1928@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r60318 -- one of the changes to urllib didn't survive the merge to py3k. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 13:57:35 2008 From: report at bugs.python.org (Giovanni Bajo) Date: Sat, 26 Jan 2008 12:57:35 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts In-Reply-To: <1193456436.1.0.972609600257.issue1342@psf.upfronthosting.co.za> Message-ID: <1201352255.15.0.450948847879.issue1342@psf.upfronthosting.co.za> Changes by Giovanni Bajo: ---------- nosy: +rasky __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 13:57:46 2008 From: report at bugs.python.org (Robin Bryce) Date: Sat, 26 Jan 2008 12:57:46 -0000 Subject: [issue1940] curses.filter can not be used as described in its documentation In-Reply-To: <1201352266.5.0.670433987116.issue1940@psf.upfronthosting.co.za> Message-ID: <1201352266.5.0.670433987116.issue1940@psf.upfronthosting.co.za> New submission from Robin Bryce: curses.filter forces the top most window to 1 line tall and preserves existing tty content. It must be called *before* curses.initscr in order to acheive this. The python documentation states that curses.filter must be called before initscr but the implementation prevents this. It uses the NoArgNoReturnVoidFunction macro defined in Include/py_curses.h. This macro in turn invokes the PyCursesInitialised macro which forces an error if initscr has not been called. curses.filter needs an explicit definition to avoid this: Replacing "NoArgNoReturnVoidFunction(filter)" in Modules/_cursesmodule.c with static PyObject *PyCurses_filter (PyObject *self) { /* MUST NOT BE PyCursesInitialised */ filter(); \ Py_INCREF(Py_None); return Py_None; } Would allow curses.filter to be called as documented. But really should get a check for "!PyCursesInitialised". ---------- components: Documentation, Library (Lib) messages: 61708 nosy: robinbryce severity: normal status: open title: curses.filter can not be used as described in its documentation type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 14:04:49 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Sat, 26 Jan 2008 13:04:49 -0000 Subject: [issue1872] change the bool struct format code from 't' to '?' In-Reply-To: <1200759352.1.0.256938962764.issue1872@psf.upfronthosting.co.za> Message-ID: <1201352689.07.0.175868468994.issue1872@psf.upfronthosting.co.za> Changes by Georgij Kondratjev: ---------- nosy: +orivej __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 15:05:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 26 Jan 2008 14:05:39 -0000 Subject: [issue1940] curses.filter can not be used as described in its documentation In-Reply-To: <1201352266.5.0.670433987116.issue1940@psf.upfronthosting.co.za> Message-ID: <1201356339.56.0.193575673908.issue1940@psf.upfronthosting.co.za> Georg Brandl added the comment: You're right. I fixed this in r60322, r60323 (2.5). ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 15:15:17 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 26 Jan 2008 14:15:17 -0000 Subject: [issue1473257] Add a gi_code attr to generators Message-ID: <1201356917.6.0.615972396773.issue1473257@psf.upfronthosting.co.za> Georg Brandl added the comment: Reformatted the patch to use tabs and committed as r60324. ---------- assignee: gvanrossum -> georg.brandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 26 17:44:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 26 Jan 2008 16:44:34 -0000 Subject: [issue1938] test_zipfile failure In-Reply-To: <1201313938.37.0.0332747788012.issue1938@psf.upfronthosting.co.za> Message-ID: <1201365873.96.0.498111120479.issue1938@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied in r60326 Thanks! Next time please explain the ratio for the fix in a sentence and don't commit a patch with absolute file names. ---------- nosy: +tiran priority: -> low resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 19:39:34 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 26 Jan 2008 18:39:34 -0000 Subject: [issue1938] test_zipfile failure In-Reply-To: <1201313938.37.0.0332747788012.issue1938@psf.upfronthosting.co.za> Message-ID: <1201372774.77.0.503971806204.issue1938@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: You're right, sorry. I'll do that. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 20:21:29 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 26 Jan 2008 19:21:29 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> New submission from Benjamin Peterson: This patch modernizes many modules in the stdlib by making them using the with statement. They affected modules are modulefinder, ftplib, cookielib, shutil, pydoc, platform, _LWPCookieJar, mailbox, _MozillaCookieJar, and zipfile. ---------- components: Library (Lib) files: stdlib-with-stmt.diff messages: 61713 nosy: gutworth severity: normal status: open title: 2.6 stdlib using with statement versions: Python 2.6 Added file: http://bugs.python.org/file9294/stdlib-with-stmt.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 21:05:29 2008 From: report at bugs.python.org (Thomas Heller) Date: Sat, 26 Jan 2008 20:05:29 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201377929.07.0.443783469015.issue1941@psf.upfronthosting.co.za> Thomas Heller added the comment: modulefinder should be kept compatible with Python 2.2, so please do not apply the patch for this module. See also PEP 291. No idea about the other modules. ---------- nosy: +theller __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 21:15:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 26 Jan 2008 20:15:15 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201378515.31.0.37488055831.issue1941@psf.upfronthosting.co.za> Christian Heimes added the comment: A while ago Raymond explained on Python developer list that the with statement is slightly slower than a try/finally block. Performance critical sections like the threading module must not use the with statement. ---------- assignee: -> rhettinger keywords: +patch nosy: +rhettinger, tiran priority: -> normal type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 21:26:28 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Sat, 26 Jan 2008 20:26:28 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201379188.4.0.133257462156.issue1941@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: The patch doesn't change the threading module, so I'm not sure if there's anything in particular you think is performance critical there. The places where it uses try/finally are: * _Condition.wait. This performs operations on a mutex which are much slower than any overhead "with" might bring. It also has sleep calls in it to implement timeout support, so it's not going to be extremely fast in those cases anyway. I notice, however, that it executes a number of lines of code outside before setting up the try/finally statement, allowing for the possibility of a buggy deadlock should an exception (such as KeyboardInterrupt) occur before the try block begins. * _Event.set, which uses _Condition and so also deals with mutexes. * _Event.clear and _Event.wait, similarly. * Thread.__bootstrap, which writes to stderr and uses mutexes, so is already quite slow. (but this case probably isn't a candidate for conversion to with anyway) * Thread.__delete and Thread.join, - more mutexes and conditions. So there doesn't seem to be anything particularly performance critical here. You can argue that the slightly increased overhead of with would still be bad, even for things that are already slow (such as mutex manipulation), I suppose. In this case, measuring the difference would be a useful step to take. However, there's also the issue of correctness. A KeyboardInterrupt can arrive between any of these mutxes being acquired and the try/finally being set up. It can also arrive after the finally begins executing and before the mutex is actually released. In either case, this will result in a lock being held when it shouldn't be, which will probably lead to a deadlock. Converting to with to manipulate these mutexes (assuming the lock type has its context management methods implemented in C) will remove the possibility of these bugs occurring. ---------- nosy: +exarkun __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 21:36:42 2008 From: report at bugs.python.org (Adam Olsen) Date: Sat, 26 Jan 2008 20:36:42 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201379802.66.0.837865335796.issue1941@psf.upfronthosting.co.za> Adam Olsen added the comment: Is there a guarantee that the with-statement is safe in the face of KeyboardInterrupt? PEP 343 seems to imply it's not, using it as a reason for why we need no special handling if __exit__ fails. ---------- nosy: +Rhamphoryncus __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 21:38:37 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Sat, 26 Jan 2008 20:38:37 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201379917.29.0.251470838736.issue1941@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: It's explicitly not (and Guido said this is what he wanted, several times). However, CPython will not raise a KeyboardInterrupt in the middle of a C function. Hence my parenthetical about implementing the lock type in C. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 21:39:48 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 26 Jan 2008 20:39:48 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201379988.4.0.32221958826.issue1941@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This new patch removes the modulefinder changes. I was the one you submitted #1910 which probably sparked the performance debate. In this patch, I tried to avoid these touchy places. Added file: http://bugs.python.org/file9295/stdlib-with-stmt2.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 21:42:30 2008 From: report at bugs.python.org (Tom Lynn) Date: Sat, 26 Jan 2008 20:42:30 -0000 Subject: [issue1631394] sre module has misleading docs Message-ID: <1201380150.98.0.782657781706.issue1631394@psf.upfronthosting.co.za> Tom Lynn added the comment: Nice changes to the wording. (For the record: it's r60316 in fact.) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Jan 26 21:49:56 2008 From: report at bugs.python.org (Adam Olsen) Date: Sat, 26 Jan 2008 20:49:56 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201380596.01.0.732948230068.issue1941@psf.upfronthosting.co.za> Adam Olsen added the comment: Yes, but there's no guarantee it will even reach the C function. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 21:51:42 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Sat, 26 Jan 2008 20:51:42 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201380702.1.0.114229407902.issue1941@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: There may not be a guarantee, but it will with the current implementation, and the discussion on this ticket seems to be very geared towards CPython implementation peculiarities. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 22:50:42 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 26 Jan 2008 21:50:42 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201384242.58.0.827708572306.issue1941@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please make darned sure these changes are semantically neutral. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 22:57:44 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 26 Jan 2008 21:57:44 -0000 Subject: [issue1942] test_plistlib started failing In-Reply-To: <1201384664.2.0.634554837169.issue1942@psf.upfronthosting.co.za> Message-ID: <1201384664.2.0.634554837169.issue1942@psf.upfronthosting.co.za> New submission from Guido van Rossum: Probably a merge glitch. ---------- components: Macintosh messages: 61724 nosy: gvanrossum priority: urgent severity: normal status: open title: test_plistlib started failing type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 23:05:21 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 26 Jan 2008 22:05:21 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201385121.69.0.488715521195.issue1941@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Sorry, but what does that mean? All tests are passing with the changes. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 23:14:58 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 26 Jan 2008 22:14:58 -0000 Subject: [issue1942] test_plistlib started failing In-Reply-To: <1201384664.2.0.634554837169.issue1942@psf.upfronthosting.co.za> Message-ID: <1201385698.91.0.464280905569.issue1942@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fixed by Crys in r60333. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 23:27:35 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 26 Jan 2008 22:27:35 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201385121.69.0.488715521195.issue1941@psf.upfronthosting.co.za> Message-ID: <479BB3D4.8000706@cheimes.de> Christian Heimes added the comment: Benjamin Peterson wrote: > Sorry, but what does that mean? All tests are passing with the changes. Tests aren't a proof for correctness. A failing test proofs either an error in the implementation or in the test suite. The reverse "all tests are passing => everything is fine" is not a valid assumption. Every change must be carefully studied. with open(name) as fp is fine in almost every case but other cases may not. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 23:44:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Jan 2008 22:44:35 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> New submission from Antoine Pitrou: This is an attempt at improving allocation of str (PyUnicode) objects. For that it does two things: 1. make str objects PyVarObjects, so that the object is allocated in one pass rather than two 2. maintain an array of freelists, each for a given str length, so that many str allocations can bypass actual memory allocation calls There is a ~10% speedup in stringbench, and a slight improvement in pybench (as invoked with "./python Tools/pybench/pybench.py -t String"). Also, memory consumption is a bit lower when running those benchmarks. ---------- components: Interpreter Core files: unialloc.patch messages: 61728 nosy: pitrou severity: normal status: open title: improved allocation of PyUnicode objects type: rfe versions: Python 3.0 Added file: http://bugs.python.org/file9296/unialloc.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Jan 26 23:45:09 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Jan 2008 22:45:09 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201387509.09.0.27626583809.issue1943@psf.upfronthosting.co.za> Changes by Antoine Pitrou: Added file: http://bugs.python.org/file9297/stringbench3k.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 00:02:02 2008 From: report at bugs.python.org (Brett Cannon) Date: Sat, 26 Jan 2008 23:02:02 -0000 Subject: [issue1935] test_descr.py converted to unittest In-Reply-To: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za> Message-ID: <1201388522.07.0.431200399698.issue1935@psf.upfronthosting.co.za> Brett Cannon added the comment: Just so you know, Amaury, a student did a conversion for GHOP: http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=291 . It was not checked in yet as we are waiting for contributor forms first. But perhaps you can have a look at it and see if there is anything to take? I suspect yours is fine (or possibly better since you just have more experience than a high schooler; no offense, Jeff), but it wouldn't hurt to have a look and just choose one or the other. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 00:09:24 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Sat, 26 Jan 2008 23:09:24 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201388964.22.0.938789531957.issue1943@psf.upfronthosting.co.za> Changes by Georgij Kondratjev: ---------- nosy: +orivej __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 00:27:35 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 26 Jan 2008 23:27:35 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201390055.27.0.353725007691.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The Unicode object was designed not to be a PyVarObject (in contrast to the string object), so I'm not sure what you would want to break that design in return for a mere 10% speedup. Note that turning the objects into PyVarObjects removes the ability to extend the type at C level. It also introduces lots of problems if you want to resize a Unicode object, due to the fact that the memory address of the whole PyUnicodeObject can change. Resizing is done quite often in codecs. Regarding your second point: Unicode objects already use a free list and even keep the allocated Py_UNICODE buffer allocated (if it's not too large). Furthermore, the allocation is handled by pymalloc, so you only rarely need to go to the system malloc() to allocate more space. Tuning the KEEPALIVE_SIZE_LIMIT will likely have similar effects w/r to speedup. ---------- nosy: +lemburg __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 00:27:39 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 26 Jan 2008 23:27:39 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201390059.38.0.244030546276.issue1941@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It means to that the test suites are likely inadequate in this department and that you need to carefully check each transformation to make sure it doesn't do something subtlely different. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 01:24:02 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Jan 2008 00:24:02 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201393442.0.0.233654345185.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I just tried bumping KEEPALIVE_SIZE_LIMIT to 200. It makes up for a bit of the speedup, but the PyVarObject version is still faster. Moreover, and perhaps more importantly, it eats less memory (800KB less in pybench, 3MB less when running the whole test suite). (then there are of course microbenchmarks. For example: # With KEEPALIVE_SIZE_LIMIT = 200 ./python -m timeit -s "s=open('LICENSE', 'r').read()" "s.split()" 1000 loops, best of 3: 556 usec per loop # With this patch ./python -m timeit -s "s=open('LICENSE', 'r').read()" "s.split()" 1000 loops, best of 3: 391 usec per loop ) I don't understand the argument for codecs having to resize the unicode object. Since codecs also have to resize the bytes object when encoding, the argument should apply to bytes objects as well, yet bytes (and str in 2.6) is a PyVarObject. I admit I don't know the exact reasons for PyUnicode's design. I just know that the patch doesn't break the API, and runs the test suite fine. Are there any specific things to look for? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 03:11:16 2008 From: report at bugs.python.org (Bill Janssen) Date: Sun, 27 Jan 2008 02:11:16 -0000 Subject: [issue1926] NNTPS support in nntplib In-Reply-To: <1201294155.49.0.646967029662.issue1926@psf.upfronthosting.co.za> Message-ID: <4b3e516a0801261811h5df1934ch725c301c63a4a564@mail.gmail.com> Bill Janssen added the comment: Great, Ray. I don't see any test cases for the nntp library in the Lib/test/ directory. How can we make sure it works on the buildbots? Bill On Jan 25, 2008 12:49 PM, Ray Chason wrote: > > Ray Chason added the comment: > > Here's take 2. > > The pre-patch NNTP class has a long and complicated constructor. Rather > than duplicate this constructor in NNTP_SSL, the patch converts most of > the NNTP class to a new class, NNTPBase, which takes an > already-connected socket as a parameter. NNTP and NNTP_SSL both inherit > NNTPBase and create that socket in their own respective ways. > > Added file: http://bugs.python.org/file9286/python-nntps-patch-2.txt > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9298/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080127/0dba2c04/attachment-0001.txt From report at bugs.python.org Sun Jan 27 07:26:44 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 27 Jan 2008 06:26:44 -0000 Subject: [issue1944] Documentation for PyUnicode_AsString (et al.) missing. In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za> Message-ID: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: I was wandering whether the pointer returned by PyUnicode_AsString needs to be freed after usage (It turned it doesn't since the result is cached). However, I found out that there isn't any documentation on docs.python.org about the PyUnicode_AsString and PyUnicode_AsStringAndSize functions. Although, both are documented in the public unicodeobject.h header. I notice that the documentation for several other unicode functions is missing. Quickly, I see: PyUnicode_Resize PyUnicode_InternImmortal PyUnicode_GetDefaultEncoding PyUnicode_SetDefaultEncoding PyUnicode_BuildEncodingMap PyUnicode_FromFormatV PyUnicode_*UTF7* PyUnicode_AsEncodedObject PyUnicode_FromOrdinal PyUnicode_DecodeFSDefault PyUnicode_DecodeFSDefaultAndSize It would probably be a good idea to polish up the documentation for PyUnicode as much as possible for Python 3000, since extension developers will certainly need to refer to it a lot during the transition from 2.x. ---------- components: Documentation keywords: easy messages: 61734 nosy: alexandre.vassalotti severity: normal status: open title: Documentation for PyUnicode_AsString (et al.) missing. versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 14:52:05 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 27 Jan 2008 13:52:05 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201441925.84.0.708568372808.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Your microbenchmark is biased towards your patched version. The KEEPALIVE_SIZE_LIMIT will only cut in when you deallocate and then reallocate Unicode objects. The free list used for Unicode objects is also limited to 1024 objects - which isn't all that much. You could tune MAX_UNICODE_FREELIST_SIZE as well. Regarding memory usage: this is difficult to measure in Python, since pymalloc will keep memory chunks allocated even if they are not in use by Python. However, this is a feature of pymalloc and not specific to the Unicode implementation. It can be tuned in pymalloc. To get more realistic memory measurements, you'd have to switch off pymalloc altogether and then create a separate process that consumes lots of memory to force the OS to have it allocate only memory that's really needed to the process you're running for memory measurements. Of course, keeping objects alive in a free list will always use more memory than freeing them altogether and returning the memory to the OS. It's a speed/space tradeoff. The RAM/CPU costs ratio has shifted a lot towards RAM nowadays, so using more RAM is usually more efficient than using more CPU time. Regarding resize: you're right - the string object is a PyVarObject as well and couldn't be changed at the time due to backwards compatibility reasons. You should also note that when I added Unicode to Python 1.6, it was a new and not commonly used type. Codecs were not used much either, so there was no incentive to make resizing strings work better. Later on, other optimizations were added to the Unicode implementation that caused the PyUnicode_Resize() API to also require being able to change the object address. Still, in the common case, it doesn't change the object address. The reason for using an external buffer for the Unicode object was to be able to do further optimizations, such as share buffers between Unicode objects. We never ended up using this, though, but there's still a lot of room for speedups and more memory efficiency because of this design. Like I already mentioned, PyObjects are also easier to extend at C level - adding new variables to the object at the end is easy with PyObjects. It's difficult for PyVarObjects, since you always have to take the current size of the object into account and you always have to use indirection to get at the extra variables due to the undefined offset of the variables. How much speedup do you get when you compare the pybench test with KEEPALIVE_SIZE_LIMIT = 200 compared to your patched version ? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 15:55:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 27 Jan 2008 14:55:27 -0000 Subject: [issue1944] Documentation for PyUnicode_AsString (et al.) missing. In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za> Message-ID: <1201445727.77.0.522993635795.issue1944@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 15:57:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 27 Jan 2008 14:57:39 -0000 Subject: [issue1945] Document back ported C functions In-Reply-To: <1201445858.91.0.21119487494.issue1945@psf.upfronthosting.co.za> Message-ID: <1201445858.91.0.21119487494.issue1945@psf.upfronthosting.co.za> New submission from Christian Heimes: Document the C functions which were back ported from py3k in r60283. ---------- components: Documentation keywords: easy messages: 61736 nosy: tiran priority: normal severity: normal status: open title: Document back ported C functions type: rfe versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 16:20:46 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 27 Jan 2008 15:20:46 -0000 Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up. In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za> Message-ID: <1201447246.47.0.484191637655.issue1682@psf.upfronthosting.co.za> Mark Dickinson added the comment: I noticed that the ability to type Rational("2.3") has been added (and I think this is a very useful addition). One minor nit: would it make sense to have Rational("2.") and Rational(".3") also work? These strings work for float() and Decimal(), and 2. and .3 work as float literals, so it would seem to make sense to allow this for Rational as well. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 16:35:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Jan 2008 15:35:42 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201448142.84.0.527981260707.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: With KEEPALIVE_SIZE_LIMIT = 200, the pybench runtime is basically the same as with my patched version. stringbench remains a bit faster though (~8%). You say that RAM size is cheaper than CPU power today, which is true but misses one part of the picture: the importance of CPU caches, and thus of working set size. There are also probably people wanting to use Python in memory-constrained environments (embedded). I understand the argument about possible optimizations with an external buffer, but are such optimizations likely to be implemented? (see #1590352 and #1629305). If they really are, then I'm happy with the unicode type remaining a plain PyObject! __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 16:59:04 2008 From: report at bugs.python.org (Israel Tsadok) Date: Sun, 27 Jan 2008 15:59:04 -0000 Subject: [issue1946] re.search hangs on this In-Reply-To: <1201449544.57.0.177227713029.issue1946@psf.upfronthosting.co.za> Message-ID: <1201449544.57.0.177227713029.issue1946@psf.upfronthosting.co.za> New submission from Israel Tsadok: import re re.search(r'a(b[^b]*b|[^c])*cxxx', 'abbcacabbbbcabbbbbbcabbbbbbbbbbbbbbcacabbbbbbbbbbbbbbcabbbbcac') perl seems to handle this just fine. (The original problem was trying to translate some html to text: re.sub(r'])*>(.*?)

', r'\1\n') This hanged on several files. Changing [^>] to [^">] resolved my problem, but the general case remains.) This might be a dupe of http://bugs.python.org/issue1297193 ---------- components: Regular Expressions messages: 61739 nosy: itsadok severity: normal status: open title: re.search hangs on this versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 17:03:56 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 27 Jan 2008 16:03:56 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201449836.03.0.994558797943.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I don't really see the connection with #1629305. An optimization that would be worth checking is hooking up the Py_UNICODE pointer to interned Unicode objects if the contents match (e.g. do a quick check based on the hash value and then a memcmp). That would save memory and the call to the pymalloc allocator. Another strategy could involve a priority queue style cache with the aim of identifying often used Unicode strings and then reusing them. This could also be enhanced using an offline approach: you first run an application with an instrumented Python interpreter to find the most often used strings and then pre-fill the cache or interned dictionary on the production Python interpreter at startup time. Coming from a completely different angle, you could also use the Py_UNICODE pointer to share slices of a larger data buffer. A Unicode sub-type could handle this case, keeping a PyObject* reference to the larger buffer, so that it doesn't get garbage collected before the Unicode slice. Regarding memory constrained environments: these should simply switch off all free lists and pymalloc. OTOH, even mobile phones come with gigabytes of RAM nowadays, so it's not really worth the trouble, IMHO. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 17:46:46 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Jan 2008 16:46:46 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201452406.83.0.689161559489.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: All of those proposals are much heavier to implement; they also make the unicode type more complicated and difficult to maintain probably (while turning it into a PyVarObject actually shortens the implementation a bit). In any case, it's not something I want to tackle. The reason that I mentioned #1629305 was that it was such an optimization which complicated the unicode type while bringing very significant speedups. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 18:37:15 2008 From: report at bugs.python.org (shore.cloud) Date: Sun, 27 Jan 2008 17:37:15 -0000 Subject: [issue1947] Exception exceptions.AttributeError '_shutdown' in Message-ID: <1201455435.45.0.790953321864.issue1947@psf.upfronthosting.co.za> New submission from shore.cloud: Exception exceptions.AttributeError: '_shutdown' in ignored ---------- files: thread1.py messages: 61742 nosy: Mr Shore severity: normal status: open title: Exception exceptions.AttributeError '_shutdown' in __________________________________ From report at bugs.python.org Sun Jan 27 19:05:40 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 27 Jan 2008 18:05:40 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201457140.47.0.873900594838.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Agreed, those optimizations do make the implementation more complicated. It's also not clear whether they would really be worth it. #1629305 only provided speedups for the case where you write s += 'abc'. The usual idiom for this is to use a list and then concatenate in one go. If you want a really fast approach, you'd use cStringIO or perhaps the bufferarray. I don't think that optimizing for just one particular use case warrants making the code more complicated or changing the C interface radically. In your case, I think that closing the door for being able to easily extend the type implement at the C is the main argument against it. The speedups are only marginal and can also be achieved (to some extent) by tuning the existing implementation's parameters. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 19:16:20 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 27 Jan 2008 18:16:20 -0000 Subject: [issue1867] patch for pydoc to work in py3k In-Reply-To: <1200685441.85.0.862976764101.issue1867@psf.upfronthosting.co.za> Message-ID: <1201457780.69.0.937619654175.issue1867@psf.upfronthosting.co.za> Georg Brandl added the comment: Done in r60366, thanks! __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 19:58:17 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 27 Jan 2008 18:58:17 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201460297.6.0.656026597414.issue1941@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Today, I carefully looked through every change in my patching. I asked myself "Does this do the same things in the same order as the original?" and "Could exceptions cause the code to function differently?" They only changes were when the block which used the file was not in a try finally block so if an exception were raised, it the file would be closed. The with statement of course removes this problem. So, I do believe the patch is "semantically neutral." I would, however, not mind if another set of eyes examined it. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 19:58:42 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 27 Jan 2008 18:58:42 -0000 Subject: [issue1947] Exception exceptions.AttributeError '_shutdown' in Message-ID: <1201460321.93.0.999415914807.issue1947@psf.upfronthosting.co.za> Christian Heimes added the comment: Next time please set type, component and version ---------- components: +Library (Lib) nosy: +tiran priority: -> low type: -> behavior versions: +Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 20:03:10 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Jan 2008 19:03:10 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201460590.16.0.369302690305.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I know it's not the place to discuss #1629305, but the join() solution is not always faster. Why? Because 1) there's the list contruction and method call overhead 2) ceval.c has some bytecode hackery to try and make plain concatenations somewhat less slow. As for cStringIO, I actually observed in some experiments that it was slower than the other alternatives, at least for short strings. All in all, choosing between the three idioms is far from obvious and needs case-by-case analysis. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 20:37:05 2008 From: report at bugs.python.org (shore.cloud) Date: Sun, 27 Jan 2008 19:37:05 -0000 Subject: [issue1947] Exception exceptions.AttributeError '_shutdown' in Message-ID: shore.cloud added the comment: I will,sorry 2008/1/28, Christian Heimes : > > > Christian Heimes added the comment: > > Next time please set type, component and version > > ---------- > components: +Library (Lib) > nosy: +tiran > priority: -> low > type: -> behavior > versions: +Python 2.5 > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9300/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080127/6f8210a4/attachment.txt From report at bugs.python.org Sun Jan 27 20:38:59 2008 From: report at bugs.python.org (safe alattar) Date: Sun, 27 Jan 2008 19:38:59 -0000 Subject: [issue1948] Cant open python gui using VISTA In-Reply-To: <1201462739.88.0.734539859059.issue1948@psf.upfronthosting.co.za> Message-ID: <1201462739.88.0.734539859059.issue1948@psf.upfronthosting.co.za> New submission from safe alattar: I need help opening the python gui (IDLE). On XP I had no issues. On Vista nothing occurs when I try to open IDLE. If there is a solution to this, please let me know in a user friendly manner (Im new to this!) Thanks. ---------- messages: 61749 nosy: needhelpasap severity: normal status: open title: Cant open python gui using VISTA __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 23:19:46 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 27 Jan 2008 22:19:46 -0000 Subject: [issue1949] test_ntpath.py rewriting In-Reply-To: <1201472386.07.0.26140471271.issue1949@psf.upfronthosting.co.za> Message-ID: <1201472386.07.0.26140471271.issue1949@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': Since I noticed that test_ntpath.py (unlike test_genericpath.py, test_macpath.py and test_posixpath.py) does NOT use unittest for doing tests I tried to rewrite it. The patch in attachment does that leaving the original tests unchanged. Tested successfully by having used python 2.6 (current trunk) on Windows XP and Linux Ubuntu. ---------- components: Tests files: test_ntpath.diff messages: 61750 nosy: giampaolo.rodola severity: normal status: open title: test_ntpath.py rewriting versions: Python 2.6 Added file: http://bugs.python.org/file9301/test_ntpath.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 23:20:35 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 27 Jan 2008 22:20:35 -0000 Subject: [issue1949] test_ntpath.py rewriting In-Reply-To: <1201472386.07.0.26140471271.issue1949@psf.upfronthosting.co.za> Message-ID: <1201472435.29.0.558944759626.issue1949@psf.upfronthosting.co.za> Changes by Giampaolo Rodola': Added file: http://bugs.python.org/file9302/test_ntpath.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 23:25:01 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 27 Jan 2008 22:25:01 -0000 Subject: [issue1948] Cant open python gui using VISTA In-Reply-To: <1201462739.88.0.734539859059.issue1948@psf.upfronthosting.co.za> Message-ID: <1201472701.48.0.775223750993.issue1948@psf.upfronthosting.co.za> Christian Heimes added the comment: I assume you are talking about Python 2.5.1 on Windows Vista? Yes, there is a solution. You have to unhide the folder .idlerc in your USERPROFILE directory and remove its content. ---------- assignee: -> kbk components: +IDLE nosy: +kbk, tiran priority: -> high type: -> crash versions: +Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 23:28:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 27 Jan 2008 22:28:15 -0000 Subject: [issue1949] test_ntpath.py rewriting In-Reply-To: <1201472386.07.0.26140471271.issue1949@psf.upfronthosting.co.za> Message-ID: <1201472895.03.0.937008038686.issue1949@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch looks fine but I've no time to review it properly. ---------- keywords: +easy, patch nosy: +tiran priority: -> normal resolution: -> accepted type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 23:34:50 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 27 Jan 2008 22:34:50 -0000 Subject: [issue1949] test_ntpath.py converted to unittest In-Reply-To: <1201472386.07.0.26140471271.issue1949@psf.upfronthosting.co.za> Message-ID: <1201473290.01.0.381599954304.issue1949@psf.upfronthosting.co.za> Changes by Giampaolo Rodola': ---------- title: test_ntpath.py rewriting -> test_ntpath.py converted to unittest __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 23:44:55 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 27 Jan 2008 22:44:55 -0000 Subject: [issue1950] Potential Overflow due to incorrect usage of PyUnicode_AsString. In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za> Message-ID: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: I have found a few instances of the following pattern in Py3k: char buf[MAX]; len = PyUnicode_GET_SIZE(str); if (len >= MAX) /* return error */ strcpy(buf, PyUnicode_AsString(str)); which could overflow if str contains non-ASCII characters. These were probably introduced during the PyString -> PyUnicode transition. Anyway, I got a patch that fixes (hopefully) most of these bugs. ---------- assignee: alexandre.vassalotti components: Interpreter Core files: unicode_string_overflow.patch keywords: patch messages: 61753 nosy: alexandre.vassalotti priority: normal severity: normal status: open title: Potential Overflow due to incorrect usage of PyUnicode_AsString. type: security versions: Python 3.0 Added file: http://bugs.python.org/file9303/unicode_string_overflow.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Jan 27 23:45:12 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 27 Jan 2008 22:45:12 -0000 Subject: [issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString. In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za> Message-ID: <1201473912.83.0.933629305729.issue1950@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: ---------- title: Potential Overflow due to incorrect usage of PyUnicode_AsString. -> Potential overflows due to incorrect usage of PyUnicode_AsString. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 01:03:39 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Jan 2008 00:03:39 -0000 Subject: [issue1951] test_wave.py converted to unittest In-Reply-To: <1201478619.82.0.744977170557.issue1951@psf.upfronthosting.co.za> Message-ID: <1201478619.82.0.744977170557.issue1951@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': In attachment. ---------- components: Tests files: test_wave.diff messages: 61754 nosy: giampaolo.rodola severity: minor status: open title: test_wave.py converted to unittest type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9304/test_wave.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 01:54:44 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Jan 2008 00:54:44 -0000 Subject: [issue1951] test_wave.py converted to unittest In-Reply-To: <1201478619.82.0.744977170557.issue1951@psf.upfronthosting.co.za> Message-ID: <1201481684.87.0.365067854332.issue1951@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Sorry but I realized right now by reading Lib/test/readme.txt that the test scripts are required to have a global "test_main()" function defined hence the "main()" function I defined in my patch should be renamed in "test_main()". __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 02:21:20 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Jan 2008 01:21:20 -0000 Subject: [issue1952] test_select.py converted to unittest In-Reply-To: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za> Message-ID: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': In attachment. ---------- components: Tests files: test_select.diff messages: 61756 nosy: giampaolo.rodola severity: minor status: open title: test_select.py converted to unittest type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9305/test_select.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 02:21:54 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Jan 2008 01:21:54 -0000 Subject: [issue1952] test_select.py converted to unittest In-Reply-To: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za> Message-ID: <1201483314.84.0.254793710325.issue1952@psf.upfronthosting.co.za> Changes by Giampaolo Rodola': Added file: http://bugs.python.org/file9306/test_select.py __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 03:17:38 2008 From: report at bugs.python.org (Neal Norwitz) Date: Mon, 28 Jan 2008 02:17:38 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201486658.16.0.924505845459.issue1621@psf.upfronthosting.co.za> Neal Norwitz added the comment: I'm just starting to look at the patch. The first one changes i to unsigned in Modules/_csv.c. Hopefully most of them are like this. The code is fine as it is. There is no reliance on overflow AFAICT. It's just that the breaking condition from the loop is not in the for (...). I think this change is fine to avoid a warning. Just pointing out that in this one case, it's not a real problem. Change to heapq doesn't seem needed. I looked at the warning generated from this and it's if (!n). This seems to indicate the compiler thinks that n could be negative. That should not be possible. It came from PyList_GET_SIZE. We had verified the object was already a list. So this value should be between 0 and PY_SSIZE_T_MAX. We check for 0, so it might be > 0. After decrementing n, it should be between 0 and PY_SSIZE_T_MAX-1. Of course, the compiler can't know the value can't be negative (or PY_SSIZE_T_MIN) which would cause an underflow. Change to hotshot should avoid a cast, so it's slightly better with this approach. Although with the change to size_t, the cast in flush_data can be removed (just after the fwrite). I don't see the reason to need for the change in sre.c, but I'm pretty sure there are other overflows. audioop definitely looks needed. cPickle looks necessary. expat/xmlparse.c is interesting--not sure if it's really necessary. In practice this probably can't be reached. gc can't really overflow given that NUM_GENERATIONS is 3 and not likely to grow much more. :-) I stopped looking at this point. It looks like some of these are really needed. Others are not possible given other invariants (the compiler can't know about). I like the idea of silencing compiler warnings. However, I fear this may generate a different problem. Namely signed/unsigned mismatches. What happens if you add this warning: -Wsign-compare I think we got rid of most of those before (probably not true as much for Modules/*.c). I think this introduces many more. Would it be possible to come up with a patch that doesn't introduce more warnings w/-Wsign-compare? One potential issue with this patch is that while the additions might have guaranteed semantics, we might have other problems when doing: size_t value = PyXXX_Size(); if (value < 0) ... I'm hoping that if we can use both -Wstrict-overflow and -Wsign-conversion, eliminate all warnings, resulting in better code. (You could also try building with g++. The core used to work without warnings. The modules still had a ways to go.) Also what is the current state? What has been implemented and what else needs to be done? Perhaps we should make other bug report(s) to address other tangents that were discussed in this thread. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 03:28:50 2008 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 28 Jan 2008 02:28:50 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201487330.59.0.0890154001472.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Thanks for the through review! I will add -Wsign-compare and fix new warnings. Btw current state is with the patch -fwrapv is not needed and no regressions. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 03:41:06 2008 From: report at bugs.python.org (Neal Norwitz) Date: Mon, 28 Jan 2008 02:41:06 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1201487330.59.0.0890154001472.issue1621@psf.upfronthosting.co.za> Message-ID: Neal Norwitz added the comment: I just added -Wstrict-overflow to the code in sysmodule.c (sys_getframe) and tried with gcc 4.2.1. It doesn't warn. I wonder if 4.3 is more picky or warns when it shouldn't? Unless if I changed the code so it doesn't work: typedef struct {int ref;} PyObject; typedef struct { PyObject* f_back; } PyFrameObject; int PyArg_ParseTuple(PyObject*, const char*, int*); PyObject * sys_getframe(PyFrameObject *f, PyObject *self, PyObject *args) { int depth = -1; if (!PyArg_ParseTuple(args, "|i:_getframe", &depth)) return 0; while (depth > 0 && f != 0) { f = (PyFrameObject*)f->f_back; --depth; } return (PyObject*)f; } Compiled with: gcc-4.2.1-glibc-2.3.2/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-gcc -Wstrict-overflow -c xx.c produced no warnings. This is not a stock gcc 4.2.1, so that could also be an issue. Did I run it correctly. Is there anything else I need to do? If you run the code above with gcc 4.3, does it produce a warning? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 03:41:26 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 28 Jan 2008 02:41:26 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201488086.26.0.566497123574.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: Unfortunately I have no time to work on this myself, but in order to make progress I recommend checking in things piecemeal so that the same changes don't get reviewed over and over again. I propose that each submit reference this bug ("Partial fix for issue #1621" I'd suggest) and that the submits are recorded here (e.g. "fixed in rXXX (2.5.2), rYYY (2.6)"). Then hopefully only a few hard cases will remain. With Neal, I don't see what the warning in _csv is about. What condition is being turned into a constant? Is the compiler perhaps rearranging the code so as to insert "if (field[0] == '\0') goto XXX;" in front of the for-loop where XXX jumps into the middle of the condition in the if-statement immediately following the for-loop, and skipping that if-block when breaking of the loop later? That would be clever, and correct, and I'm not sure if making i unsigned is going to help -- in fact it might make the compiler decide it can't use that optimization... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 03:45:12 2008 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 28 Jan 2008 02:45:12 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201488312.29.0.673986017288.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: To Neal, Can you try with -Wstrict-overflow=3 , but yes I am using gcc 4.3 trunk. To Guido, I'll check _csv.c issue closely. Shall I create the new bug reports or will reviewers will do so and CC me maybe? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 03:51:06 2008 From: report at bugs.python.org (Neal Norwitz) Date: Mon, 28 Jan 2008 02:51:06 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1201488312.29.0.673986017288.issue1621@psf.upfronthosting.co.za> Message-ID: Neal Norwitz added the comment: On Jan 27, 2008 6:45 PM, Ismail Donmez wrote: > > Can you try with -Wstrict-overflow=3 , but yes I am using gcc 4.3 trunk. I just tried with =1, =2, =3, and no =. All the same result: no warning. Ismail, thanks for going through all this effort. It's very helpful. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 03:54:17 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 28 Jan 2008 02:54:17 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201488857.58.0.31544567743.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: Don't create new bug reports! __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 03:59:34 2008 From: report at bugs.python.org (Ray Chason) Date: Mon, 28 Jan 2008 02:59:34 -0000 Subject: [issue1926] NNTPS support in nntplib In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za> Message-ID: <1201489174.59.0.580429992019.issue1926@psf.upfronthosting.co.za> Ray Chason added the comment: It seems that I, or whoever writes any future test_nntplib.py, would have to understand how existing tests such as test_smtplib.py work. It looks like that one is setting up some kind of miniature mail server and accepting a connection on localhost -- neat trick, binding a server socket to port 0 so it still works if you have a real mail server running. Anyway, getting good coverage isn't something I can bang out in an afternoon. Class NNTPBase and its derivatives (I'm talking post-patch of course) have lots of methods and I want to cover them as well as possible. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 04:02:23 2008 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 28 Jan 2008 03:02:23 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201489343.89.0.700346713424.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Neal, I'll try to answer your questions one by one, first with _csv.c compiler issues : Modules/_csv.c:969: warning: assuming signed overflow does not occur when simplifying conditional to constant There is a check inside loop like this: if (c == '\0') break; Instead of this if we do the check in the for : + for (i = 0; i < strlen(field) ; i++) { and remove the if check compiler no longer issues a warning also csv test passes with this. Attached patch implements this optimization. Guido, you don't have to shout, you know noone pays me per python bugreport I create :) Added file: http://bugs.python.org/file9307/csv.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 04:10:02 2008 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 28 Jan 2008 03:10:02 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201489802.97.0.0169977796813.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: _sre.c case is the most interesting one , compiler says : ./Modules/_sre.c:1002: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1069: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1086: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1143: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1185: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1214: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1238: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1251: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1277: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1291: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1308: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1395: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1408: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c: In function 'sre_umatch': ./Modules/_sre.c:1002: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1069: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1086: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1143: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1185: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1214: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1238: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1251: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1277: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1291: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1308: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1395: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1408: warning: assuming signed overflow does not occur when simplifying conditional to constant all lines refer to : RETURN_ON_ERROR(ret); My investigation : On line 1002 we got RETURN_ON_ERROR(ret); but ret is already 0 and not set to anything this if will always be false. Same for line 1069, ret is still zero there. Maybe I am missing something here? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 04:16:57 2008 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 28 Jan 2008 03:16:57 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201490217.8.0.899627183612.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: For xmlparse.c compiler says : Modules/expat/xmlparse.c:5337: warning: assuming signed overflow does not occur when simplifying conditional to constant Its impossible for j to overflow here due to name[i] check but I am not sure what gcc is optimizing here. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 04:20:29 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 28 Jan 2008 03:20:29 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201490429.34.0.607414472246.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: > for (i = 0; i < strlen(field) ; i++) { This looks inefficient. Why not for (i = 0; field[i] != '\0'; i++) { ??? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 04:30:30 2008 From: report at bugs.python.org (safe alattar) Date: Mon, 28 Jan 2008 03:30:30 -0000 Subject: [issue1948] Cant open python gui using VISTA In-Reply-To: <1201462739.88.0.734539859059.issue1948@psf.upfronthosting.co.za> Message-ID: <1201491030.37.0.15261674413.issue1948@psf.upfronthosting.co.za> safe alattar added the comment: I made a search for the hidden folder 'idlerc' and got back no results : ( __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 04:32:54 2008 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 28 Jan 2008 03:32:54 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201491174.09.0.5232234057.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Hah strlen in a loop, a nice beginner mistake but its 5.30 AM here so please excuse me, Guido your version of course is way better. But with that version compiler issues Modules/_csv.c:969: warning: assuming signed overflow does not occur when simplifying conditional to constant again, strlen() just fooled that optimization it seems. So there should be another way to optimize this loop. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 04:34:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Jan 2008 03:34:29 -0000 Subject: [issue1953] gc.compact_freelists In-Reply-To: <1201491269.72.0.799398122167.issue1953@psf.upfronthosting.co.za> Message-ID: <1201491269.72.0.799398122167.issue1953@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch implements gc.compact_freelists() which calls PyInt and PyFloat_CompactFreeList(). I've moved the code from the _Fini methods to the _CompactFreeList() methods. The patch also moves the clear type cache function to gc.clear_type_cache(). ---------- assignee: nnorwitz components: Extension Modules, Interpreter Core files: trunk_compact_freelist.patch keywords: patch messages: 61771 nosy: nnorwitz, tiran priority: normal severity: normal status: open title: gc.compact_freelists type: rfe versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9308/trunk_compact_freelist.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 04:36:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Jan 2008 03:36:45 -0000 Subject: [issue1952] test_select.py converted to unittest In-Reply-To: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za> Message-ID: <1201491405.71.0.439056202936.issue1952@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 05:46:53 2008 From: report at bugs.python.org (Bill Janssen) Date: Mon, 28 Jan 2008 04:46:53 -0000 Subject: [issue1926] NNTPS support in nntplib In-Reply-To: <1201489174.59.0.580429992019.issue1926@psf.upfronthosting.co.za> Message-ID: <4b3e516a0801272046m5d1b58dau5c487ad182031566@mail.gmail.com> Bill Janssen added the comment: Yeah, it took me a couple of months to do a reasonable test case for the SSL code. Perhaps we could test against an existing NNTP server? Like Google's? Bill On Jan 27, 2008 6:59 PM, Ray Chason wrote: > > Ray Chason added the comment: > > It seems that I, or whoever writes any future test_nntplib.py, would > have to understand how existing tests such as test_smtplib.py work. It > looks like that one is setting up some kind of miniature mail server and > accepting a connection on localhost -- neat trick, binding a server > socket to port 0 so it still works if you have a real mail server running. > > Anyway, getting good coverage isn't something I can bang out in an > afternoon. Class NNTPBase and its derivatives (I'm talking post-patch > of course) have lots of methods and I want to cover them as well as > possible. > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9309/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080128/0864e1f5/attachment.txt From report at bugs.python.org Mon Jan 28 06:51:19 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 28 Jan 2008 05:51:19 -0000 Subject: [issue1954] SocketServer.ForkingMixIn creates a zombie In-Reply-To: <1201499479.46.0.649764617185.issue1954@psf.upfronthosting.co.za> Message-ID: <1201499479.46.0.649764617185.issue1954@psf.upfronthosting.co.za> New submission from Ralf Schmitt: collect_children is only called in process_request, so at least the last process forked is not collected. This could be handled by calling collect_children every X seconds or by handling SIGCHLD. ---------- messages: 61773 nosy: schmir severity: normal status: open title: SocketServer.ForkingMixIn creates a zombie __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 09:14:21 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 28 Jan 2008 08:14:21 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1201488086.26.0.566497123574.issue1621@psf.upfronthosting.co.za> Message-ID: <479D8ED4.8090608@v.loewis.de> Martin v. L?wis added the comment: > With Neal, I don't see what the warning in _csv is about. What condition > is being turned into a constant? Is the compiler perhaps rearranging the > code so as to insert "if (field[0] == '\0') goto XXX;" in front of the > for-loop where XXX jumps into the middle of the condition in the > if-statement immediately following the for-loop, and skipping that > if-block when breaking of the loop later? Indeed that's what happens. In the case of breaking the loop later, the compiler can skip the if-block only if signed ints never overflow, hence the warning. Another way of silencing the warning is to test field[0]=='\0' in the if-statement. This might also somewhat pessimize the code, but allows the compiler to eliminate i altogether. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 09:33:42 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 28 Jan 2008 08:33:42 -0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1201509222.92.0.554283291151.issue1025395@psf.upfronthosting.co.za> Changes by Martin v. L?wis: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 28 12:09:40 2008 From: report at bugs.python.org (Stephen Emslie) Date: Mon, 28 Jan 2008 11:09:40 -0000 Subject: [issue1923] meaningful whitespace can be lost in rfc822_escape In-Reply-To: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za> Message-ID: <1201518580.0.0.0285378866357.issue1923@psf.upfronthosting.co.za> Stephen Emslie added the comment: Here's that keeps the whitespace in tact, along with a simple test. This doesn't patch docs as the existing documentation_ already describes the long string as multiple lines of "plain text in reStructuredText format", which is what this fixes. .. _documentation: http://docs.python.org/dev/distutils/setupscript.html#additional-meta-data Added file: http://bugs.python.org/file9310/distutils_metadata_whitespace.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 15:39:39 2008 From: report at bugs.python.org (Adam Goucher) Date: Mon, 28 Jan 2008 14:39:39 -0000 Subject: [issue1955] fix using unittest as a superclass In-Reply-To: <1201531179.73.0.502077509605.issue1955@psf.upfronthosting.co.za> Message-ID: <1201531179.73.0.502077509605.issue1955@psf.upfronthosting.co.za> New submission from Adam Goucher: There are a couple places in unittest where 'issubclass(something, TestCase)' is used. This prevents you from organizing your test code via class hierarchies. To solve this problem, issubclass should be looking whether the object is a subclass of unittest.TestCase to walk the inheritance tree all the way up and not just a single level. Currently, this will not work. module A.. class A(unittest.TestCase): pass module B... import A class B(A.A) def testFoo(self): print "blah blah blah I have attached a patch which will address all locations where this could happen. ---------- components: Library (Lib) files: cpython-unittest-subclass.diff messages: 61776 nosy: agoucher severity: normal status: open title: fix using unittest as a superclass versions: Python 2.5 Added file: http://bugs.python.org/file9311/cpython-unittest-subclass.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 15:40:58 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Mon, 28 Jan 2008 14:40:58 -0000 Subject: [issue1956] Lib/bsddb/test/test_thread.py uses old 'except' syntax In-Reply-To: <1201531258.39.0.0196498727995.issue1956@psf.upfronthosting.co.za> Message-ID: <1201531258.39.0.0196498727995.issue1956@psf.upfronthosting.co.za> New submission from Georgij Kondratjev: "except OSError, e:" (appears twice) should be changed to "except OSError as e:" ---------- components: Library (Lib) messages: 61777 nosy: orivej severity: normal status: open title: Lib/bsddb/test/test_thread.py uses old 'except' syntax type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 15:44:50 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Mon, 28 Jan 2008 14:44:50 -0000 Subject: [issue1956] Lib/bsddb/test/test_thread.py uses old 'except' syntax In-Reply-To: <1201531258.39.0.0196498727995.issue1956@psf.upfronthosting.co.za> Message-ID: <1201531490.88.0.612807331784.issue1956@psf.upfronthosting.co.za> Georgij Kondratjev added the comment: Appeared in 60350 svnmerge: http://svn.python.org/view/python/branches/py3k/Lib/bsddb/test/test_thread.py?rev=60350&view=log http://svn.python.org/view/python/branches/py3k/Lib/bsddb/test/test_thread.py?rev=60350&r1=58058&r2=60350 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 15:52:40 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Mon, 28 Jan 2008 14:52:40 -0000 Subject: [issue1956] Lib/bsddb/test/test_thread.py uses old 'except' syntax In-Reply-To: <1201531258.39.0.0196498727995.issue1956@psf.upfronthosting.co.za> Message-ID: <1201531960.5.0.25686364165.issue1956@psf.upfronthosting.co.za> Georgij Kondratjev added the comment: If you notice that at http://svn.python.org/view/python/branches/py3k/Lib/bsddb/test/test_thread.py?rev=60350&r1=58058&r2=60350 "shutil.rmtree(self.homeDir)" didn`t change between revisions, that would be false: in fact extra space (" ") was added. Is this a bug in Roundup? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 16:10:07 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Jan 2008 15:10:07 -0000 Subject: [issue1955] fix using unittest as a superclass In-Reply-To: <1201531179.73.0.502077509605.issue1955@psf.upfronthosting.co.za> Message-ID: <1201533007.1.0.763669847767.issue1955@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't really understand what problem you are trying to solve. Can you attach a sample script to show it more clearly? Also, the only thing your patch does is rename Test(Case|Suite) references to unittest.Test(Case|Suite)... I doubt it would have any effect unless you were monkeypatching the unittest module to replace those classes with other ones (which should certainly be considered very dirty ;-)). ---------- nosy: +pitrou __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 16:31:54 2008 From: report at bugs.python.org (Dennis Jensen) Date: Mon, 28 Jan 2008 15:31:54 -0000 Subject: [issue1957] [patch] syslogmodule: Release GIL when calling syslog(3) In-Reply-To: <1201534314.07.0.339732897675.issue1957@psf.upfronthosting.co.za> Message-ID: <1201534314.07.0.339732897675.issue1957@psf.upfronthosting.co.za> New submission from Dennis Jensen: The glibc syslog(3) call will block in some cases; the attached patch releases the GIL around the syslog call. ---------- components: Extension Modules, Interpreter Core files: syslogmodule-patch.txt messages: 61781 nosy: rd2 severity: minor status: open title: [patch] syslogmodule: Release GIL when calling syslog(3) type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9312/syslogmodule-patch.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 16:57:32 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 28 Jan 2008 15:57:32 -0000 Subject: [issue1955] fix using unittest as a superclass In-Reply-To: <1201531179.73.0.502077509605.issue1955@psf.upfronthosting.co.za> Message-ID: <1201535852.9.0.518317255899.issue1955@psf.upfronthosting.co.za> Guido van Rossum added the comment: This patch seems to be based upon a misunderstanding of how Python namespaces work. ---------- keywords: +patch nosy: +gvanrossum resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 18:53:48 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Jan 2008 17:53:48 -0000 Subject: [issue1957] [patch] syslogmodule: Release GIL when calling syslog(3) In-Reply-To: <1201534314.07.0.339732897675.issue1957@psf.upfronthosting.co.za> Message-ID: <1201542828.1.0.463323137036.issue1957@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks for the patch. I'm going to review it later. ---------- keywords: +patch nosy: +tiran priority: -> high versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 18:54:11 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 28 Jan 2008 17:54:11 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201542851.63.0.752605905094.issue1621@psf.upfronthosting.co.za> Guido van Rossum added the comment: I wonder if it would help making i a Py_ssize_t instead of an int? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 18:54:40 2008 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 28 Jan 2008 17:54:40 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201542880.22.0.355825432599.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Neal, You could btw check http://repo.or.cz/w/pytest.git?a=shortlog;h=overflow-fix which have each fix seperate so that reviewing is easy. Just ignore configure changes thats for later. Thanks, ismail __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 18:54:50 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Jan 2008 17:54:50 -0000 Subject: [issue1956] Lib/bsddb/test/test_thread.py uses old 'except' syntax In-Reply-To: <1201531258.39.0.0196498727995.issue1956@psf.upfronthosting.co.za> Message-ID: <1201542890.15.0.474838898792.issue1956@psf.upfronthosting.co.za> Christian Heimes added the comment: I normally don't run the tests with -uall when I merge changes. from the trunk. ---------- assignee: -> tiran nosy: +tiran priority: -> high resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 18:56:00 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Jan 2008 17:56:00 -0000 Subject: [issue1954] SocketServer.ForkingMixIn creates a zombie In-Reply-To: <1201499479.46.0.649764617185.issue1954@psf.upfronthosting.co.za> Message-ID: <1201542960.7.0.682240054486.issue1954@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you provide a patch? Next time please fill in type, components and versions, too. :) ---------- components: +Library (Lib) nosy: +tiran priority: -> normal type: -> behavior versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 18:57:10 2008 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 28 Jan 2008 17:57:10 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1201542851.63.0.752605905094.issue1621@psf.upfronthosting.co.za> Message-ID: <200801281957.28426.ismail@pardus.org.tr> Ismail Donmez added the comment: > Guido van Rossum added the comment: > > I wonder if it would help making i a Py_ssize_t instead of an int? gcc still issues the same warning with that. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 18:59:37 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 28 Jan 2008 17:59:37 -0000 Subject: [issue1954] SocketServer.ForkingMixIn creates a zombie In-Reply-To: <1201499479.46.0.649764617185.issue1954@psf.upfronthosting.co.za> Message-ID: <1201543177.08.0.815693603901.issue1954@psf.upfronthosting.co.za> Guido van Rossum added the comment: Using signals is asking for all sorts of trouble. What is the point of collecting the last process? Having one zombie child max as a steady state strikes me as totally acceptable. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 19:01:53 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 28 Jan 2008 18:01:53 -0000 Subject: [issue1956] Lib/bsddb/test/test_thread.py uses old 'except' syntax In-Reply-To: <1201531258.39.0.0196498727995.issue1956@psf.upfronthosting.co.za> Message-ID: <1201543313.7.0.315313885781.issue1956@psf.upfronthosting.co.za> Guido van Rossum added the comment: Chris: I think it's worth running all tests before submitting a merge. Catch them early is what I say. :-) ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 19:05:21 2008 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 28 Jan 2008 18:05:21 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201543521.31.0.423381305083.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: gcc is optimizing the second if check , for specifically i == 0 seems to redundant according to gcc. if (i == 0 && quote_empty) { if (dialect->quoting == QUOTE_NONE) { PyErr_Format(error_obj, "single empty field record must be quoted"); return -1; } else *quoted = 1; } __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 19:09:33 2008 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 28 Jan 2008 18:09:33 -0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1201543773.04.0.347783252829.issue1621@psf.upfronthosting.co.za> Ismail Donmez added the comment: Moving the empty check before the loop will fix this and possibly optimize empty string handling. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 19:24:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Jan 2008 18:24:57 -0000 Subject: [issue1956] Lib/bsddb/test/test_thread.py uses old 'except' syntax In-Reply-To: <1201543313.7.0.315313885781.issue1956@psf.upfronthosting.co.za> Message-ID: <479E1DF5.408@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Chris: I think it's worth running all tests before submitting a merge. > Catch them early is what I say. :-) An ordianry test run already takes a considerable amount of time on my system. I usually wait until the build bots notify me about a failing test in the network and bsddb section. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 19:37:43 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Jan 2008 18:37:43 -0000 Subject: [issue1956] Lib/bsddb/test/test_thread.py uses old 'except' syntax In-Reply-To: <1201531258.39.0.0196498727995.issue1956@psf.upfronthosting.co.za> Message-ID: <1201545463.54.0.841015437113.issue1956@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r60394 The bug wasn't detected because the tests couldn't be imported. One test file still used an absolute import instead of a relative. ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 19:41:30 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Jan 2008 18:41:30 -0000 Subject: [issue1951] test_wave.py converted to unittest In-Reply-To: <1201478619.82.0.744977170557.issue1951@psf.upfronthosting.co.za> Message-ID: <1201545690.69.0.660378622523.issue1951@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks for the patch! ---------- keywords: +easy, patch nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 20:26:54 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Jan 2008 19:26:54 -0000 Subject: [issue1951] test_wave.py converted to unittest In-Reply-To: <1201478619.82.0.744977170557.issue1951@psf.upfronthosting.co.za> Message-ID: <1201548414.2.0.635160781646.issue1951@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Glad to help. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 20:37:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Jan 2008 19:37:28 -0000 Subject: [issue1579] logging documentation is unclear In-Reply-To: <1197300194.46.0.863908405505.issue1579@psf.upfronthosting.co.za> Message-ID: <1201549048.85.0.310919977184.issue1579@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy priority: -> normal type: -> rfe versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 20:39:30 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Jan 2008 19:39:30 -0000 Subject: [issue1507] complex constructor loses signs of zeros In-Reply-To: <1196202312.79.0.339731037994.issue1507@psf.upfronthosting.co.za> Message-ID: <1201549170.28.0.930578938504.issue1507@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> high versions: -Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 21:30:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Jan 2008 20:30:42 -0000 Subject: [issue1952] test_select.py converted to unittest In-Reply-To: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za> Message-ID: <1201552242.71.0.65158952334.issue1952@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch looks and works fine for me. Two things: 1. it's a shame the tests are skipped for windows or macintosh, but it was just the same in the original version 2. I don't think sys.platform[:3] can be equal to 'riscos' :) ---------- nosy: +pitrou __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 21:55:00 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 28 Jan 2008 20:55:00 -0000 Subject: [issue1541] Bad OOB data management when using asyncore with select.poll() In-Reply-To: <1196618056.9.0.300104478176.issue1541@psf.upfronthosting.co.za> Message-ID: <1201553700.83.0.487615005865.issue1541@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 21:55:11 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 28 Jan 2008 20:55:11 -0000 Subject: [issue1541] Bad OOB data management when using asyncore with select.poll() In-Reply-To: <1196618056.9.0.300104478176.issue1541@psf.upfronthosting.co.za> Message-ID: <1201553711.99.0.250732678516.issue1541@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- assignee: -> akuchling nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 21:57:24 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 28 Jan 2008 20:57:24 -0000 Subject: [issue1389051] imaplib causes excessive fragmentation for large documents Message-ID: <1201553844.46.0.68711166414.issue1389051@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Jan 28 22:19:37 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Jan 2008 21:19:37 -0000 Subject: [issue1952] test_select.py converted to unittest In-Reply-To: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za> Message-ID: <1201555177.48.0.790732565137.issue1952@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > 1. it's a shame the tests are skipped for windows or macintosh, but it > was just the same in the original version Yeah... I'm probably not the best person for talking about this low level stuff but since sockets seem to be the most portable thing accepted by select.select, maybe a listening socket could be used instead of a process pipe. > 2. I don't think sys.platform[:3] can be equal to 'riscos' You're right. The original version was that way and I didn't notice it was wrong since I've put hands on unittest stuff only. I think this could be fine: - if sys.platform[:3] in ('win', 'mac', 'os2', 'riscos'): + if sys.platform in ('win16', 'win32', 'win64', 'mac', 'os2', 'riscos'): __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 22:51:16 2008 From: report at bugs.python.org (Douglas Mayle) Date: Mon, 28 Jan 2008 21:51:16 -0000 Subject: [issue1958] IPv6 compiled getaddrinfo returns IPv6 address even if the system does not support IPv6 In-Reply-To: <1201557075.89.0.233826065538.issue1958@psf.upfronthosting.co.za> Message-ID: <1201557075.89.0.233826065538.issue1958@psf.upfronthosting.co.za> New submission from Douglas Mayle: The following code calls getadddrinfo and returns invalid addresses (IPv6 addresses) when Python has been compiled with IPv6 support and the system kernel does not support IPv6. import socket for res in socket.getaddrinfo("localhost", "80", 0, socket.SOCK_STREAM): print "%r" % (res,) (2, 1, 6, '', ('127.0.0.1', 80)) (10, 1, 6, '', ('::1', 80, 0, 0)) ---------- components: Library (Lib) messages: 61799 nosy: douglas severity: normal status: open title: IPv6 compiled getaddrinfo returns IPv6 address even if the system does not support IPv6 type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 22:56:52 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 28 Jan 2008 21:56:52 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201557412.73.0.48805092312.issue1577@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Hi Antoine, You stated the following in a previous comment: "Right now, shutil.move(src_dir, dst_dir) replaces dst_dir with src_dir if dst_dir is empty, but moves src_dir inside dst_dir otherwise." But my test shows differently. If dst_dir doesn't exist or if it is empty, dst_dir is simply replaced with src_dir. If dst_dir is non-empty, shutil.move() raises error. In which case did you find src_dir being moved to dst_dir? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 22:57:44 2008 From: report at bugs.python.org (Douglas Mayle) Date: Mon, 28 Jan 2008 21:57:44 -0000 Subject: [issue1958] IPv6 compiled getaddrinfo returns IPv6 address even if the system does not support IPv6 In-Reply-To: <1201557075.89.0.233826065538.issue1958@psf.upfronthosting.co.za> Message-ID: <1201557464.53.0.98218065765.issue1958@psf.upfronthosting.co.za> Douglas Mayle added the comment: Please close this as invalid, the system C library returns the same response... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 23:01:22 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 28 Jan 2008 22:01:22 -0000 Subject: [issue814996] OSF/1 test_dbm segfaults Message-ID: <1201557682.33.0.546687911109.issue814996@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I am assuming that this can be closed considering that there is no activity for a long time. ---------- nosy: +draghuram resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Jan 28 23:02:34 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Jan 2008 22:02:34 -0000 Subject: [issue1959] test_contains.py converted to unittest In-Reply-To: <1201557754.63.0.944783137976.issue1959@psf.upfronthosting.co.za> Message-ID: <1201557754.63.0.944783137976.issue1959@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': In attachment. All existent tests are unchanged. ---------- components: Tests files: test_contains.diff messages: 61803 nosy: giampaolo.rodola severity: normal status: open title: test_contains.py converted to unittest type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9313/test_contains.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 23:02:54 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Jan 2008 22:02:54 -0000 Subject: [issue1959] test_contains.py converted to unittest In-Reply-To: <1201557754.63.0.944783137976.issue1959@psf.upfronthosting.co.za> Message-ID: <1201557774.7.0.260026464184.issue1959@psf.upfronthosting.co.za> Changes by Giampaolo Rodola': Added file: http://bugs.python.org/file9314/test_contains.py __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 23:11:51 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 28 Jan 2008 22:11:51 -0000 Subject: [issue1958] IPv6 compiled getaddrinfo returns IPv6 address even if the system does not support IPv6 In-Reply-To: <1201557075.89.0.233826065538.issue1958@psf.upfronthosting.co.za> Message-ID: <1201558311.58.0.78454713893.issue1958@psf.upfronthosting.co.za> Martin v. L?wis added the comment: My guess is that the C library returns it because /etc/hosts says so. The convention is that /etc/hosts should call ::1 ip6-localhost (and ip6-loopback) instead. ---------- nosy: +loewis resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Jan 28 23:28:53 2008 From: report at bugs.python.org (Douglas Mayle) Date: Mon, 28 Jan 2008 22:28:53 -0000 Subject: [issue1958] IPv6 compiled getaddrinfo returns IPv6 address even if the system does not support IPv6 In-Reply-To: <1201557075.89.0.233826065538.issue1958@psf.upfronthosting.co.za> Message-ID: <1201559333.21.0.357952256816.issue1958@psf.upfronthosting.co.za> Douglas Mayle added the comment: Martin's hypothesis is confirmed, removing ::1 from /etc/hosts removes the response __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 00:31:01 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Jan 2008 23:31:01 -0000 Subject: [issue1960] test_gdbm.py converted to unittest In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za> Message-ID: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': In attachment. All existent tests are unchanged. ---------- components: Tests files: test_gdbm.diff messages: 61806 nosy: giampaolo.rodola severity: normal status: open title: test_gdbm.py converted to unittest type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9315/test_gdbm.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 00:31:20 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Jan 2008 23:31:20 -0000 Subject: [issue1960] test_gdbm.py converted to unittest In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za> Message-ID: <1201563080.12.0.0258961088175.issue1960@psf.upfronthosting.co.za> Changes by Giampaolo Rodola': Added file: http://bugs.python.org/file9316/test_gdbm.py __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 01:08:25 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 29 Jan 2008 00:08:25 -0000 Subject: [issue1960] test_gdbm.py converted to unittest In-Reply-To: <1201563080.12.0.0258961088175.issue1960@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: Have a look at http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=290 where a GHOP student did a conversion as well. Any chance to come up with a possible merged version that takes the best from your work, Giampaolo and the student's work? ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 02:03:28 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 29 Jan 2008 01:03:28 -0000 Subject: [issue1960] test_gdbm.py converted to unittest In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za> Message-ID: <1201568608.45.0.402203019447.issue1960@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > Have a look at http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=290 > where a GHOP student did a conversion as well. Interesting, didn't know about that. In future I'll check that site before start working on a new patch involving the test suite since it seems those students are already working on these kind of issues. > Any chance to come up with a possible merged version > that takes the best from your work, Giampaolo and the > student's work? Don't know... the suite is extremely simple and, IMO, I don't even think there's a real need to do that. I noticed that the student added/changed some stuff like the new "test_modes" method which maybe could be useful to have. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 02:19:08 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 29 Jan 2008 01:19:08 -0000 Subject: [issue923643] long <-> byte-string conversion Message-ID: <1201569548.46.0.445958041693.issue923643@psf.upfronthosting.co.za> Mark Dickinson added the comment: Closing this due to little-or-no activity for over three years. Antoine's use case seems to me to be covered by issue #1023290. Trevor, please speak up if you want to keep this alive. ---------- resolution: -> rejected status: open -> pending superseder: -> proposed struct module format code addition ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Jan 29 02:24:36 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 29 Jan 2008 01:24:36 -0000 Subject: [issue1960] test_gdbm.py converted to unittest In-Reply-To: <1201568608.45.0.402203019447.issue1960@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Jan 28, 2008 5:03 PM, Giampaolo Rodola' wrote: > > Giampaolo Rodola' added the comment: > > > Have a look at > http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=290 > > where a GHOP student did a conversion as well. > > Interesting, didn't know about that. > In future I'll check that site before start working on a new patch > involving the test suite since it seems those students are already > working on these kind of issues. > We have held off on committing their code until we get contributor agreements from them. Hopefully that will all get resolved in February and thus you won't have to check the GHOP site for long. > > Any chance to come up with a possible merged version > > that takes the best from your work, Giampaolo and the > > student's work? > > Don't know... the suite is extremely simple and, IMO, I don't even think > there's a real need to do that. > I noticed that the student added/changed some stuff like the new > "test_modes" method which maybe could be useful to have. Well, if you have an opinion, feel free to leave a comment in this issue about it. I will most likely be the one who does the checkin and I will read this issue before I commit. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 03:20:18 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 29 Jan 2008 02:20:18 -0000 Subject: [issue1960] test_gdbm.py converted to unittest In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za> Message-ID: <1201573218.16.0.448704306744.issue1960@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > Well, if you have an opinion, feel free to leave a comment in this > issue about it. I will most likely be the one who does the checkin and > I will read this issue before I commit. * One of the things I dislike is the fact that the student used "self.g = gdbm.open(self.filename, 'c')" in setUp method since if that fails there will be a NameError exception raised in tearDown method and the errors reported by unittest would be 2 where in fact it would be only 1. Probably a thing like this one would have been better: def setUp(self): self.g = None def tearDown(self): if self.g is not None: self.g.close() ... def test_it(self): self.g = gdbm.open(self.filename, 'c') ... - Another thing I don't like is that os.unlink(self.filename) executed in tearDown would be better if protected by a try/except statement. - +1 for the self.g.close() used by the student in the tearDown method. That was a thing I haven't considered and it's not included in my patch. - +0.5 for the "test_modes" method added by the student. Maybe it's useful, maybe it's not, I don't know. Aside from that I don't see other relevant differences since the code is really minimalistic. Feel free to commit the patch you consider to be the best. If you want me to do so I can provide a merged version of my patch including the differences I described above. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 04:06:45 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 29 Jan 2008 03:06:45 -0000 Subject: [issue1961] possible error with json format for sphinx In-Reply-To: <1201576005.17.0.220280417702.issue1961@psf.upfronthosting.co.za> Message-ID: <1201576005.17.0.220280417702.issue1961@psf.upfronthosting.co.za> New submission from Brett Cannon: I currently can't build the docs (r60374): ... File "/Users/brett/Dev/python/2.x/pristine/Doc/tools/sphinx/search.py", line 70, in load for (k, v) in frozen[2].iteritems()) AttributeError: 'list' object has no attribute 'iteritems' make: *** [build] Error 1 Seems to be related to the json stuff based on the full traceback. ---------- components: Documentation tools (Sphinx) messages: 61812 nosy: brett.cannon priority: high severity: normal status: open title: possible error with json format for sphinx versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 04:14:31 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 29 Jan 2008 03:14:31 -0000 Subject: [issue1960] test_gdbm.py converted to unittest In-Reply-To: <1201573218.16.0.448704306744.issue1960@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Jan 28, 2008 6:20 PM, Giampaolo Rodola' wrote: > > Giampaolo Rodola' added the comment: > > > Well, if you have an opinion, feel free to leave a comment in this > > issue about it. I will most likely be the one who does the checkin and > > I will read this issue before I commit. > > * One of the things I dislike is the fact that the student used "self.g > = gdbm.open(self.filename, 'c')" in setUp method since if that fails > there will be a NameError exception raised in tearDown method and the > errors reported by unittest would be 2 where in fact it would be only 1. > Probably a thing like this one would have been better: > > def setUp(self): > self.g = None > > def tearDown(self): > if self.g is not None: > self.g.close() > ... > > def test_it(self): > self.g = gdbm.open(self.filename, 'c') > ... > Could also still open perform the open() call in setUp() and do what you need in the tearDown() to not be an error. There should probably also be a way to not cause an error if the file path is just not writable as that is not a sign of a failing test but an unavailable resource. > - Another thing I don't like is that os.unlink(self.filename) executed > in tearDown would be better if protected by a try/except statement. > Even better is test.test_support.unlink() which handles those details for you. > - +1 for the self.g.close() used by the student in the tearDown method. > That was a thing I haven't considered and it's not included in my patch. > > - +0.5 for the "test_modes" method added by the student. Maybe it's > useful, maybe it's not, I don't know. > > > Aside from that I don't see other relevant differences since the code is > really minimalistic. Feel free to commit the patch you consider to be > the best. > If you want me to do so I can provide a merged version of my patch > including the differences I described above. Fine by me. Or you can wait until I have time to look at your code. It's up to you. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 07:34:24 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 29 Jan 2008 06:34:24 -0000 Subject: [issue1954] SocketServer.ForkingMixIn creates a zombie In-Reply-To: <1201499479.46.0.649764617185.issue1954@psf.upfronthosting.co.za> Message-ID: <1201588464.55.0.795049011558.issue1954@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Well, one child isn't the maximum. All children which do not finish before the last client connects, will live on as zombies (and will be collected when the next client connects). If that is acceptable, then just close this report. Using signals would be easier if http://bugs.python.org/issue1089358 goes in. But even then a single accept call might not suffice and the code might need to select on the listening socket and another filedescriptor (on which the signal handler writes). The simplest solution might be to use select with a timeout and check for dead children periodically. (and sorry for not filling out the complete form.) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 09:59:42 2008 From: report at bugs.python.org (mattbaas) Date: Tue, 29 Jan 2008 08:59:42 -0000 Subject: [issue1962] ctypes feature request: Automatic type conversion of input arguments to C functions In-Reply-To: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za> Message-ID: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za> New submission from mattbaas: This is rather a feature request instead of a bug report. Below is the mail I posted to the ctypes-users mailing list. In short: When ctypes checks input argument types using the "argtypes" attribute, it would be useful if it would try to convert the input value automatically if it isn't already an appropriate ctypes type (but a "compatible" Python type). Here is the full mail with some examples: I'm wrapping a couple of C functions from a DLL and I'm using the argtypes attribute to declare the types of the input arguments. I can call the functions just fine, but I was wondering why I have to provide the exact ctypes type as input when using more complex types such as arrays or callbacks (whereas Python floats are automatically converted). Here is an example code snippet (I was using Python 2.5 on WinXP). The library ri.dll contains the functions RiColor() which takes an array of 3 floats as input and a function RiErrorHandler() which takes a pointer to a function as input: # Create the required types... RtColor = 3*c_float RtErrorHandler = CFUNCTYPE(None, c_int, c_int, c_char_p) # Load the library and declare the input arguments... ri = cdll.LoadLibrary("ri.dll") ri.RiColor.argtypes = [RtColor] ri.RiErrorHandler.argtypes = [RtErrorHandler] Now I can call the color function like this: ri.RiColor(RtColor(1,0,0)) But sometimes it would be more convenient to work with other types like tuples, lists or, in this case, a special vector type (that may come from another module but that behaves like a list of 3 floats). But when I try to pass in just a Python tuple or list I get the following errors: ri.RiColor((1,0,0)) --> ctypes.ArgumentError: argument 1: : Don't know how to convert parameter 1 ri.RiColor([1,0,0]) --> ctypes.ArgumentError: argument 1: : expected c_float_Array_3 instance instead of list Similarly with the error handler function. I have to wrap a Python function with the RtErrorHandler type, otherwise ctypes won't accept it: def errHandler(code, severity, message): pass ri.RiErrorHandler(RtErrorHandler(errHandler)) # works ri.RiErrorHandler(errHandler) # produces a TypeError So whenever an input type doesn't match what was specified in argtypes, couldn't ctypes try to convert the value before issuing an error? (it works with floats, so why not with other types as well?) The conversion could just be done by passing the value to the constructor of the required type. In the color example this also means that array types should also accept sequences as input (i.e. anything that supports iteration and has the right number of elements). I think this modification to ctypes would make the wrapped functions more flexible without having to write additional wrapper functions in Python. ---------- components: Extension Modules messages: 61815 nosy: mattbaas severity: normal status: open title: ctypes feature request: Automatic type conversion of input arguments to C functions type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 12:11:10 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 29 Jan 2008 11:11:10 -0000 Subject: [issue1935] test_descr.py converted to unittest In-Reply-To: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za> Message-ID: <1201605070.16.0.907454427618.issue1935@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: On the contrary, Jeff's version is better in many aspects. I happily withdraw my submission. Just a question: why were the docstrings removed? ---------- resolution: -> duplicate __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 12:51:47 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2008 11:51:47 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201607507.76.0.877326639474.issue1577@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi Raghuram, I'm confused, because I can't reproduce it either. I'm afraid I had drunk too much or too little coffee when typing that. Perhaps the patch's semantics should be reconsidered then... What do you think? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 13:14:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 29 Jan 2008 12:14:47 -0000 Subject: [issue1963] marshal module is leaking references In-Reply-To: <1201608887.67.0.254774790303.issue1963@psf.upfronthosting.co.za> Message-ID: <1201608887.67.0.254774790303.issue1963@psf.upfronthosting.co.za> New submission from Christian Heimes: Hello Raymond! Your changes have introduced a ref leak: test_marshal leaked [32, 32, 32, 32] references, sum=128 ---------- assignee: rhettinger messages: 61818 nosy: rhettinger, tiran priority: high severity: normal status: open title: marshal module is leaking references type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 13:33:34 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Tue, 29 Jan 2008 12:33:34 -0000 Subject: [issue1297193] Search is to long with regex like ^(.+|dontmatch)*$ Message-ID: <1201610014.65.0.212633031846.issue1297193@psf.upfronthosting.co.za> Changes by Georgij Kondratjev: ---------- nosy: +orivej _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 29 13:33:45 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Tue, 29 Jan 2008 12:33:45 -0000 Subject: [issue1946] re.search hangs on this In-Reply-To: <1201449544.57.0.177227713029.issue1946@psf.upfronthosting.co.za> Message-ID: <1201610025.72.0.921793692047.issue1946@psf.upfronthosting.co.za> Changes by Georgij Kondratjev: ---------- nosy: +orivej __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 15:23:14 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 29 Jan 2008 14:23:14 -0000 Subject: [issue1962] ctypes feature request: Automatic type conversion of input arguments to C functions In-Reply-To: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za> Message-ID: <1201616594.18.0.795525015537.issue1962@psf.upfronthosting.co.za> Christian Heimes added the comment: Feature request -> RFE (request for enhancement) ---------- assignee: -> theller nosy: +theller, tiran priority: -> normal type: behavior -> rfe versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 16:11:12 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 29 Jan 2008 15:11:12 -0000 Subject: [issue780024] Makefile.pre.in ignores CPPFLAGS from environment Message-ID: <1201619472.1.0.802583868785.issue780024@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: The latest Makefile.pre.in does have this change (@CPPFLAGS@ is appended). ---------- nosy: +draghuram resolution: -> fixed status: open -> closed versions: +Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Jan 29 17:15:53 2008 From: report at bugs.python.org (Tim Golden) Date: Tue, 29 Jan 2008 16:15:53 -0000 Subject: [issue1964] Slight adjustment to sphinx print-media stylesheet In-Reply-To: <1201623353.06.0.378481748773.issue1964@psf.upfronthosting.co.za> Message-ID: <1201623353.06.0.378481748773.issue1964@psf.upfronthosting.co.za> New submission from Tim Golden: My previous patch to the print stylesheet used by Sphinx was a little overenthusiastic and resulted in the right edge of the text truncating on some printers. This version reverts a part of that and gives a useful result on the printers I've tried. Patch attached against r60407 of Sphinx ---------- components: Documentation tools (Sphinx) files: sphinx-r60407.patch messages: 61821 nosy: tim.golden severity: minor status: open title: Slight adjustment to sphinx print-media stylesheet versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9317/sphinx-r60407.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 18:18:12 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Tue, 29 Jan 2008 17:18:12 -0000 Subject: [issue1685] linecache .updatecache fails on utf8 encoded files In-Reply-To: <1198300635.1.0.891509425639.issue1685@psf.upfronthosting.co.za> Message-ID: <1201627092.71.0.587236943003.issue1685@psf.upfronthosting.co.za> Changes by Georgij Kondratjev: ---------- nosy: +orivej __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 18:21:01 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Tue, 29 Jan 2008 17:21:01 -0000 Subject: [issue1595] Probable extra semicolon in Py_LeaveRecursiveCall macro In-Reply-To: <1197409249.11.0.710274454226.issue1595@psf.upfronthosting.co.za> Message-ID: <1201627261.01.0.367300628857.issue1595@psf.upfronthosting.co.za> Changes by Georgij Kondratjev: ---------- nosy: +orivej __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 18:25:42 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 29 Jan 2008 17:25:42 -0000 Subject: [issue1961] possible error with json format for sphinx In-Reply-To: <1201576005.17.0.220280417702.issue1961@psf.upfronthosting.co.za> Message-ID: <1201627541.95.0.179771946788.issue1961@psf.upfronthosting.co.za> Georg Brandl added the comment: Please run a make clean (or just remove the build/html/searchindex.json file) and this should go away. ---------- nosy: +georg.brandl resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 18:36:41 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 29 Jan 2008 17:36:41 -0000 Subject: [issue1954] SocketServer.ForkingMixIn creates a zombie In-Reply-To: <1201499479.46.0.649764617185.issue1954@psf.upfronthosting.co.za> Message-ID: <1201628201.95.0.605122228889.issue1954@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 18:41:18 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Tue, 29 Jan 2008 17:41:18 -0000 Subject: [issue1391] Adds the .compact() method to bsddb db.DB objects In-Reply-To: <1194227398.84.0.43254190344.issue1391@psf.upfronthosting.co.za> Message-ID: <1201628478.98.0.713833305123.issue1391@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 19:26:47 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 29 Jan 2008 18:26:47 -0000 Subject: [issue1965] Move trunc() to math module In-Reply-To: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za> Message-ID: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za> New submission from Raymond Hettinger: http://mail.python.org/pipermail/python-dev/2008-January/076626.html Also, the docstring doesn't seem correct or clear. ---------- assignee: jyasskin components: Extension Modules messages: 61823 nosy: jyasskin, rhettinger severity: normal status: open title: Move trunc() to math module versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 20:14:09 2008 From: report at bugs.python.org (Mike Klaas) Date: Tue, 29 Jan 2008 19:14:09 -0000 Subject: [issue1966] infinite loop in httplib In-Reply-To: <1201634049.27.0.941407141284.issue1966@psf.upfronthosting.co.za> Message-ID: <1201634049.27.0.941407141284.issue1966@psf.upfronthosting.co.za> New submission from Mike Klaas: There are a small number of sites that do not send the trailing \r\n when using chunked transfer encoding (say 1 in 500,000). This unfortunately, causes httplib to go into an infinite loop. Fixed by checking for EOF (3 line patch) ---------- components: Library (Lib) files: httplib_chunked.patch messages: 61824 nosy: klaas severity: major status: open title: infinite loop in httplib type: behavior versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9318/httplib_chunked.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 20:21:16 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 29 Jan 2008 19:21:16 -0000 Subject: [issue1965] Move trunc() to math module In-Reply-To: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za> Message-ID: <1201634476.11.0.756823931751.issue1965@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin: ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 21:12:54 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 29 Jan 2008 20:12:54 -0000 Subject: [issue1935] test_descr.py converted to unittest In-Reply-To: <1201605070.16.0.907454427618.issue1935@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Jan 29, 2008 3:11 AM, Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc added the comment: > > On the contrary, Jeff's version is better in many aspects. > I happily withdraw my submission. > > Just a question: why were the docstrings removed? Beats me. =) I didn't even notice when I did the initial review. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 21:15:43 2008 From: report at bugs.python.org (Georgij Kondratjev) Date: Tue, 29 Jan 2008 20:15:43 -0000 Subject: [issue1750076] Python 2.5+ skips while statements in debuggers Message-ID: <1201637743.43.0.246527028357.issue1750076@psf.upfronthosting.co.za> Changes by Georgij Kondratjev: ---------- nosy: +orivej _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 29 21:24:25 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 29 Jan 2008 20:24:25 -0000 Subject: [issue1935] test_descr.py converted to unittest In-Reply-To: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za> Message-ID: <1201638265.02.0.358218374589.issue1935@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Did he misunderstand the last comment in this post of yours? http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=291#c24 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 21:42:22 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Tue, 29 Jan 2008 20:42:22 -0000 Subject: [issue1397] py3k-pep3137: failing unit test test_bsddb In-Reply-To: <1194352164.91.0.707733802252.issue1397@psf.upfronthosting.co.za> Message-ID: <1201639342.89.0.733286229113.issue1397@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 21:52:25 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 29 Jan 2008 20:52:25 -0000 Subject: [issue1935] test_descr.py converted to unittest In-Reply-To: <1201638265.02.0.358218374589.issue1935@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Jan 29, 2008 12:24 PM, Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc added the comment: > > Did he misunderstand the last comment in this post of yours? > http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=291#c24 Ah, I see what you mean. So docstrings are not used in testing methods because unittest outputs those as the name of the test and they are not always useful. The convention is to make them comments instead and let the method test name be what unittest outputs. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 21:53:22 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 29 Jan 2008 20:53:22 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201640002.66.0.481455287869.issue1577@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: We are back to square 1 :-). Your patch incorporates Facundo's suggestion which is 'rename(src_file, dst_dir/`basename src_file`). It is not clear to me from rereading the earlier comments whether Guido rejected this approach or not. I would personally prefer this approach. If this change is not going to be considered, we will be left with making a doc change; something to the effect: "If the destination is a file and is on same file system as that of src, then simply use rename." An additional doc change will be needed to correct the statement "If dst is a directory, OSError will be raised". As you found out, this is not entirely true on Linux and perhaps on other versions of unix. I don't think any other changes are needed. I did not go through the test cases in the patch but I think we can certainly use some of them even if no code change is done. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 22:07:32 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2008 21:07:32 -0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1201640852.38.0.291241456489.issue1577@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By the way, if we really wanted to be complete in the unit tests, we should also test the case where either src or dst is a symlink to a directory. But it's still much better than originally - there was hardly any unit test for shutil.move(). __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 22:10:03 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 29 Jan 2008 21:10:03 -0000 Subject: [issue606733] Docstring formatter. Message-ID: <1201641003.83.0.870099667212.issue606733@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: ---------- resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Jan 29 22:35:31 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Tue, 29 Jan 2008 21:35:31 -0000 Subject: [issue1391] Adds the .compact() method to bsddb db.DB objects In-Reply-To: <1194227398.84.0.43254190344.issue1391@psf.upfronthosting.co.za> Message-ID: <1201642531.83.0.160581703197.issue1391@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I can reproduce the crash from a pure C program, so this library seems buggy. Posting a report in http://forums.oracle.com/forums/thread.jspa?threadID=611821 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 22:48:31 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 29 Jan 2008 21:48:31 -0000 Subject: [issue1750076] Python 2.5+ skips while statements in debuggers Message-ID: <1201643311.71.0.882665505575.issue1750076@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Here is an attempt to correct the problem, with unit tests. I removed half of the trick marked by a "XXX(nnorwitz)", by adding an attribute to "struct instr" (this attribute is a bitfield and does not increase the memory usage). FOR_ITER is no more special-cased in assemble_lnotab. Note that the attribute is not always set: only when the target block has already been filled with instructions. Hopefully this is the case for the beginning of loops (while & for). Then the second part of the trick (c->u->u_lineno_set = false, already used in compiler_for) can be applied to compiler_while. Don't know how to write this better. Nir's examples now correctly generate the 3 offsets, and the unit test checks that a "line" event is repeatedly emitted for the "while" condition. ---------- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file9319/while_lnotab.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Jan 29 22:54:44 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2008 21:54:44 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201643684.66.0.926608411745.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FWIW, I tried using the freelist scheme introduced in my patch without making PyUnicode a PyVarObject and, although it's better than the standard version, it's still not as good as the PyVarObject version. Would you be interested in that patch? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 23:03:39 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 29 Jan 2008 22:03:39 -0000 Subject: [issue400622] Just a test Message-ID: <1201644219.15.0.51310274394.issue400622@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This message links to msg32826 ---------- nosy: +loewis ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Jan 29 23:39:05 2008 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 29 Jan 2008 22:39:05 -0000 Subject: [issue1967] Backport dictviews to 2.6 In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za> Message-ID: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za> New submission from Thomas Wouters: Patch to backport dictviews to trunk. Consists of some trickery: - new 'viewkeys', 'viewvalues' and 'viewitems' methods of dicts, returning exactly what 'keys', 'values' and 'items' return in 3.0: three new types defined in dictobject.c - a future import (dictviews) that changes which opcodes are generated for (some) attribute access - special opcodes for getting and setting 'keys', 'values' and 'items' attributes from an object. These opcodes do nothing special unless a future import is in effect in the calling code block *and* the type they are called on is a dict subclass, in which case they translate 'keys', 'values' and 'items' to 'viewkeys', 'viewvalues' and 'viewitems'. - similar specialcasing in getattr() and setattr() ---------- components: Interpreter Core files: dictviews_backport.diff keywords: patch messages: 61834 nosy: twouters severity: normal status: open title: Backport dictviews to 2.6 versions: Python 2.6 Added file: http://bugs.python.org/file9320/dictviews_backport.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Jan 29 23:55:50 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 29 Jan 2008 22:55:50 -0000 Subject: [issue1968] Unused number magic methods leaked into Py2.6 In-Reply-To: <1201647350.7.0.0255165658093.issue1968@psf.upfronthosting.co.za> Message-ID: <1201647350.7.0.0255165658093.issue1968@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The Py2.6 code has __round__, __ceil__, and __floor__ methods still in several objects (int, longs, float, Rational) but they are not invoked by anything. For example, round(Rational(22,7)) does not use the Rational.__round__ code and round(22) does not use the code for int.__round__; the code is just ignored. Since the code is not used, it probably shouldn't be in Py2.6. I think these backports happened before Guido decided, "I think the pre-3.0 rule should be: round(), math.floor(), math.ceil() *always* return a float." Probably, rev 59731 may have intended to revert these changes but just missed them. IIRC, the decision was that only __trunc__ would be backported and the other three magic methods would wait for Py3.0 where their invocation functions would get their new signature and start calling the magic methods. ---------- assignee: jyasskin messages: 61835 nosy: jyasskin, rhettinger severity: normal status: open title: Unused number magic methods leaked into Py2.6 versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 00:53:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2008 23:53:35 -0000 Subject: [issue1969] split and rsplit in bytearray are inconsistent In-Reply-To: <1201650815.76.0.106888653852.issue1969@psf.upfronthosting.co.za> Message-ID: <1201650815.76.0.106888653852.issue1969@psf.upfronthosting.co.za> New submission from Antoine Pitrou: In the bytearray type, the split and rsplit methods use a different definition of what is a whitespace character. split_whitespace calls ISSPACE(), while rsplit_whitespace calls Py_UNICODE_ISSPACE(). The latter is probably an error since it is also inconsistent with behaviour of the bytes type: >>> s = b"\x09\x0A\x0B\x0C\x0D\x1C\x1D\x1E\x1F" >>> s.split() [b'\x1c\x1d\x1e\x1f'] >>> s.rsplit() [b'\x1c\x1d\x1e\x1f'] >>> b = bytearray(s) >>> b.split() [bytearray(b'\x1c\x1d\x1e\x1f')] >>> b.rsplit() [] ---------- components: Interpreter Core messages: 61836 nosy: pitrou severity: normal status: open title: split and rsplit in bytearray are inconsistent type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 01:44:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2008 00:44:35 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> Message-ID: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Currently the PyUnicode type uses a function call and several lookups per character to detect whitespace and linebreaks. This slows down considerably the split(), rsplit() and splitlines() methods. Since the overwhelming majority of whitespace and linebreaks are ASCII characters, it makes sense to have a fast lookup table for the common case. Patch attached (also with another tiny change which helps compiler optimization of split/rsplit here). (this may also help other methods like strip() a bit, but in that case the impact of whitespace detection is probably negligible) Some numbers: # With patch $ ./python -m timeit -s "s=open('LICENSE', 'r').read()" "s.splitlines()" 10000 loops, best of 3: 127 usec per loop $ ./python -m timeit -s "s=open('LICENSE', 'r').read()" "s.split()" 1000 loops, best of 3: 457 usec per loop # Without patch $ ./python-orig -m timeit -s "s=open('LICENSE', 'r').read()" "s.splitlines()" 10000 loops, best of 3: 175 usec per loop $ ./python-orig -m timeit -s "s=open('LICENSE', 'r').read()" "s.split()" 1000 loops, best of 3: 571 usec per loop ---------- components: Interpreter Core files: unispace.patch messages: 61837 nosy: pitrou severity: normal status: open title: Speedup unicode whitespace and linebreak detection versions: Python 3.0 Added file: http://bugs.python.org/file9321/unispace.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 02:26:28 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 30 Jan 2008 01:26:28 -0000 Subject: [issue1969] split and rsplit in bytearray are inconsistent In-Reply-To: <1201650815.76.0.106888653852.issue1969@psf.upfronthosting.co.za> Message-ID: <1201656388.78.0.0498849055095.issue1969@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yeah, that looks like a bug. ---------- keywords: +easy nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 03:51:34 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 30 Jan 2008 02:51:34 -0000 Subject: [issue1960] test_gdbm.py converted to unittest In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za> Message-ID: <1201661494.3.0.0986099948243.issue1960@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Updated version in attachment. Changes: - Added "if self.g is not None: self.g.close()" clause in tearDown. - Used "test.test_support.unlink(filename)" instead of the try/except statement. - Added tests for the flag clause in the open() statement by trying all supported mode flags. I also called the method "test_flags" instead of "test_modes" since "mode" is a kwarg for open(). - Added tests for trying to open non existing database with flag == 'r' and 'w'. Untested methods which are now tested: - keys(). - firstkey(). - nextkey(). - reorganize() The only method currently not tested yet is sync(). I'm not sure how to test it, maybe I'm misunderstanding its purpose. Added file: http://bugs.python.org/file9322/test_gdbm.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 03:52:02 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 30 Jan 2008 02:52:02 -0000 Subject: [issue1960] test_gdbm.py converted to unittest In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za> Message-ID: <1201661522.8.0.433843135317.issue1960@psf.upfronthosting.co.za> Changes by Giampaolo Rodola': Added file: http://bugs.python.org/file9323/test_gdbm.py __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 04:31:35 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 30 Jan 2008 03:31:35 -0000 Subject: [issue1948] Cant open python gui using VISTA In-Reply-To: <1201462739.88.0.734539859059.issue1948@psf.upfronthosting.co.za> Message-ID: <1201663895.95.0.279534583187.issue1948@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Make explorer show all hidden files, then don't search for it, but directly navigate to .idlerc; note the leading dot. Please understand that this tracker is not a means you to request help, but for you to provide help, by reporting bugs. If you seek help, use python-list at python.org (aka news:comp.lang.python) instead, or python-help at python.org or python-tutor at python.org. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 05:44:24 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Wed, 30 Jan 2008 04:44:24 -0000 Subject: [issue1968] Unused number magic methods leaked into Py2.6 In-Reply-To: <1201647350.7.0.0255165658093.issue1968@psf.upfronthosting.co.za> Message-ID: <1201668264.64.0.29683697488.issue1968@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I can't find the __round__, __ceil__, and __floor__ methods in int, long, and float. I left them in Rational on purpose, thinking that there might be a module that provided the new behaviors for 2.6 code, but you're probably right that these should be rolled back until such a module appears. They do have the benefit of demonstrating that it's possible to write a numeric class that does the right thing in both 2.6 and 3.0 without many code changes. (I should check that 2to3 does the right thing on it.) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 06:19:53 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 30 Jan 2008 05:19:53 -0000 Subject: [issue1968] Unused number magic methods leaked into Py2.6 In-Reply-To: <1201647350.7.0.0255165658093.issue1968@psf.upfronthosting.co.za> Message-ID: <1201670393.08.0.808553285142.issue1968@psf.upfronthosting.co.za> Raymond Hettinger added the comment: For 2.6, they should be omitted from rational.py. The code that is there is not the code that is run -- that impairs its value as a demo module. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 06:24:38 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Wed, 30 Jan 2008 05:24:38 -0000 Subject: [issue1968] Unused number magic methods leaked into Py2.6 In-Reply-To: <1201647350.7.0.0255165658093.issue1968@psf.upfronthosting.co.za> Message-ID: <1201670678.49.0.266969135711.issue1968@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Will do. ---------- components: +Library (Lib) resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 09:15:53 2008 From: report at bugs.python.org (Thomas Heller) Date: Wed, 30 Jan 2008 08:15:53 -0000 Subject: [issue1971] ctypes exposing the pep 3118 buffer interface In-Reply-To: <1201680953.7.0.68287385548.issue1971@psf.upfronthosting.co.za> Message-ID: <1201680953.7.0.68287385548.issue1971@psf.upfronthosting.co.za> New submission from Thomas Heller: The attached patch against py3k makes ctypes expose the pep 3118 buffer interface. The code is also available in the py3k-ctypes-pep3118 branch. ---------- components: Extension Modules files: ctypes-pep3118.patch keywords: patch messages: 61844 nosy: theller priority: urgent severity: normal status: open title: ctypes exposing the pep 3118 buffer interface type: rfe versions: Python 3.0 Added file: http://bugs.python.org/file9324/ctypes-pep3118.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 10:41:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 09:41:34 -0000 Subject: [issue1953] Compact int and float freelists In-Reply-To: <1201491269.72.0.799398122167.issue1953@psf.upfronthosting.co.za> Message-ID: <1201686094.13.0.766113066614.issue1953@psf.upfronthosting.co.za> Christian Heimes added the comment: I've moved the methods back to the sys module and added API docs for the C and Python code. ---------- title: gc.compact_freelists -> Compact int and float freelists Added file: http://bugs.python.org/file9325/trunk_compact_freelist2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 10:43:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 09:43:21 -0000 Subject: [issue1968] Unused number magic methods leaked into Py2.6 In-Reply-To: <1201647350.7.0.0255165658093.issue1968@psf.upfronthosting.co.za> Message-ID: <1201686201.57.0.968314707007.issue1968@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> high type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 10:52:15 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 09:52:15 -0000 Subject: [issue1969] split and rsplit in bytearray are inconsistent In-Reply-To: <1201650815.76.0.106888653852.issue1969@psf.upfronthosting.co.za> Message-ID: <1201686735.29.0.784362977471.issue1969@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r60437 with unit test. Thanks for the report! ---------- nosy: +tiran resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 10:53:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 09:53:26 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> Message-ID: <1201686806.95.0.628600127518.issue1970@psf.upfronthosting.co.za> Christian Heimes added the comment: Sounds interesting and good! ---------- keywords: +patch nosy: +tiran priority: -> normal type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 10:54:11 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 09:54:11 -0000 Subject: [issue1967] Backport dictviews to 2.6 In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za> Message-ID: <1201686851.82.0.757004869836.issue1967@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 10:54:34 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 09:54:34 -0000 Subject: [issue1391] Adds the .compact() method to bsddb db.DB objects In-Reply-To: <1194227398.84.0.43254190344.issue1391@psf.upfronthosting.co.za> Message-ID: <1201686874.05.0.027826994873.issue1391@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 10:55:01 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 09:55:01 -0000 Subject: [issue1965] Move trunc() to math module In-Reply-To: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za> Message-ID: <1201686901.83.0.890327162794.issue1965@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 10:56:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 09:56:10 -0000 Subject: [issue1966] infinite loop in httplib In-Reply-To: <1201634049.27.0.941407141284.issue1966@psf.upfronthosting.co.za> Message-ID: <1201686970.51.0.690428231365.issue1966@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm not sure if the patch can get into 2.3 and 2.4. It's up to Martin to decide. ---------- assignee: -> loewis keywords: +easy, patch nosy: +loewis, tiran priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 10:58:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 09:58:05 -0000 Subject: [issue1685] linecache .updatecache fails on utf8 encoded files In-Reply-To: <1198300635.1.0.891509425639.issue1685@psf.upfronthosting.co.za> Message-ID: <1201687085.86.0.625312051452.issue1685@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +easy, patch priority: -> high type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 10:58:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 09:58:31 -0000 Subject: [issue1964] Slight adjustment to sphinx print-media stylesheet In-Reply-To: <1201623353.06.0.378481748773.issue1964@psf.upfronthosting.co.za> Message-ID: <1201687111.26.0.659680192319.issue1964@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl keywords: +patch nosy: +georg.brandl priority: -> normal type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 11:09:39 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 30 Jan 2008 10:09:39 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> Message-ID: <1201687779.49.0.662080848843.issue1970@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Nice patch ! ---------- nosy: +lemburg __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 11:10:03 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 30 Jan 2008 10:10:03 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> Message-ID: <1201687803.07.0.76420446974.issue1970@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: This should also be backported to Py2.6. ---------- versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 11:24:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 10:24:47 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> Message-ID: <1201688687.02.0.0129698391241.issue1970@psf.upfronthosting.co.za> Christian Heimes added the comment: I agree! The new patch applies cleanly to the trunk. I've fixed some white spaces and renamed the tables to _Py_ascii_.... Added file: http://bugs.python.org/file9326/trunk_unispace.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 11:25:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 10:25:39 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> Message-ID: <1201688739.73.0.139209228036.issue1970@psf.upfronthosting.co.za> Christian Heimes added the comment: Sorry, this patch doesn't contain my current work. Added file: http://bugs.python.org/file9327/trunk_unispace.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 11:25:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 10:25:44 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> Message-ID: <1201688744.96.0.0724540272175.issue1970@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file9326/trunk_unispace.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 11:42:59 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 30 Jan 2008 10:42:59 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> Message-ID: <1201689779.76.0.233233107714.issue1970@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Please make those stables static... In general, everything that's not needed outside an object file should be made static to avoid naming conflicts. For static symbols, there's no need to prefix them with any "Py" indicator. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 11:58:04 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2008 10:58:04 -0000 Subject: [issue1972] improve bytes and bytearray tests In-Reply-To: <1201690684.03.0.553815304341.issue1972@psf.upfronthosting.co.za> Message-ID: <1201690684.03.0.553815304341.issue1972@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Currently some tests in test_bytes.py only test bytearray, others only test bytes. Here is a patch to try to make test coverage more extensive. You'll notice there is a small hack in test_fromhex, that's because bytes.fromhex is buggy, I'll open a separate bug entry for that. ---------- components: Tests files: bytestest.patch messages: 61854 nosy: pitrou severity: normal status: open title: improve bytes and bytearray tests versions: Python 3.0 Added file: http://bugs.python.org/file9328/bytestest.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 11:59:43 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2008 10:59:43 -0000 Subject: [issue1973] bytes.fromhex('') raises SystemError In-Reply-To: <1201690783.64.0.509716401018.issue1973@psf.upfronthosting.co.za> Message-ID: <1201690783.64.0.509716401018.issue1973@psf.upfronthosting.co.za> New submission from Antoine Pitrou: >>> bytearray.fromhex('') bytearray(b'') >>> bytes.fromhex('') Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:3131: bad argument to internal function ---------- components: Interpreter Core messages: 61855 nosy: pitrou severity: normal status: open title: bytes.fromhex('') raises SystemError versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:07:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 11:07:03 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201689779.76.0.233233107714.issue1970@psf.upfronthosting.co.za> Message-ID: <47A05A54.4050409@cheimes.de> Christian Heimes added the comment: > Please make those stables static... > > In general, everything that's not needed outside an object file should > be made static to avoid naming conflicts. For static symbols, there's no > need to prefix them with any "Py" indicator. The ascii whitespace table is required for Py_UNICODE_ISSPACE. I can make the linebreak table static but I can't make the whitespace table static. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:09:50 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 30 Jan 2008 11:09:50 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> Message-ID: <1201691390.51.0.258383769976.issue1970@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Ok, thanks. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:13:34 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2008 11:13:34 -0000 Subject: [issue1973] bytes.fromhex('') raises SystemError In-Reply-To: <1201690783.64.0.509716401018.issue1973@psf.upfronthosting.co.za> Message-ID: <1201691614.57.0.803249110772.issue1973@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. Unittest should be covered by removing the test_bytes workaround mentioned in #1972 :) Added file: http://bugs.python.org/file9329/fromhex.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:26:26 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 11:26:26 -0000 Subject: [issue1972] improve bytes and bytearray tests In-Reply-To: <1201690684.03.0.553815304341.issue1972@psf.upfronthosting.co.za> Message-ID: <1201692386.28.0.898944962037.issue1972@psf.upfronthosting.co.za> Christian Heimes added the comment: Good idea but could you please use typ2test instead of a decorator? It involves too much magic. ---------- keywords: +patch nosy: +tiran priority: -> normal resolution: -> accepted type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:28:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 11:28:53 -0000 Subject: [issue1973] bytes.fromhex('') raises SystemError In-Reply-To: <1201690783.64.0.509716401018.issue1973@psf.upfronthosting.co.za> Message-ID: <1201692533.5.0.0270963010064.issue1973@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks! :) Fixed in r60439 ---------- keywords: +patch nosy: +tiran priority: -> normal resolution: -> fixed status: open -> closed type: -> crash __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:33:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 11:33:27 -0000 Subject: [issue1970] Speedup unicode whitespace and linebreak detection In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za> Message-ID: <1201692807.25.0.0247737014293.issue1970@psf.upfronthosting.co.za> Christian Heimes added the comment: I've applied the patch to the trunk in r60440. It will be merged into 3.0 soonish. Thanks for your work Keep it going! :) ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:45:16 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 30 Jan 2008 11:45:16 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201693516.03.0.728665866406.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Yes, definitely. Some comments on style in your first patch: * please use unicode->length instead of the macro LENGTH you added * indents in unicodeobject.c are 4 spaces * line length should stay below 80 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:47:09 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2008 11:47:09 -0000 Subject: [issue1972] improve bytes and bytearray tests In-Reply-To: <1201690684.03.0.553815304341.issue1972@psf.upfronthosting.co.za> Message-ID: <1201693629.2.0.427328969274.issue1972@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, here is a patch using type2test instead :) Added file: http://bugs.python.org/file9330/bytestest.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:48:51 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2008 11:48:51 -0000 Subject: [issue1972] improve bytes and bytearray tests In-Reply-To: <1201690684.03.0.553815304341.issue1972@psf.upfronthosting.co.za> Message-ID: <1201693731.22.0.180741642211.issue1972@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm, that "import functools" at top of the file certainly can be removed... __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:57:52 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2008 11:57:52 -0000 Subject: [issue1972] improve bytes and bytearray tests In-Reply-To: <1201690684.03.0.553815304341.issue1972@psf.upfronthosting.co.za> Message-ID: <1201694272.06.0.717279061415.issue1972@psf.upfronthosting.co.za> Changes by Antoine Pitrou: Added file: http://bugs.python.org/file9331/bytestest.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 12:59:09 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 11:59:09 -0000 Subject: [issue1972] improve bytes and bytearray tests In-Reply-To: <1201690684.03.0.553815304341.issue1972@psf.upfronthosting.co.za> Message-ID: <1201694349.82.0.963453568373.issue1972@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks again! Applied in r60442 ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 15:48:05 2008 From: report at bugs.python.org (Chris Withers) Date: Wed, 30 Jan 2008 14:48:05 -0000 Subject: [issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header In-Reply-To: <1201704485.29.0.575687789495.issue1974@psf.upfronthosting.co.za> Message-ID: <1201704485.29.0.575687789495.issue1974@psf.upfronthosting.co.za> New submission from Chris Withers: Somewhere in email.MIMEText.MIMEText.as_string (I'm not sure where) long subject headers are folded using a newline followed by a tab: >>> from email.MIMEText import MIMEText >>> m = MIMEText('foo') >>> m['Subject']='AA '*40 >>> m.as_string() 'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transfer-Encoding: 7bit\nSubject: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA\n\tAA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA \n\nfoo' While RFC 822 section 3.1.1 doesn't forbid this type of folding, the current behaviour mis-renders in both Thunderbird and Outlook. Messages generated by Thunderbird and Outlook represent the above subject as follows: 'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transfer-Encoding: 7bit\nSubject: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA\n AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA \n\nfoo' Could the email library be adjusted to do the same? Years of wondering why mails re-sent by mailman, mails from any number of python web systems and recent complaints from customers of mine of mis-rendered emails could be solved by doing so. ---------- components: Library (Lib) messages: 61866 nosy: cjw296 severity: normal status: open title: email.MIMEText.MIMEText.as_string incorrectly folding long subject header versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 16:40:24 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 30 Jan 2008 15:40:24 -0000 Subject: [issue1745035] DoS smtpd vulnerability Message-ID: <1201707624.82.0.182412417907.issue1745035@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Jan 30 16:56:30 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2008 15:56:30 -0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1201708590.52.0.31377885644.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: After some more tests I must qualify what I said. The freelist patch is an improvement in some situations. In others it does not really have any impact. On the other hand, the PyVarObject version handles memory-bound cases dramatically better, see below. With a small string: ./python -m timeit -s "s=open('INTBENCH', 'r').read()" "s.split()" -> Unpatched py3k: 26.4 usec per loop -> Freelist patch: 21.5 usec per loop -> PyVarObject patch: 20.2 usec per loop With a medium-sized string: ./python -m timeit -s "s=open('LICENSE', 'r').read()" "s.split()" -> Unpatched py3k: 458 usec per loop -> Freelist patch: 408 usec per loop -> PyVarObject patch: 316 usec per loop With a long string: ./python -m timeit -s "s=open('Misc/HISTORY', 'r').read()" "s.split()" -> Unpatched py3k: 31.3 msec per loop -> Freelist patch: 32.7 msec per loop -> PyVarObject patch: 17.8 msec per loop (the numbers are better than in my previous posts because the split-accelerating patch has been integrated) Also, given those results, it is also clear that neither pybench nor stringbench really stress memory efficiency of strings, only processing algorithms. That said, the freelist patch is attached. Added file: http://bugs.python.org/file9332/freelists.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 17:12:15 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 30 Jan 2008 16:12:15 -0000 Subject: [issue600362] relocate cgi.parse_qs() into urlparse Message-ID: <1201709535.48.0.35804565495.issue600362@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I know that Senthil has been working on consolidating url related functionalities so I am adding him to the list. ---------- nosy: +draghuram, orsenthil versions: +Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Jan 30 17:17:03 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 30 Jan 2008 16:17:03 -0000 Subject: [issue756914] SSL support for poplib Message-ID: <1201709823.85.0.477359816492.issue756914@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: no activity. Please do reopen if the offer still stands. ---------- nosy: +draghuram resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Jan 30 17:38:06 2008 From: report at bugs.python.org (Andriy Pylypenko) Date: Wed, 30 Jan 2008 16:38:06 -0000 Subject: [issue1975] signals in thread problem In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za> Message-ID: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za> New submission from Andriy Pylypenko: Hello, This issue is actually a follow up of issue 960406. The patch applied there brought in a problem at least under FreeBSD. The problem is extremely annoying so I made an effort to uncover the source of it. Here is an example code that shows the problem: some_time = 6000000 # seconds class MyThread(Thread): def run(self): while (True): time.sleep(some_time) t = MyThread() t.start() while(True): select.select(None, None, None, some_time) Start this script, then try to interrupt it by hitting Control-C. If you run this code under Linux you won't see any problem. But under FreeBSD the script won't stop until the timeout in main thread occurs or some activity takes place on descriptors passed to the select(). My investigation showed that the source of the problem is in that how signals are processed. FreeBSD processes signals in opposite order than Linux. For example suppose we have a program that starts one user thread and allows both main and user threads to receive signals. Under Linux the signal handler always fires up in context of the main thread, but under FreeBSD the signal handler runs in context of the user thread. POSIX doesn't state which behavior is correct so both behaviors should be assumed to be correct and Python should be aware of them both. Before the patch from 960406 the Python made effort to deny signal handling in user threads but the patch dropped this code and all threads are allowed to handle signals. Let's return to the script. When running the script under Linux the select() call is the one that gets interrupted by the signal and this allows the script to shutdown quickly. But under FreeBSD the sleep() call is interrupted by the signal leaving the main thread to wait on select() until timeout. The description of issue 960406 states: "This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it." And yes it behaves exactly as described but this behavior is inconsistent between different OSes. To make things predictable I've restored the code that ensures that signal handler will run in context of main thread only: long PyThread_start_new_thread(void (*func)(void *), void *arg) { ... + sigset_t set, oset; ... + sigfillset(&set); + SET_THREAD_SIGMASK(SIG_BLOCK, &set, &oset); pthread_create(...) + SET_THREAD_SIGMASK(SIG_SETMASK, &oset, NULL); ... and this works perfectly for me under FreeBSD and Linux at least for my needs. It doesn't bring any visible changes to readline behavior either. I'm using the 2.5.1 version of Python. In attach you can find this patch against the trunk. I'm not Python guru but let me try to display my vision of the situation. As I understand, my change does nothing for applications written in pure Python and running under Linux (without user modules written in C and using special thread and signal handling). Signals under Linux have absolutely no chance to be caught from within user threads as Python doesn't provide any way to alter the signal mask and with the default signal mask the signals always arrive to the main thread. So explicit prohibition to handle signals from within user thread doesn't change anything. On the other hand this change ensures that under FreeBSD things go exactly like under Linux. Of course this change can possibly break some C-written module that relies on signal handling in context of user thread (as the signal mask of the user thread must be modified explicitly now). But anyway this is how things are meant to work in order to be portable. So I'm considering this possibility as highly unlikely. I suppose the Mac OS X is affected also as it's based on FreeBSD. ---------- components: Interpreter Core files: pthread_sig.diff messages: 61870 nosy: bamby severity: normal status: open title: signals in thread problem type: behavior versions: Python 2.4, Python 2.5 Added file: http://bugs.python.org/file9333/pthread_sig.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 17:44:48 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 30 Jan 2008 16:44:48 -0000 Subject: [issue1966] infinite loop in httplib In-Reply-To: <1201634049.27.0.941407141284.issue1966@psf.upfronthosting.co.za> Message-ID: <1201711488.17.0.0671983912525.issue1966@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 17:48:27 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 30 Jan 2008 16:48:27 -0000 Subject: [issue1976] pybsddb leak in using cursors In-Reply-To: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za> Message-ID: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za> New submission from Jes?s Cea Avi?n: Iterating a cursor over a database seems to leak memory. See http://sourceforge.net/mailarchive/forum.php?thread_name=4797B7D0.8060701%40gmail.com&forum_name=pybsddb-users ---------- components: Extension Modules messages: 61871 nosy: jcea severity: normal status: open title: pybsddb leak in using cursors __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 17:48:47 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 30 Jan 2008 16:48:47 -0000 Subject: [issue1976] pybsddb leak in using cursors In-Reply-To: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za> Message-ID: <1201711727.05.0.666801109995.issue1976@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- severity: normal -> major type: -> resource usage __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 17:50:29 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 30 Jan 2008 16:50:29 -0000 Subject: [issue799104] CPPFLAGS should not be aded to ldshard command Message-ID: <1201711829.03.0.440299408355.issue799104@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: For the record, the latest Lib/distutils/sysconfig.py still seems to have this behaviour (please correct me if I am wrong). I am closing this as there is no activity for quite some time. ---------- nosy: +draghuram resolution: -> wont fix status: open -> closed type: -> behavior versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Jan 30 20:10:44 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 19:10:44 -0000 Subject: [issue1977] Python reinitialization test In-Reply-To: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za> Message-ID: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch adds a new test and a new executable. The executable calls Py_Initialze() and Py_Finalize() multiple times in a row. The test also shows that Python looses about 35 references in each round. $ ./test_reinit round 1 [7751 refs] round 2 [7797 refs] round 3 [7834 refs] round 4 [7871 refs] round 5 [7908 refs] round 6 [7945 refs] round 7 [7982 refs] round 8 [8019 refs] round 9 [8056 refs] round 10 [8093 refs] ---------- components: Build, Interpreter Core files: test_reinit.patch keywords: patch messages: 61873 nosy: tiran priority: normal severity: normal status: open title: Python reinitialization test type: rfe versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9334/test_reinit.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 20:13:10 2008 From: report at bugs.python.org (Mike Klaas) Date: Wed, 30 Jan 2008 19:13:10 -0000 Subject: [issue1966] infinite loop in httplib In-Reply-To: <1201634049.27.0.941407141284.issue1966@psf.upfronthosting.co.za> Message-ID: <1201720390.1.0.733070221893.issue1966@psf.upfronthosting.co.za> Mike Klaas added the comment: I wouldn't advocate that it go in to 2.3/2.4. The only security issue is a possible DoS, but I think that is unlikely. There is already an "attack vector" for python code using (timeout-less) httplib by simply returning the response very slowly (1byte/sec). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 20:35:09 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 30 Jan 2008 19:35:09 -0000 Subject: [issue1966] infinite loop in httplib In-Reply-To: <1201634049.27.0.941407141284.issue1966@psf.upfronthosting.co.za> Message-ID: <1201721709.69.0.618040931319.issue1966@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- versions: -Python 2.3, Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 20:45:17 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 30 Jan 2008 19:45:17 -0000 Subject: [issue1977] Python reinitialization test In-Reply-To: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za> Message-ID: <1201722316.96.0.926551024202.issue1977@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm not sure what the purpose of this test is. When would it pass, when would it fail? I don't think it is a bug if a Py_Initialize()/Py_Finalize() cycle loses references. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 21:07:50 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 20:07:50 -0000 Subject: [issue1977] Python reinitialization test In-Reply-To: <1201722316.96.0.926551024202.issue1977@psf.upfronthosting.co.za> Message-ID: <47A0D914.9030904@cheimes.de> Christian Heimes added the comment: Martin v. L?wis wrote: > Martin v. L?wis added the comment: > > I'm not sure what the purpose of this test is. When would it pass, when > would it fail? I don't think it is a bug if a > Py_Initialize()/Py_Finalize() cycle loses references. Today my attempts to fix some reference leaks related to sys.flags and sys.float_info caused the test to fail. A single init/final cycle worked but the second cycle broke. The test also shows an issue in Python 3.0. The double linked reference list is broken: $ ./test_reinit round 1 [24676 refs] round 2 [25588 refs] round 3 * ob object : type : str refcount: 0 address : 0x82248e8 * op->_ob_prev->_ob_next object : type : str refcount: 0 address : 0x82248e8 * op->_ob_next->_ob_prev object : bytearray(b'') type : bytearray refcount: 1 address : 0x839ab98 Fatal Python error: UNREF invalid object Aborted (core dumped) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 21:15:46 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 30 Jan 2008 20:15:46 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1201724146.7.0.657877777004.issue1771@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Checked-in rev 60453. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 21:16:11 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 30 Jan 2008 20:16:11 -0000 Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted() In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za> Message-ID: <1201724171.75.0.0692157443498.issue1771@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 22:09:16 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 30 Jan 2008 21:09:16 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 In-Reply-To: <1191489495.02.0.0992368584163.issue1234@psf.upfronthosting.co.za> Message-ID: <1201727356.64.0.769887659485.issue1234@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Christian, could you apply this patch ? It needs a working autoconf 2.61 installation which I currently don't have. The patch itself, does the trick, so should go in. Thanks. ---------- assignee: lemburg -> tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 23:55:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 30 Jan 2008 22:55:03 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 In-Reply-To: <1191489495.02.0.0992368584163.issue1234@psf.upfronthosting.co.za> Message-ID: <1201733703.27.0.405534797459.issue1234@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r60464 (trunk) and r60465 (25) ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Jan 30 23:58:34 2008 From: report at bugs.python.org (dugang@188.com) Date: Wed, 30 Jan 2008 22:58:34 -0000 Subject: [issue1978] Python(2.5.1) will be crashed when i use _ssl module in multi-threads environment in linux. In-Reply-To: <1201733914.21.0.052632860787.issue1978@psf.upfronthosting.co.za> Message-ID: <1201733914.21.0.052632860787.issue1978@psf.upfronthosting.co.za> New submission from dugang at 188.com: Python-2.5.1 will be crashed when i use _ssl module in multi-threads environment in linux. the sample code looks as below(A https server is running on host which ip is "192.168.5.151" and many certificates and keys in PEM format are in the directory "./cert". These certificates and keys are ok because i can use them in a web browser like IE/ Firefox.): ------------------------------------------------------------------------ ------ #! /home/duxg/Download/soft/Python-2.5.1/python # # filename: test.py # '''This script simulates the behaviors of a https client.''' import threading import httplib class HTTPSClient(threading.Thread): def __init__(self, server_ip, url, cert_file, key_file): threading.Thread.__init__(self) # get run parameters self.server_ip = server_ip self.url = url self.cert_file = cert_file self.key_file = key_file def get(self): # make headers headers = {'User-Agent': 'https_test/dugang at 188.com', 'Connection': 'close' } # use httplib conn = httplib.HTTPSConnection('%s' % self.server_ip, \ key_file = self.key_file, \ cert_file = self.cert_file) # http get conn.request('GET', self.url, headers = headers) resp = conn.getresponse() # check response if resp.status != 200: print 'get(%s) failed/status=%d.' % (self.url, resp.status) return False return True def run(self): while True: self.get() def main(): worker_number = 100 threading.stack_size(512 * 1024) worker = [] for i in range(worker_number): # create worker thread worker.append(HTTPSClient('192.168.5.151', '/test.html', \ './cert/testu%d.cert' % i, \ './cert/testu%d.key' % i)) for w in worker: # go w.start() for w in worker: # wait w.join() main() ------------------------------------------------------------------------ ------ This code will be produced a lot of exceptions and finally it will cause Python crashed. ------------------------------------------------------------------------ ------ Exception in thread Thread-19: Traceback (most recent call last): File "/home/duxg/Download/soft/Python-2.5.1/Lib/threading.py", line 460, in __bootstrap self.run() File "./test.py", line 39, in run self.get() File "./test.py", line 29, in get conn.request('GET', self.url, headers = headers) File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line 862, in request self._send_request(method, url, body, headers) File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line 885, in _send_request self.endheaders() File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line 856, in endheaders self._send_output() File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line 728, in _send_output self.send(msg) File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line 695, in send self.connect() File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line 1131, in connect ssl = socket.ssl(sock, self.key_file, self.cert_file) File "/home/duxg/Download/soft/Python-2.5.1/Lib/socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) sslerror: SSL_CTX_use_certificate_chain_file error ... *** glibc detected *** /home/duxg/Download/soft/Python-2.5.1/python: double free or corruption (!prev): 0x0a2b71a0 *** ======= Backtrace: ========= /lib/libc.so.6[0x887f41] /lib/libc.so.6(cfree+0x90)[0x88b580] /lib/libcrypto.so.6(CRYPTO_free+0x3a)[0x14f46a] /lib/libcrypto.so.6(ERR_clear_error+0x73)[0x1a4d13] /lib/libssl.so.6(SSL_CTX_use_certificate_chain_file+0x227)[0x358e47] /home/duxg/Download/soft/Python-2.5.1/build/lib.linux-i686-2.5/ _ssl.so[0xb9eb9e] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalFrameEx+0x5d2c)[0x80c539c] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalCodeEx+0x775)[0x80c65d5] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalFrameEx+0x5419)[0x80c4a89] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalFrameEx+0x6155)[0x80c57c5] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalFrameEx+0x6155)[0x80c57c5] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalFrameEx+0x6155)[0x80c57c5] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalFrameEx+0x6155)[0x80c57c5] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalFrameEx+0x6155)[0x80c57c5] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalCodeEx+0x775)[0x80c65d5] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalFrameEx+0x5419)[0x80c4a89] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalFrameEx+0x6155)[0x80c57c5] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalFrameEx+0x6155)[0x80c57c5] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_EvalCodeEx+0x775)[0x80c65d5] /home/duxg/Download/soft/Python-2.5.1/python[0x810d6f1] /home/duxg/Download/soft/Python-2.5.1/ python(PyObject_Call+0x27)[0x805a277] /home/duxg/Download/soft/Python-2.5.1/python[0x80603a7] /home/duxg/Download/soft/Python-2.5.1/ python(PyObject_Call+0x27)[0x805a277] /home/duxg/Download/soft/Python-2.5.1/ python(PyEval_CallObjectWithKeywords+0x6c)[0x80be7cc] /home/duxg/Download/soft/Python-2.5.1/python[0x80f01e8] /lib/libpthread.so.0[0xc292fb] /lib/libc.so.6(clone+0x5e)[0x8f093e] ======= Memory map: ======== 00110000-00113000 r-xp 00000000 08:05 2417874 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/time.so 00113000-00115000 rwxp 00002000 08:05 2417874 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/time.so 00115000-00119000 r-xp 00000000 08:05 2417882 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/collections.so 00119000-0011a000 rwxp 00004000 08:05 2417882 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/collections.so 0011a000-0011c000 r-xp 00000000 08:05 2417878 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/_random.so 0011c000-0011d000 rwxp 00002000 08:05 2417878 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/_random.so 0011d000-00239000 r-xp 00000000 08:03 491746 /lib/ libcrypto.so.0.9.8b 00239000-0024b000 rwxp 0011c000 08:03 491746 /lib/ libcrypto.so.0.9.8b 0024b000-0024f000 rwxp 0024b000 00:00 0 0024f000-0027b000 r-xp 00000000 08:09 623501 /usr/lib/ libgssapi_krb5.so.2.2 0027b000-0027c000 rwxp 0002c000 08:09 623501 /usr/lib/ libgssapi_krb5.so.2.2 0027c000-0027e000 r-xp 00000000 08:03 491630 /lib/libkeyutils-1.2.so 0027e000-0027f000 rwxp 00001000 08:03 491630 /lib/libkeyutils-1.2.so 00287000-00288000 r-xp 00287000 00:00 0 [vdso] 00288000-00317000 r-xp 00000000 08:09 623515 /usr/lib/libkrb5.so.3.3 00317000-00319000 rwxp 0008f000 08:09 623515 /usr/lib/libkrb5.so.3.3 00319000-00324000 r-xp 00000000 08:03 491522 /lib/libgcc_s-4.1.2- 20070503.so.1 00324000-00325000 rwxp 0000a000 08:03 491522 /lib/libgcc_s-4.1.2- 20070503.so.1 00328000-00369000 r-xp 00000000 08:03 491748 /lib/libssl.so.0.9.8b 00369000-0036d000 rwxp 00040000 08:03 491748 /lib/libssl.so.0.9.8b 003c8000-003ca000 r-xp 00000000 08:03 491577 /lib/libutil-2.6.so 003ca000-003cb000 r-xp 00001000 08:03 491577 /lib/libutil-2.6.so 003cb000-003cc000 rwxp 00002000 08:03 491577 /lib/libutil-2.6.so 00433000-00436000 r-xp 00000000 08:03 491551 /lib/libdl-2.6.so 00436000-00437000 r-xp 00002000 08:03 491551 /lib/libdl-2.6.so 00437000-00438000 rwxp 00003000 08:03 491551 /lib/libdl-2.6.so 00478000-0049f000 r-xp 00000000 08:03 491553 /lib/libm-2.6.so 0049f000-004a0000 r-xp 00026000 08:03 491553 /lib/libm-2.6.so 004a0000-004a1000 rwxp 00027000 08:03 491553 /lib/libm-2.6.so 004f4000-00506000 r-xp 00000000 08:03 491595 /lib/libz.so.1.2.3 00506000-00507000 rwxp 00011000 08:03 491595 /lib/libz.so.1.2.3 00581000-00591000 r-xp 00000000 08:03 491571 /lib/libresolv-2.6.so 00591000-00592000 r-xp 0000f000 08:03 491571 /lib/libresolv-2.6.so 00592000-00593000 rwxp 00010000 08:03 491571 /lib/libresolv-2.6.so 00593000-00595000 rwxp 00593000 00:00 0 005d7000-005d9000 r-xp 00000000 08:05 2417903 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/fcntl.so 005d9000-005da000 rwxp 00002000 08:05 2417903 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/fcntl.so 00651000-00654000 r-xp 00000000 08:05 2417915 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/cStringIO.so 00654000-00655000 rwxp 00003000 08:05 2417915 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/cStringIO.so 00734000-0073d000 r-xp 00000000 08:05 2417935 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/_socket.so 0073d000-00740000 rwxp 00009000 08:05 2417935 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/_socket.so 00820000-0096e000 r-xp 00000000 08:03 491545 /lib/libc-2.6.so 0096e000-00970000 r-xp 0014e000 08:03 491545 /lib/libc-2.6.so 00970000-00971000 rwxp 00150000 08:03 491545 /lib/libc-2.6.so 00971000-00974000 rwxp 00971000 00:00 0 009a7000-009a9000 r-xp 00000000 08:05 2417870 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/math.so 009a9000-009aa000 rwxp 00002000 08:05 2417870 /home/duxg/Download/ soft/Python-2.5.1/build/lib.linux-i686-2.5/math.so 00b11000-0Aborted (core dumped) ------------------------------------------------------------------------ ------ I think the problem is in that the _ssl module does not correctly initialize the OpenSSL Library, so i make a patch to fix it. now it seems worked well. ---------- components: None files: _ssl.c.patch messages: 61880 nosy: dugang at 188.com severity: normal status: open title: Python(2.5.1) will be crashed when i use _ssl module in multi-threads environment in linux. type: crash versions: Python 2.5 Added file: http://bugs.python.org/file9335/_ssl.c.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 01:02:48 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 00:02:48 -0000 Subject: [issue1978] Python(2.5.1) will be crashed when i use _ssl module in multi-threads environment in linux. In-Reply-To: <1201733914.21.0.052632860787.issue1978@psf.upfronthosting.co.za> Message-ID: <1201737768.04.0.38696543833.issue1978@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> janssen components: +Extension Modules -None keywords: +patch nosy: +janssen priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 02:50:48 2008 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 31 Jan 2008 01:50:48 -0000 Subject: [issue1967] Backport dictviews to 2.6 In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za> Message-ID: <1201744248.29.0.378464555717.issue1967@psf.upfronthosting.co.za> Changes by Thomas Wouters: Removed file: http://bugs.python.org/file9320/dictviews_backport.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 02:50:59 2008 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 31 Jan 2008 01:50:59 -0000 Subject: [issue1967] Backport dictviews to 2.6 In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za> Message-ID: <1201744259.54.0.851142173989.issue1967@psf.upfronthosting.co.za> Thomas Wouters added the comment: After talking to Guido, got rid of the future import magic in favour of just providing 'viewkeys', 'viewitems' and 'viewvalues' methods of dicts. This makes efficient 2.6-and-3.0 dict-using code possibly by making 2to3 translate the view-methods directly to keys/values/items in 3.0, and not wrapping everything in list(). Added file: http://bugs.python.org/file9336/dictviews_backport.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 03:06:43 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 31 Jan 2008 02:06:43 -0000 Subject: [issue1905] PythonLauncher not working correctly on OS X 10.5/Leopad In-Reply-To: <1201012501.41.0.744457037048.issue1905@psf.upfronthosting.co.za> Message-ID: <1201745203.67.0.190205970619.issue1905@psf.upfronthosting.co.za> Mark Dickinson added the comment: I can reproduce this in the trunk, on OS X 10.5.1/Intel: after a ./configure --enable-framework && make && sudo make altinstall ctrl-clicking on a simple python file on the Desktop and selecting OpenWith -> PythonLauncher fails to run the script and gives essentially the same messages in the console: 1/30/08 7:59:31 PM Python Launcher[23508] doscript: Could not activate Terminal 1/30/08 7:59:31 PM Python Launcher[23508] doscript: AESend(activate): error -600 1/30/08 7:59:31 PM Python Launcher[23508] Exit status: -600 Assigning this to Ronald Oussoren since he was the last person to touch PythonLauncher, so probably has a much better idea than me of what's going on. I'm a complete newbie when it comes to AppleEvents and the like, but I'm suspicious of the lines #define ACTIVATE_CMD 'misc' #define ACTIVATE_SUITE 'actv' in Mac/PythonLauncher/doscript.m; perhaps I'm looking in the wrong place, but I can't find documentation for 'actv' anywhere. ---------- assignee: -> ronaldoussoren nosy: +marketdickinson, ronaldoussoren versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 03:48:50 2008 From: report at bugs.python.org (Bill Janssen) Date: Thu, 31 Jan 2008 02:48:50 -0000 Subject: [issue1978] Python(2.5.1) will be crashed when i use _ssl module in multi-threads environment in linux. In-Reply-To: <1201733914.21.0.052632860787.issue1978@psf.upfronthosting.co.za> Message-ID: <1201747730.64.0.79436595587.issue1978@psf.upfronthosting.co.za> Bill Janssen added the comment: Thanks for the patch. I'm of two minds about this. It may well be an appropriate patch for 2.5.2 -- I seem to recall having to do something much like this in the new SSL module -- but it patches the old SSL code which we are replacing for 2.6. And I'd recommend downloading and using the new SSL code from PyPI with pre-2.6 Pythons instead of using the supplied support. I'd think, at the very least, this patch should include additions to the test suite for socket_ssl before it's included. ---------- nosy: +tiran priority: high -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 05:46:22 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 31 Jan 2008 04:46:22 -0000 Subject: [issue1979] Make Decimal comparisons with NaN less arbitrary In-Reply-To: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za> Message-ID: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za> New submission from Mark Dickinson: For Python 3.0 the decimal module got rich comparisons. Those comparisons have somewhat unconventional behavior with respect to NaNs, as seen below: <, <= and == comparisons involving NaNs always return False, while >, >= and != comparisons always return True. The Decimal specification has nothing helpful to say about comparisons involving NaNs. But reading IEEE- 754r (on which the Decimal specification is closely based), there are two possible options: (1) have comparisons involving NaNs (except for !=) raise InvalidOperation in the context, and hence give a Python exception (assuming that InvalidOperation isn't trapped.) (2) have comparisons involving NaNs always return False (except for !=, which always returns True). I think either of these is better than the current behavior. (2) seems like the better option, for a couple of reasons: first, it's the way that Python floats currently work, and second, there might be issues with list membership testing if equality comparisons involving NaNs raised an exception or returned a NaN. Since Mike Cowlishaw is intimately involved with both the Decimal specification and the IEEE-754r process, I thought it might be useful to have his opinion on this; his main recommendation was to have the Decimal type do the same as the float type. The attached patch makes <, <=, >, >= and == comparisons involving NaNs always return False, and != comparisons always return True. It also renames __cmp__ to _cmp and adds a few tests for the new behavior. Here's how NaN comparisons currently work: Python 3.0a2+ (py3k:60470M, Jan 30 2008, 23:11:40) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import * >>> n = Decimal("nan") >>> i = Decimal("inf") >>> n < n False >>> n > n True >>> i < n False >>> i > n True See also issue #1514428. ---------- assignee: facundobatista components: Library (Lib) files: richcmp.patch keywords: patch messages: 61884 nosy: facundobatista, marketdickinson severity: minor status: open title: Make Decimal comparisons with NaN less arbitrary type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9337/richcmp.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 06:22:39 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 31 Jan 2008 05:22:39 -0000 Subject: [issue1979] Make Decimal comparisons with NaN less arbitrary In-Reply-To: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za> Message-ID: <1201756959.29.0.171955510344.issue1979@psf.upfronthosting.co.za> Raymond Hettinger added the comment: ISTM, you're now moving far beyond the spec into territory that isn't covered by tests or standards. Is this necessary? ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 06:59:31 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 31 Jan 2008 05:59:31 -0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1201759171.26.0.962353127517.issue1545463@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: The problem still exists in 2.5.1. The explanations given so far are not correct. With x.py as before (see attached): >>> import sys, gc, x creating X('new') creating X('old') >>> del x,sys.modules['x'] deleting X('old') >>> gc.collect() deleting X('new') 6 which shows that the cycles in x module are resolvable by GC. The problem is not that there are uncollectable objects but that GC is ran on exit before x becomes dead. >>> import sys, gc, x creating X('new') creating X('old') >>> gc.set_debug(1) >>> sys.exit() gc: collecting generation 2... gc: objects in each generation: 463 2034 0 gc: done. deleting X('old') Looking at the comments in Py_Finalize, it looks like GvR intended to run GC after destroying the modules, but it led to problems: (from svn blame Python/pythonrun.c) 32278 gvanrossum 9025 guido /* Destroy all modules */ 8403 guido PyImport_Cleanup(); 9025 guido 32278 gvanrossum /* Collect final garbage. This disposes of cycles created by 34776 tim_one * new-style class definitions, for example. 34776 tim_one * XXX This is disabled because it caused too many problems. If 34776 tim_one * XXX a __del__ or weakref callback triggers here, Python code has 34776 tim_one * XXX a hard time running, because even the sys module has been 34776 tim_one * XXX cleared out (sys.stdout is gone, sys.excepthook is gone, etc). 34776 tim_one * XXX One symptom is a sequence of information- free messages 34776 tim_one * XXX coming from threads (if a __del__ or callback is invoked, 34776 tim_one * XXX other threads can execute too, and any exception they encounter 34776 tim_one * XXX triggers a comedy of errors as subsystem after subsystem 34776 tim_one * XXX fails to find what it *expects* to find in sys to help report 34776 tim_one * XXX the exception and consequent unexpected failures). I've also 34776 tim_one * XXX seen segfaults then, after adding print statements to the 34776 tim_one * XXX Python code getting called. 34776 tim_one */ 34776 tim_one #if 0 32278 gvanrossum PyGC_Collect(); 34776 tim_one #endif Commenting out PyGC_Collect() seems like a too radical solution because no module referenced cycles get collected, not even those without __del__. I have not tried it yet, but it looks like a possible solution is to call PyGC_Collect() at the end of _PyModule_Clear. ---------- type: -> resource usage versions: +Python 2.5 -Python 2.4 Added file: http://bugs.python.org/file9338/x.py _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 31 08:52:24 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Thu, 31 Jan 2008 07:52:24 -0000 Subject: [issue1014230] optparse: parser.remove_option("-h") inconsistency Message-ID: <1201765944.91.0.804235730421.issue1014230@psf.upfronthosting.co.za> Ralf Schmitt added the comment: this test program work with python 2.4 and 2.5: import optparse p1=optparse.OptionParser() p2=optparse.OptionParser() p1.remove_option('-h') p2.remove_option('-h') This issue should be closed. ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 31 09:21:28 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Thu, 31 Jan 2008 08:21:28 -0000 Subject: [issue870807] optparse int, long types support binary, octal and hex forma Message-ID: <1201767688.85.0.400428578751.issue870807@psf.upfronthosting.co.za> Ralf Schmitt added the comment: python trunk supports this. please close. ---------- nosy: +schmir ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 31 09:37:36 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 31 Jan 2008 08:37:36 -0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1201768656.23.0.123641352943.issue1545463@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: In PyImport_Cleanup(), sys and __builtin__ are the last ones deleted. What if PyGC_Collect() is called just before? ---------- nosy: +amaury.forgeotdarc _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 31 09:39:39 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 31 Jan 2008 08:39:39 -0000 Subject: [issue870807] optparse int, long types support binary, octal and hex forma Message-ID: <1201768779.47.0.424762700816.issue870807@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc: ---------- status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 31 09:51:02 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 31 Jan 2008 08:51:02 -0000 Subject: [issue1014230] optparse: parser.remove_option("-h") inconsistency Message-ID: <1201769462.22.0.735531548768.issue1014230@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc: ---------- resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 31 09:56:06 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Thu, 31 Jan 2008 08:56:06 -0000 Subject: [issue1976] pybsddb leak in using cursors In-Reply-To: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za> Message-ID: <1201769766.68.0.0923813330992.issue1976@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Seems to be a leak when a cursor is used in a database without an environment. Working on this... __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 10:08:46 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Thu, 31 Jan 2008 09:08:46 -0000 Subject: [issue1976] pybsddb leak in using cursors In-Reply-To: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za> Message-ID: <1201770526.8.0.521164052255.issue1976@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Memory leak solved. Commit 293 in Sourceforge __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 11:05:14 2008 From: report at bugs.python.org (Dmitrey) Date: Thu, 31 Jan 2008 10:05:14 -0000 Subject: [issue1515] deepcopy doesn't copy instance methods In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za> Message-ID: <1201773914.37.0.11183360199.issue1515@psf.upfronthosting.co.za> Dmitrey added the comment: Hallo, I' developer of the OpenOpt, free Python-based numerical optimization framework. Please don't you mind me to increase Severity of the bug to major. This bug is driving me mad, as well as some of OO users, and makes OO usage much less convenient and obvious. http://openopt.blogspot.com/2008/01/about-prob-structure-redefinition.html ---------- nosy: +Dmitrey severity: normal -> major __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 11:06:08 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 31 Jan 2008 10:06:08 -0000 Subject: [issue1979] Make Decimal comparisons with NaN less arbitrary In-Reply-To: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za> Message-ID: <1201773968.87.0.557769659859.issue1979@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yes, I think it's necessary. Speaking of standards, it's the current behavior which isn't backed by any standard or rationale other than the historical one involving now-defunct 3- way comparisons. The proposed behavior is much closer to that specified by C99 (see sections 7.12.14 and section F.3) and by IEEE 754 and its upcoming revision (see section 5.11 of the most recent draft, which is linked to from the wikipedia page for IEEE 754r). Even better from a standards-compliance perspective would be to have all comparisons except != involving NaNs raise the InvalidOperation flag. The current behavior also breaks something fundamental: namely, that x < y should have the same truth value as y > x. Python even depends on this for reversing comparison operators, which explains, but in my opinion doesn't excuse, the following oddity: >>> 2 < Decimal("NaN") True >>> Decimal(2) < Decimal("NaN") False __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 11:27:25 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 31 Jan 2008 10:27:25 -0000 Subject: [issue1977] Python reinitialization test In-Reply-To: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za> Message-ID: <1201775245.67.0.132296481026.issue1977@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Perhaps ROUNDS, CAUSE_SEGFAULT and VERBOSE could be command-line rather than compile-time options? ---------- nosy: +pitrou __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 12:19:38 2008 From: report at bugs.python.org (Erno Kuusela) Date: Thu, 31 Jan 2008 11:19:38 -0000 Subject: [issue1980] pdb losing __file__ In-Reply-To: <1201778377.96.0.548753633413.issue1980@psf.upfronthosting.co.za> Message-ID: <1201778377.96.0.548753633413.issue1980@psf.upfronthosting.co.za> New submission from Erno Kuusela: under pdb, __file__ is not defined when executing a source code file directly. for example, if myprogram.py contains "print __file__", a NameError will be raised when run with python -m pdb myprogram.py. ---------- components: Library (Lib) messages: 61896 nosy: erno severity: normal status: open title: pdb losing __file__ versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 13:18:22 2008 From: report at bugs.python.org (David Binger) Date: Thu, 31 Jan 2008 12:18:22 -0000 Subject: [issue1482] IMAP4 SSL isn't working In-Reply-To: <1195637275.04.0.129181694073.issue1482@psf.upfronthosting.co.za> Message-ID: <1201781902.14.0.608127591029.issue1482@psf.upfronthosting.co.za> David Binger added the comment: Bill's patch does appear to fix the ssl-related problem. imaplib is still broken in py3k, though, due to bytes/str issues. ---------- nosy: +dbinger __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 14:30:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 13:30:57 -0000 Subject: [issue1980] pdb losing __file__ In-Reply-To: <1201778377.96.0.548753633413.issue1980@psf.upfronthosting.co.za> Message-ID: <1201786257.46.0.732603301179.issue1980@psf.upfronthosting.co.za> Christian Heimes added the comment: The issue is already fixed in the 2.5 and 2.6. 2.5.2 is going to be released in a couple of weeks. $ python2.5 test.py > /home/heimes/dev/python/trunk/test.py(4)() -> print __file__ (Pdb) n test.py --Return-- > /home/heimes/dev/python/trunk/test.py(4)()->None -> print __file__ (Pdb) n ---------- nosy: +tiran resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 14:34:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 13:34:08 -0000 Subject: [issue1979] Make Decimal comparisons with NaN less arbitrary In-Reply-To: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za> Message-ID: <1201786448.34.0.52075606202.issue1979@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 14:41:41 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 13:41:41 -0000 Subject: [issue1977] Python reinitialization test In-Reply-To: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za> Message-ID: <1201786901.22.0.281633151025.issue1977@psf.upfronthosting.co.za> Christian Heimes added the comment: I like to keep the test as simple as possible. Here is a new file that shows Python crashes in the third Py_Finalize(). Added file: http://bugs.python.org/file9339/test_reinit.c __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 15:18:38 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 14:18:38 -0000 Subject: [issue1515] deepcopy doesn't copy instance methods In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za> Message-ID: <1201789118.34.0.645107078866.issue1515@psf.upfronthosting.co.za> Christian Heimes added the comment: I've read your blog. You don't have to modify the Python core: import copy import types def _deepcopy_method(x, memo): return type(x)(x.im_func, deepcopy(x.im_self, memo), x.im_class) copy._deepcopy_dispatch[types.MethodType] = _deepcopy_method I still wonder why you have to use deepcopy in your app. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 15:23:43 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 14:23:43 -0000 Subject: [issue1515] deepcopy doesn't copy instance methods In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za> Message-ID: <1201789423.53.0.18833238164.issue1515@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm bumping up the version number to 2.6. Python 2.5 is in maintenance mode and the behavior of deepcopy for instance methods won't be changed. ---------- components: +Library (Lib) priority: -> normal versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 15:48:39 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 31 Jan 2008 14:48:39 -0000 Subject: [issue799088] distutils ignored LDFLAGS in Makefile Message-ID: <1201790919.4.0.0899851224072.issue799088@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: ---------- resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 31 15:50:27 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 31 Jan 2008 14:50:27 -0000 Subject: [issue800926] Python version numbers in headers/footers PDF documentation Message-ID: <1201791027.92.0.842378822841.issue800926@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Not really sure if this applies to new docs. I will let Georg close this one :-). ---------- nosy: +draghuram, georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 31 15:51:49 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 31 Jan 2008 14:51:49 -0000 Subject: [issue800929] Module-specific PDFs Message-ID: <1201791109.33.0.444716257022.issue800929@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Yet another one. ---------- nosy: +draghuram, georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 31 16:18:20 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 15:18:20 -0000 Subject: [issue1977] Python reinitialization test In-Reply-To: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za> Message-ID: <1201792700.37.0.0045271482015.issue1977@psf.upfronthosting.co.za> Christian Heimes added the comment: If fixed the problem with multiple reinitialization in r60477. It took me quite some time to find the right spot. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 17:17:02 2008 From: report at bugs.python.org (Alexander Shigin) Date: Thu, 31 Jan 2008 16:17:02 -0000 Subject: [issue1981] operator "is" In-Reply-To: <1201796222.53.0.881330735735.issue1981@psf.upfronthosting.co.za> Message-ID: <1201796222.53.0.881330735735.issue1981@psf.upfronthosting.co.za> New submission from Alexander Shigin: Hello, The operator "is" works strange with methods, i.e.: >>> a = 1 >>> a.__abs__ is a.__abs__ False If this is the preferred behavior by some reasons, I think documentation should explain it. It was tested on python 2.4.4, 2.5.1 and trunk r60477. ---------- messages: 61905 nosy: shigin severity: normal status: open title: operator "is" type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 17:19:04 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 31 Jan 2008 16:19:04 -0000 Subject: [issue1981] operator "is" In-Reply-To: <1201796222.53.0.881330735735.issue1981@psf.upfronthosting.co.za> Message-ID: <1201796344.68.0.713936765726.issue1981@psf.upfronthosting.co.za> Georg Brandl added the comment: Yes, it is expected since the descriptor access to methods creates a new bound method object every time. The "is" operator does not work special with methods. There is another issue about documenting this, so closing as a duplicate. ---------- nosy: +georg.brandl resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 17:24:29 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 31 Jan 2008 16:24:29 -0000 Subject: [issue1981] operator "is" In-Reply-To: <1201796222.53.0.881330735735.issue1981@psf.upfronthosting.co.za> Message-ID: <1201796669.21.0.249922608784.issue1981@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: It's actually documented in http://docs.python.org/dev/reference/datamodel.html """ Note that the transformation from function object to (unbound or bound) method object happens each time the attribute is retrieved from the class or instance """ ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 17:46:30 2008 From: report at bugs.python.org (Alexander Shigin) Date: Thu, 31 Jan 2008 16:46:30 -0000 Subject: [issue1981] operator "is" In-Reply-To: <1201796222.53.0.881330735735.issue1981@psf.upfronthosting.co.za> Message-ID: <1201797990.63.0.967070906221.issue1981@psf.upfronthosting.co.za> Alexander Shigin added the comment: I think it's good idea to make a note in Comparisons section or make some reference to data model section. """ The operators is and is not test for object identity: x is y is true if and only if x and y are the same object. x is not y yields the inverse truth value. """ But, >>> id(a.__abs__) == id(a.__abs__) True And only example below shows me error in my objection. >>> id(w) 6636344 >>> p = id(w) >>> del w >>> e = 1 >>> id(e) 6636344 I'm sorry for spam. I've missed Issue1410739 when search for any open bug. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 18:15:58 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 31 Jan 2008 17:15:58 -0000 Subject: [issue1515] deepcopy doesn't copy instance methods In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za> Message-ID: <1201799758.88.0.487606258946.issue1515@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm fine with applying Michael's suggestion to 2.6. I're reverting the priority change though; using deepcopy is not OO and IMO usually indicates that there's something wrong with your app. ---------- severity: major -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 18:16:25 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 31 Jan 2008 17:16:25 -0000 Subject: [issue1410739] Add notes to the manual about `is` and methods Message-ID: <1201799785.08.0.872969127307.issue1410739@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: An even more surprising example: >>> id([1]) == id([2]) True ---------- nosy: +amaury.forgeotdarc _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 31 18:21:42 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 17:21:42 -0000 Subject: [issue1410739] Add notes to the manual about `is` and methods Message-ID: <1201800102.09.0.0346814443162.issue1410739@psf.upfronthosting.co.za> Christian Heimes added the comment: The example sure is surprising for somebody without intimate knowledge about Python's memory management. Although the is operator is implemented as id(a) == id(b) reference counting, free lists and arenas can cause some surprising effects. ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 31 18:32:15 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 31 Jan 2008 17:32:15 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201800735.84.0.0929152826893.issue1941@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Comments? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 18:42:11 2008 From: report at bugs.python.org (Bill Janssen) Date: Thu, 31 Jan 2008 17:42:11 -0000 Subject: [issue1482] IMAP4 SSL isn't working In-Reply-To: <1195637275.04.0.129181694073.issue1482@psf.upfronthosting.co.za> Message-ID: <1201801331.49.0.477363713639.issue1482@psf.upfronthosting.co.za> Bill Janssen added the comment: But that's issue 1210, which is still open. David, do you want to submit a patch for 1210? Meanwhile, do we still need this issue to be open? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 18:43:27 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 31 Jan 2008 17:43:27 -0000 Subject: [issue1979] Make Decimal comparisons with NaN less arbitrary In-Reply-To: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za> Message-ID: <1201801407.0.0.421461232644.issue1979@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a patch (richcmp_signal.patch) that gives an alternative way of doing things: all <, <=, > and >= comparisons involving a NaN raise the InvalidOperation flag (using exactly the same semantics as those specified for compare_signal). == and != comparisons always return False and True, respectively, just as they do now. So the post-patch decimal exactly follows IEEE 754(r) on this. I think it makes good sense from a user's viewpoint, too: with the default settings, any <, <=, > or >= comparison involving a NaN raises a Python exception; this seems like the best outcome for a beginning Decimal user, while expert users can choose to use the public compare or compare_signal methods instead. My worries about list membership testing were nonsensical: there's only one reasonable behaviour for == and !=, namely the current behavior, which also matches all the standards. On balance, I think I prefer this approach to the idea of returning False on comparisons involving NaNs. The only fly in the ointment is that floats and Decimals behave differently in this respect. Added file: http://bugs.python.org/file9340/richcmp_signal.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 18:45:11 2008 From: report at bugs.python.org (Thomas Heller) Date: Thu, 31 Jan 2008 17:45:11 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201801511.94.0.215020465785.issue1941@psf.upfronthosting.co.za> Thomas Heller added the comment: Lib/platform.py contains this notice at the top: # This module is maintained by Marc-Andre Lemburg . # If you find problems, please submit bug reports/patches via the # Python SourceForge Project Page and assign them to "lemburg". # # Note: Please keep this module compatible to Python 1.5.2. I didn't look into the other modules in the patch. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 18:46:17 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Thu, 31 Jan 2008 17:46:17 -0000 Subject: [issue1968] Unused number magic methods leaked into Py2.6 In-Reply-To: <1201647350.7.0.0255165658093.issue1968@psf.upfronthosting.co.za> Message-ID: <1201801577.85.0.802009153029.issue1968@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Done in r60480. ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 18:48:26 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 31 Jan 2008 17:48:26 -0000 Subject: [issue1941] 2.6 stdlib using with statement In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za> Message-ID: <1201801706.7.0.0504179625312.issue1941@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Please remove the platform.py part of the patch. You can apply that to Py3k, but not to the 2.x series. ---------- nosy: +lemburg __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 19:03:17 2008 From: report at bugs.python.org (Bill Janssen) Date: Thu, 31 Jan 2008 18:03:17 -0000 Subject: [issue1210] imaplib does not run under Python 3 In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za> Message-ID: <1201802597.65.0.981006186047.issue1210@psf.upfronthosting.co.za> Bill Janssen added the comment: IMAP doesn't really support multiple charsets (just looked at RFC 3501). There are two places where character sets other than ASCII is used. One is in the SEARCH command; there's an optional parameter which can indicate that the search strings are in a non-ASCII character set. The other is in transmission of message literals (email messages) back and forth. So probably setting the default encoding at this level isn't quite right, as you should definitely be reading raw bytes from the socket, not characters, but it isn't too far off. Looks like _command() needs a bit of work (it shouldn't try to quote bytes, only strings), and the documentation need to be improved, to say that non-ASCII search strings and message bodies should be passed as bytes encoded according to the specified CHARSET, but with those fixes it should work. Assuming that bytes are hashable in Python 3K. ---------- nosy: +janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 19:05:21 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 31 Jan 2008 18:05:21 -0000 Subject: [issue1976] pybsddb leak in using cursors In-Reply-To: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za> Message-ID: <1201802721.25.0.681668330749.issue1976@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Greg, can you take a look? ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 19:06:23 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 31 Jan 2008 18:06:23 -0000 Subject: [issue1976] pybsddb leak in using cursors In-Reply-To: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za> Message-ID: <1201802783.04.0.42702645199.issue1976@psf.upfronthosting.co.za> Martin v. L?wis added the comment: jcea, can you please attach the actual patch to be reviewed to this report? What is commit 293 in SourceForge? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 19:11:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 18:11:32 -0000 Subject: [issue1515] deepcopy doesn't copy instance methods In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za> Message-ID: <1201803092.5.0.721301858589.issue1515@psf.upfronthosting.co.za> Christian Heimes added the comment: Since Guido accepted the proposal can you please provide a patch with at least one unit test? ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 19:12:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 18:12:51 -0000 Subject: [issue1410739] Add notes to the manual about `is` and methods Message-ID: <1201803171.68.0.538422841951.issue1410739@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: fdrake -> keywords: +easy type: -> rfe versions: +Python 2.6 -Python 2.4 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 31 19:38:58 2008 From: report at bugs.python.org (Dmitrey) Date: Thu, 31 Jan 2008 18:38:58 -0000 Subject: [issue1515] deepcopy doesn't copy instance methods In-Reply-To: <1201803092.5.0.721301858589.issue1515@psf.upfronthosting.co.za> Message-ID: <47A215C2.7020405@scipy.org> Dmitrey added the comment: I don't know did you mean it to me (as I've noticed from address) or no. I can hardly provide any help for fixing the bug, I'm not skilled enough in Python core files. Here's results of the proposition mentioned: import copy import types def _deepcopy_method(x, memo): return type(x)(x.im_func, deepcopy(x.im_self, memo), x.im_class) copy._deepcopy_dispatch[types.MethodType] = _deepcopy_method from scikits.openopt import NLP p = NLP(lambda x: x**2, 1) p3 = _deepcopy_method(p, None) Traceback (most recent call last): File "test_deepcopy.py", line 10, in p3 = _deepcopy_method(p, None) File "test_deepcopy.py", line 5, in _deepcopy_method return type(x)(x.im_func, deepcopy(x.im_self, memo), x.im_class) AttributeError: NLP instance has no attribute 'im_func' as for copy.py from Python core, it seems like the file has no "_deepcopy_method" function. Users want to run r = p.solve(solverName) for several different solvers and same p instance. So it needs each time using for sn in [solverName1, solverName2, ..., solverNameN]: p = NLP(dozens of params) p.somefiled.paramN+1 =valN+1 p.somefiled.paramN+2 =valN+2 ... r{i} = p.solve(sn) while in my previous MATLAB version of the toolbox it looks just like: (assign prob only once) p = ooAssign(params) for sn in [solverName1, solverName2, ..., solverNameN] r{i} = p.solve(sn) end Christian Heimes wrote: > Christian Heimes added the comment: > > Since Guido accepted the proposal can you please provide a patch with at > least one unit test? > > ---------- > resolution: -> accepted > > __________________________________ > Tracker > > __________________________________ > > > > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 19:48:13 2008 From: report at bugs.python.org (David Binger) Date: Thu, 31 Jan 2008 18:48:13 -0000 Subject: [issue1482] IMAP4 SSL isn't working In-Reply-To: <1201801331.49.0.477363713639.issue1482@psf.upfronthosting.co.za> Message-ID: David Binger added the comment: On Jan 31, 2008, at 12:42 PM, Bill Janssen wrote: > > Bill Janssen added the comment: > > But that's issue 1210, which is still open. David, do you want to > submit a patch for 1210? I see that you are correct that 1210 is the bytes/str issue. I regret it, but I won't be able to supply a patch. > > Meanwhile, do we still need this issue to be open? Unless I'm missing something, the patch "b" that you posted has not been checked in. I think the issue should remain open until that happens. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 19:59:16 2008 From: report at bugs.python.org (Andreas Balogh) Date: Thu, 31 Jan 2008 18:59:16 -0000 Subject: [issue1982] Feature: extend strftime to accept milliseconds In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za> Message-ID: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za> New submission from Andreas Balogh: Currently serializing datetime objects into isoformat string is well possible. The reverse process - parsing an isoformat string into a datetime object - doesn't work due to the missing %-tag for the strftime format string. Proposal: Add new tag to strftime like format strings allowing to print and parse milliseconds. ---------- components: Extension Modules messages: 61924 nosy: asbalogh severity: normal status: open title: Feature: extend strftime to accept milliseconds versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 20:17:48 2008 From: report at bugs.python.org (Brett Cannon) Date: Thu, 31 Jan 2008 19:17:48 -0000 Subject: [issue1982] Feature: extend strftime to accept milliseconds In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za> Message-ID: <1201807068.59.0.0363693822463.issue1982@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 21:07:18 2008 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 31 Jan 2008 20:07:18 -0000 Subject: [issue846388] Check for signals during regular expression matches Message-ID: <1201810038.57.0.438897881038.issue846388@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think this is worth backporting to 2.5.2. This and r60054 are the *only* differences between _sre.c in 2.5.2 and 2.6. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Jan 31 21:07:28 2008 From: report at bugs.python.org (Ryan Stutsman) Date: Thu, 31 Jan 2008 20:07:28 -0000 Subject: [issue1983] Return from fork() is pid_t, not int In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za> Message-ID: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za> New submission from Ryan Stutsman: In current trunk (60097). Return from fork is not int but pid_t. Treating this as an int causes total breakage on systems with 64-bit pids. ---------- components: Library (Lib) messages: 61926 nosy: stutsman severity: normal status: open title: Return from fork() is pid_t, not int versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 21:26:58 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 31 Jan 2008 20:26:58 -0000 Subject: [issue1983] Return from fork() is pid_t, not int In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za> Message-ID: <1201811218.64.0.682610119066.issue1983@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you provide a patch? It would be good if it still worked on systems that don't have pid_t (although we could also require pid_t and then see what systems that breaks for). Also, what systems use 64-bit pids? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 21:51:32 2008 From: report at bugs.python.org (Ryan Stutsman) Date: Thu, 31 Jan 2008 20:51:32 -0000 Subject: [issue1983] Return from fork() is pid_t, not int In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za> Message-ID: <1201812692.21.0.669395031823.issue1983@psf.upfronthosting.co.za> Ryan Stutsman added the comment: Yeah; I shuold be able to provide one. I just hacked 2.4.4 to work so I think I could provide a fix easily. The version I put together here is rough, so I'll try to create a cleaner solution tonight or this weekend. HiStar does (http://www.scs.stanford.edu/histar/). Not sure if it's better to test for pid_t (in configure) or just use a long long value all around a punt the problem? I'll probably just go with the former unless there are objections. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 22:16:45 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 31 Jan 2008 21:16:45 -0000 Subject: [issue1222] locale.format bug if thousand separator is space (french separator as example) In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za> Message-ID: <1201814205.4.0.187939717016.issue1222@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. It is fairly big and I'm sorry about it, here is why: 1. it reworks the test suite using unittest, and makes it more comprehensive 2. it adds a feature in locale.py which allows overriding the localeconv dictionary (this is necessary for proper testing) 3. it fixes the present bug, and also fixes integer formatting with grouping and padding (which was broken, as well as untested) Point 2 above may be controversial, it is just a dictionary (by default empty) named _override_localeconv, if you prefer we can make it a real API, e.g. _set_localeconv(). Added file: http://bugs.python.org/file9341/1222.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 22:21:20 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 21:21:20 -0000 Subject: [issue1982] Feature: extend strftime to accept milliseconds In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za> Message-ID: <1201814480.04.0.590969507855.issue1982@psf.upfronthosting.co.za> Christian Heimes added the comment: Your chances are going to increase if you can come up with a decent patch. It's going to be harder than you might think. Python uses the system's strftime function. You'd have to implement a strftime replacement which supports miliseconds. Can't you use another like TAI64 (http://cr.yp.to/libtai/tai64.html#tai64n) or JDN (http://en.wikipedia.org/wiki/Julian_day) instead? ---------- nosy: +tiran priority: -> normal versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 22:30:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 31 Jan 2008 21:30:03 -0000 Subject: [issue1983] Return from fork() is pid_t, not int In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za> Message-ID: <1201815003.02.0.711988260679.issue1983@psf.upfronthosting.co.za> Christian Heimes added the comment: It's probably better to use pid_t through the code and add a typedef int pid_t for system's without pid_t. Or better typedef long pid_t? On my Linux, pid_t is defined as __PID_T_TYPE, which is defines as __S32_TYPE which ends up as int. ---------- nosy: +tiran priority: -> normal type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 22:32:59 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 31 Jan 2008 21:32:59 -0000 Subject: [issue1983] Return from fork() is pid_t, not int In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za> Message-ID: <1201815179.68.0.557999584953.issue1983@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Don't use long long literally; not all systems have such a type, and even if they do, they might not call it "long long". __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 22:55:58 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 31 Jan 2008 21:55:58 -0000 Subject: [issue1864] test_locale doesn't use unittest In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za> Message-ID: <1201816558.94.0.85275852858.issue1864@psf.upfronthosting.co.za> Antoine Pitrou added the comment: An improved version of this patch is now included in the proposed patch for #1222 :) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 22:57:20 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 31 Jan 2008 21:57:20 -0000 Subject: [issue1864] test_locale doesn't use unittest In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za> Message-ID: <1201816640.4.0.577300234302.issue1864@psf.upfronthosting.co.za> Antoine Pitrou added the comment: An improved version of this patch is now included in the proposed patch for #1222 :) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 23:19:39 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 31 Jan 2008 22:19:39 -0000 Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results Message-ID: <1201817978.91.0.372011463025.issue1678380@psf.upfronthosting.co.za> Mark Dickinson added the comment: Bug identifying 0j and -0j fixed for Python 2.6 in revision 60483. Martin, can this be backported to 2.5.2? I'll assume not, unless I hear otherwise from you. ---------- status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Jan 31 23:26:08 2008 From: report at bugs.python.org (Neil Roques) Date: Thu, 31 Jan 2008 22:26:08 -0000 Subject: [issue1984] The raw string r'\' fails In-Reply-To: <1201818368.03.0.299164822165.issue1984@psf.upfronthosting.co.za> Message-ID: <1201818368.03.0.299164822165.issue1984@psf.upfronthosting.co.za> New submission from Neil Roques: Python's raw strings are supposed to prevent characters being interpreted as special. However entering the raw string r'\' into an interactive session will result in: Traceback ( File "", line 1 r'\' ^ SyntaxError: EOL while scanning single-quoted string Python seems to have escaped the close of the string, even though raw strings are not supposed to ever escape characters. ---------- components: Interpreter Core messages: 61936 nosy: passage severity: minor status: open title: The raw string r'\' fails type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 23:41:54 2008 From: report at bugs.python.org (Toni Brkic) Date: Thu, 31 Jan 2008 22:41:54 -0000 Subject: [issue1985] Bug/Patch: Problem with xml/__init__.py when using freeze.py In-Reply-To: <1201819314.87.0.163541496288.issue1985@psf.upfronthosting.co.za> Message-ID: <1201819314.87.0.163541496288.issue1985@psf.upfronthosting.co.za> New submission from Toni Brkic: Hi, I tried to do freeze.py for my script that uses ElementTree. But got the this error: File "/usr/lib/python2.5/xml/__init__.py", line 45, in _xmlplus.__path__.extend(__path__) AttributeError: 'str' object has no attribute 'extend' The reason seems that _xmlplus.__path__ is a string after freeze.py. I fixed it by changing the import to: try: _xmlplus.__path__.extend(__path__) sys.modules[__name__] = _xmlplus except AttributeError: pass This might not be the correct solution but it works for me. I do not really now how the __path__ variable works in a freezed environment. Best regards ---------- messages: 61937 nosy: glomde severity: normal status: open title: Bug/Patch: Problem with xml/__init__.py when using freeze.py __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Jan 31 23:54:07 2008 From: report at bugs.python.org (Michael Van Biesbrouck) Date: Thu, 31 Jan 2008 22:54:07 -0000 Subject: [issue1515] deepcopy doesn't copy instance methods In-Reply-To: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za> Message-ID: <1201820047.8.0.854944184446.issue1515@psf.upfronthosting.co.za> Michael Van Biesbrouck added the comment: Dmitrey: You can't call _deepcopy_method() on anything other than something with type types.MethodType. It is a function in a type-dispatch table, so it will always be called safely. copy._deepcopy_dispatch is that table; if you assign _deepcopy_method to copy._deepcopy_dispatch[types.MethodType] then copy.deepcopy() will understand what to do with method types. See my unit test below for the semantics. Christian Heimes, this is my unit test: # This test would fail due to an exception during deepcopy in version 2.5.1 class C(object): def __init__(self, n): self.n = n def GetN(self): return self.n orig_obj = C(42) copy_list = copy.deepcopy([orig_obj, orig_obj.GetN]) if copy_list[1]() != 42: print 'Error: Instance method lost object?' orig_obj.n = 43 if copy_list[1]() != 42: print 'Error: Instance method assoc with orig object' copy_list[0].n = 44 if copy_list[1]() != 44: print 'Error: Instance method should assoc with new object copy' if not type(copy_list[1]) is type(orig_obj.GetN): print 'Error: Deepcopy changed type of instance method' Why do people want to use copy and deepcopy? I think that the issue is that Python is an imperative language that passes and copies references. If a library function doesn't treat its arguments as const, horrible things could happen. Compounding this, several standard operations (such as sort) operate in place, so if you want to use them then you need to make shallow copies at the very least. When non-scalar types nest, the whole structure can be deepcopied or copy can be used repeatedly in a selective manner (with a high chance of bugs). Perl deals with this issue by using standard copy semantics (but call-by-reference) and a copy-on-write implementation. Most operations operate out-of-place. Pure languages can use reference-based copy semantics because you can't modify anything, forcing users to create the copy-on-write implementation when mutating structures. __________________________________ Tracker __________________________________