", right before the Unicode string "??". #! /usr/bin/python3 # -*- coding: utf-8 -*- print( """\ Content-type: text/html """ ); print( """\ \ """ ); print("

"); print("??"); print("

"); print( """\ \ """ ); ---------- components: Unicode messages: 92341 nosy: loveminix severity: normal status: open title: Unicode IO not working in cgi applet type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:46:34 2009 From: report at bugs.python.org (lplatypus) Date: Mon, 07 Sep 2009 04:46:34 +0000 Subject: [New-bugs-announce] [issue6853] system proxy not used for https (on windows) In-Reply-To: <1252298794.29.0.673935576663.issue6853@psf.upfronthosting.co.za> Message-ID: <1252298794.29.0.673935576663.issue6853@psf.upfronthosting.co.za> New submission from lplatypus : On Windows, the urllib2 module (renamed to urllib.request in python 3) does not use the system web proxy for https URLs in the case where "Use the same proxy for all protocols" is selected in the Internet Explorer proxy settings. Attached is a patch against urllib/request.py in python 3.1.1 ---------- components: Library (Lib) files: urllib-httpsproxy.patch keywords: patch messages: 92342 nosy: ldeller severity: normal status: open title: system proxy not used for https (on windows) type: behavior versions: Python 2.6, Python 3.1 Added file: http://bugs.python.org/file14850/urllib-httpsproxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:13:34 2009 From: report at bugs.python.org (loveminix) Date: Mon, 07 Sep 2009 05:13:34 +0000 Subject: [New-bugs-announce] [issue6854] UnicodeDecodeError when retrieving binary data from cgi.FieldStorage() In-Reply-To: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za> Message-ID: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za> New submission from loveminix : The following cgi applet uploads a binary file to the server. It gets a "UnicodeDecodeError" inside cgi.FieldStorage(). The same code works in python 2.6. #! /usr/bin/python3 import os, cgi; import cgitb; cgitb.enable(); pathInfo = os.environ.get("PATH_INFO", ""); serverName = os.environ.get("SERVER_NAME", ""); scriptName = os.environ.get("SCRIPT_NAME", ""); if pathInfo == "": print( """\ Content-type: text/html """ ); print( """\

\ """.format(serverName, scriptName) ); elif pathInfo == "/upload": fieldStorage = cgi.FieldStorage(); fileItem = fieldStorage["file"]; if fileItem.filename != "": file = open("/tmp/test.txt", mode="wb"); file.write(fileItem.file.read()); file.close(); print( """\ Content-type: text/html """ ); print( """\

Success

\ """ ); ---------- components: Library (Lib) messages: 92343 nosy: loveminix severity: normal status: open title: UnicodeDecodeError when retrieving binary data from cgi.FieldStorage() type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 08:29:47 2009 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 07 Sep 2009 06:29:47 +0000 Subject: [New-bugs-announce] [issue6855] ihooks support for relative imports In-Reply-To: <1252304987.26.0.681394594908.issue6855@psf.upfronthosting.co.za> Message-ID: <1252304987.26.0.681394594908.issue6855@psf.upfronthosting.co.za> New submission from Neil Schemenauer : ihooks in 2.6 does not support relative imports. The attached patch was impired by Brett's "import in Python" code. ---------- assignee: brett.cannon components: Library (Lib) files: ihooks_relimport.txt messages: 92345 nosy: brett.cannon, nascheme priority: normal severity: normal stage: patch review status: open title: ihooks support for relative imports type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14852/ihooks_relimport.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 09:47:30 2009 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Mon, 07 Sep 2009 07:47:30 +0000 Subject: [New-bugs-announce] [issue6856] allow settong uid and gid when creating tar files In-Reply-To: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za> Message-ID: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za> New submission from Tarek Ziad? : I am proposing this feature for an issue we have in Distutils: being able to set the uid/gid of files added in a tar archive using tarfile. Here's what I am proposing: - adding two methods to TarInfo: set_uid and set_gid, that are able to take a user and group name *or* a uid and gid number - adding in TarFile a new filter option to add() called include. If given, it's a callable that receives the tarinfo object right before it's added, so its uid/gid can be tweaked. This callable must return the object. If it returns None, the object is not added to the tar file. ---------- components: Library (Lib) messages: 92348 nosy: lars.gustaebel, tarek severity: normal status: open title: allow settong uid and gid when creating tar files type: feature request versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 17:46:48 2009 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 Sep 2009 15:46:48 +0000 Subject: [New-bugs-announce] [issue6857] float().__format__() default alignment In-Reply-To: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za> Message-ID: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za> New submission from Stefan Krah : format(float("0.12345"), "7.0") -> ' 0.1' The default alignment should be 'left-aligned'. ---------- messages: 92370 nosy: skrah severity: normal status: open title: float().__format__() default alignment versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 01:07:53 2009 From: report at bugs.python.org (gert cuykens) Date: Mon, 07 Sep 2009 23:07:53 +0000 Subject: [New-bugs-announce] [issue6858] This is a python file, apply syntax highlighting In-Reply-To: <1252364873.43.0.809885579905.issue6858@psf.upfronthosting.co.za> Message-ID: <1252364873.43.0.809885579905.issue6858@psf.upfronthosting.co.za> New submission from gert cuykens : http://groups.google.be/group/comp.lang.python/browse_thread/thread/252fa1ccd0251977# Menu option please, so I can highlight .wsgi .txt .xml files with python code in it, does not matter if non python code gets wrongly highlighted too. ---------- components: IDLE messages: 92395 nosy: gert severity: normal status: open title: This is a python file, apply syntax highlighting type: feature request versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 01:58:08 2009 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Sep 2009 23:58:08 +0000 Subject: [New-bugs-announce] [issue6859] stdint (eg. uint64_t) for ctypes In-Reply-To: <1252367888.87.0.134332885078.issue6859@psf.upfronthosting.co.za> Message-ID: <1252367888.87.0.134332885078.issue6859@psf.upfronthosting.co.za> New submission from STINNER Victor : It would be nice to have (at least) some stdint.h types in ctypes: - uint8_t, int8_t - int16_t, uint16_t - int32_t, uint32_t - uint64_t, int64_t Attached fle is a Python implementation of that. stdint.h contains much more types, but I don't think that (u)int_leastXX_t/(u)int_fastXX_t are used in public structures/functions. Other interesting types/constants from stdint.h: - intptr_t / uintptr_t - (U)INT(8|16|32|64)_(MIN|MAX) - PTRDIFF_MAX ---------- components: Extension Modules files: stdint.py messages: 92403 nosy: haypo severity: normal status: open title: stdint (eg. uint64_t) for ctypes type: feature request Added file: http://bugs.python.org/file14858/stdint.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 03:08:34 2009 From: report at bugs.python.org (=?utf-8?q?Patrick_N=C3=A4f?=) Date: Tue, 08 Sep 2009 01:08:34 +0000 Subject: [New-bugs-announce] [issue6860] Inconsistent naming of custom command in setup.py help output In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za> Message-ID: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za> New submission from Patrick N?f : The attached setup.py file defines a custom command named "test", which is implemented in a class named "TestClass". Try to run both of the following: 1) ./setup.py test -h 2) ./setup.py --help-commands In case 1, Distutils will use the class name to print the help output. In case 2, it will use the command name. This behaviour is inconsistent. As a developer, if I want to get the output right in both cases, I am forced to use the same name both for the command class and the command name (a string in a dictionary). I propose that Distutils always use the command name. Besides fixing the inconsistency, this solution gives the freedom to choose class names back to the developer. I have tested this behaviour on Mac OS X 10.5, both with the system-provided Python 2.5 and custom-installed versions of Python 2.6 and 3.1. ---------- assignee: tarek components: Distutils files: setup.py messages: 92405 nosy: herzbube, tarek severity: normal status: open title: Inconsistent naming of custom command in setup.py help output type: behavior versions: Python 2.5, Python 2.6, Python 3.1 Added file: http://bugs.python.org/file14859/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 03:56:16 2009 From: report at bugs.python.org (kai zhu) Date: Tue, 08 Sep 2009 01:56:16 +0000 Subject: [New-bugs-announce] [issue6861] bytearray.__new__ doesn't subclass In-Reply-To: <1252374976.15.0.672645211717.issue6861@psf.upfronthosting.co.za> Message-ID: <1252374976.15.0.672645211717.issue6861@psf.upfronthosting.co.za> New submission from kai zhu : # a00.py parent = bytearray # fails # parent = bytes # works # parent = str # works class Foo(parent): def __new__(klass, x): return parent.__new__(klass, x) Foo(x = None) $ python3.1 -c "import a00" Traceback (most recent call last): File "", line 1, in File "a00.py", line 11, in Foo(x = None) TypeError: 'x' is an invalid keyword argument for this function lethe 3 /tmp/kaizhu/Python-3.1.1: ---------- components: Interpreter Core, Library (Lib) messages: 92406 nosy: kaizhu severity: normal status: open title: bytearray.__new__ doesn't subclass type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 09:22:07 2009 From: report at bugs.python.org (john zeng) Date: Tue, 08 Sep 2009 07:22:07 +0000 Subject: [New-bugs-announce] [issue6862] exec(), locals() and local variable access In-Reply-To: <1252394527.99.0.612337784106.issue6862@psf.upfronthosting.co.za> Message-ID: <1252394527.99.0.612337784106.issue6862@psf.upfronthosting.co.za> New submission from john zeng : Can you help me understand why variable `u' is not accessible after exec()? Is this sort of a late binding issue? def test(v1): print(v1) print("Before exec(): " + str(locals())) exec(v1) print("After exec(): " + str(locals())) # This fails: # print(u) # This is workaround: en = locals()['u'] print(en) v1="u=4" test(v1) ---------- components: Interpreter Core messages: 92409 nosy: ooev severity: normal status: open title: exec(), locals() and local variable access type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:05:39 2009 From: report at bugs.python.org (=?utf-8?q?Pertti_Kellom=C3=A4ki?=) Date: Tue, 08 Sep 2009 13:05:39 +0000 Subject: [New-bugs-announce] [issue6863] Wrong linker command if CXX set to "ccache g++" In-Reply-To: <1252415139.67.0.192610915526.issue6863@psf.upfronthosting.co.za> Message-ID: <1252415139.67.0.192610915526.issue6863@psf.upfronthosting.co.za> New submission from Pertti Kellom?ki : If the compiler command in CXX contains more than one word, e.g. "ccache g++", line 256 in distutils/unixccompiler.py only picks the first word as the linker and discards the rest: linker[i] = self.compiler_cxx[i] On Ubuntu 9.04 the values of the variables are: (Pdb) print linker ['gcc', '-pthread', '-shared', '-Wl,-O1', '-Wl,-Bsymbolic-functions'] (Pdb) print self.compiler_cxx ['ccache', 'g++'] (Pdb) ---------- assignee: tarek components: Distutils messages: 92414 nosy: perttikellomaki, tarek severity: normal status: open title: Wrong linker command if CXX set to "ccache g++" type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:37:25 2009 From: report at bugs.python.org (dpogg1) Date: Tue, 08 Sep 2009 13:37:25 +0000 Subject: [New-bugs-announce] [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6 In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za> Message-ID: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za> New submission from dpogg1 : IDLE 2.6.1 locks up on Mac OS 10.6 when running using Apple's built-in version of Python (also 2.6.1) when creating a new buffer window or attempting to run/debug an existing file. ---------- assignee: ronaldoussoren components: IDLE, Macintosh messages: 92415 nosy: dpogg1, ronaldoussoren severity: normal status: open title: IDLE 2.6.1 locks up on Mac OS 10.6 type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 21:10:42 2009 From: report at bugs.python.org (caglar10ur) Date: Tue, 08 Sep 2009 19:10:42 +0000 Subject: [New-bugs-announce] [issue6865] Refcount error in pwd module In-Reply-To: <1252437042.03.0.0223574441717.issue6865@psf.upfronthosting.co.za> Message-ID: <1252437042.03.0.0223574441717.issue6865@psf.upfronthosting.co.za> New submission from caglar10ur : Fix refcounting problem which causes a segfault for following test code; -------------------------------------------------------- #include int main(void) { int i; for (i = 0; i < 1000; ++i) { Py_Initialize(); PyRun_SimpleString("import pwd\n"); Py_Finalize(); } return 0; } -------------------------------------------------------- Reported-by: Onur K???k Signed-off-by: S.?a?lar Onur ---------- files: pwdmodule_refcount_fix.patch keywords: patch messages: 92425 nosy: caglar10ur severity: normal status: open title: Refcount error in pwd module type: crash versions: Python 2.5 Added file: http://bugs.python.org/file14863/pwdmodule_refcount_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 22:03:50 2009 From: report at bugs.python.org (Mark Roddy) Date: Tue, 08 Sep 2009 20:03:50 +0000 Subject: [New-bugs-announce] [issue6866] TestLoader.loadTestsFromName does not use suiteClass attribute to create TestSuite instances In-Reply-To: <1252440230.46.0.994444389252.issue6866@psf.upfronthosting.co.za> Message-ID: <1252440230.46.0.994444389252.issue6866@psf.upfronthosting.co.za> New submission from Mark Roddy : The TestLoader class in unittest.py has an attribute 'suiteClass' that is used to create instances of TestSuite object(s) in the process of loading tests. If it is desired to subclass the TestSuite class then consumers may set this attribute on a TestLoader object in order to override what TestSuite class gets instantiated (a pythonic version of the factory method pattern). However, the loadTestsFromName() on the TestLoader class does not use this attribute to create TestSuite instances, and instead has a hard coded reference to the unittest.TestSuite class. This results in the base class being created instead of a possibly desired subclass that has been specified via this attribute. Solution for this issue is to change the loadTestsFromName() method to use the suiteClass attribute when creating TestSuite objects instead using a reference to the TestSuite class. Included is a patch that implements this behavior as well as two additional test for the test_unittest.py file which expose this issue if run against an unpatched version of unittest. ---------- components: Library (Lib) files: unittest.patch keywords: patch messages: 92427 nosy: MarkRoddy severity: normal status: open title: TestLoader.loadTestsFromName does not use suiteClass attribute to create TestSuite instances type: behavior versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file14864/unittest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 03:58:00 2009 From: report at bugs.python.org (shaowei.cui) Date: Wed, 09 Sep 2009 01:58:00 +0000 Subject: [New-bugs-announce] [issue6867] return value of epoll.register In-Reply-To: <1252461480.6.0.183531606536.issue6867@psf.upfronthosting.co.za> Message-ID: <1252461480.6.0.183531606536.issue6867@psf.upfronthosting.co.za> New submission from shaowei.cui : help(select.epoll) show 'register(fd[, eventmask]) -> bool', but it return 'None' actually. I view the source code of selectmodule.c that return None actually. The function "pyepoll_internal_ctl(int epfd, int op, PyObject *pfd, unsigned int events)" ---------- assignee: georg.brandl components: Documentation messages: 92440 nosy: georg.brandl, shaovie severity: normal status: open title: return value of epoll.register type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 04:13:11 2009 From: report at bugs.python.org (shaowei.cui) Date: Wed, 09 Sep 2009 02:13:11 +0000 Subject: [New-bugs-announce] [issue6868] Check errno of epoll_ctrl In-Reply-To: <1252462391.45.0.469283463386.issue6868@psf.upfronthosting.co.za> Message-ID: <1252462391.45.0.469283463386.issue6868@psf.upfronthosting.co.za> New submission from shaowei.cui : in selectmodule.c, I found the code of epoll module ' result = epoll_ctl(epfd, op, fd, &ev); if (errno == EBADF) { /* fd already closed */ result = 0; errno = 0; } ' 'man epoll_ctl' show 'EBADF epfd or fd is not a valid file descriptor.', assume I register an fd of 'open('xxx', O_RDONLY)', return value will be -1, errno will be EBADF, epoll not support 'file descriptors.' as i know, or i register an fd was not be opened. ---------- components: Library (Lib) messages: 92441 nosy: shaovie severity: normal status: open title: Check errno of epoll_ctrl type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 10:31:15 2009 From: report at bugs.python.org (Ilya) Date: Wed, 09 Sep 2009 08:31:15 +0000 Subject: [New-bugs-announce] [issue6869] Embedded python crashed on 4th run, if "ctypes" is used In-Reply-To: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za> Message-ID: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za> New submission from Ilya : When embedding python from C, and importing "ctypes" module in embedded script, it always crashes on Py_Finalize() on 4th cycle. Tested with both PyRun_SimpleString(...) and PyRun_String(...). Platform: Windows XP IDE's: LabWindows/CVI 8.5 and Code::Blocks/gcc Code: -------------------------- #include #include int main() { int i; for (i=0; i<10; i++) { printf("--- %d ---\n", i); Py_Initialize(); PyRun_SimpleString("import ctypes"); Py_Finalize(); } return 0; } -------------------------------- Output: -------------------------------- --- 0 --- --- 1 --- --- 2 --- --- 3 --- Process returned -1073741819 (0xC0000005) execution time : 3.109 s Press any key to continue. -------------------------------- ---------- assignee: theller components: ctypes messages: 92444 nosy: Warlock, theller severity: normal status: open title: Embedded python crashed on 4th run, if "ctypes" is used type: crash versions: Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 11:06:23 2009 From: report at bugs.python.org (Pravin Chavan) Date: Wed, 09 Sep 2009 09:06:23 +0000 Subject: [New-bugs-announce] [issue6870] sybase module for python3.1 In-Reply-To: <1252487183.35.0.803150529972.issue6870@psf.upfronthosting.co.za> Message-ID: <1252487183.35.0.803150529972.issue6870@psf.upfronthosting.co.za> New submission from Pravin Chavan : How can I use sybase module in python 3.1? ---------- components: Extension Modules messages: 92445 nosy: pravinpchavan severity: normal status: open title: sybase module for python3.1 type: feature request versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 18:07:22 2009 From: report at bugs.python.org (Stefan Krah) Date: Wed, 09 Sep 2009 16:07:22 +0000 Subject: [New-bugs-announce] [issue6871] decimal.py: more format issues In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za> Message-ID: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za> New submission from Stefan Krah : Hi, I've two more issues where format behavior should probably be identical: 1: (version 2.6 vs. 3.1): Version 2.6: >>> format(Decimal("NaN"), "+08.4") '+0000NaN' >>> format(float("NaN"), "+08.4") '+00.0nan' Version 3.1: >>> format(Decimal("NaN"), "+08.4") '+NaN ' >>> format(float("NaN"), "+08.4") '+0000nan' 2: (float vs. decimal): >>> format(float(123), "00") '123.0' >>> format(Decimal(123), "00") Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.1/decimal.py", line 3611, in __format__ spec = _parse_format_specifier(specifier, _localeconv=_localeconv) File "/usr/lib/python3.1/decimal.py", line 5563, in _parse_format_specifier raise ValueError("Invalid format specifier: " + format_spec) ValueError: Invalid format specifier: 00 ---------- messages: 92453 nosy: marketdickinson, skrah severity: normal status: open title: decimal.py: more format issues _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 21:03:28 2009 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 Sep 2009 19:03:28 +0000 Subject: [New-bugs-announce] [issue6872] Support system readline on OS X 10.6 In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za> Message-ID: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za> New submission from Mark Dickinson : The readline library supplied in OS X 10.6 looks good enough to use in Python. It would be nice to enable building with this library, to avoid having to install GNU readline. There's a curious off-by-one difference between Apple's readline (which, as I understand it, is just libedit wrapped to look like libreadline) and GNU readline: with 'n' history items, the valid indices for Apple's readline are 0 through n-1; for GNU they're 1 through n. I was able to get Python trunk + system readline working on OS X 10.6 using the attached patch (which obviously isn't suitable for applying, since it breaks the build with a non-system readline). A side effect of the patch is that readline.get_history_item and friends store the first history entry with index 0 rather than 1: Python 2.7a0 (trunk:74735M, Sep 9 2009, 19:40:25) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import readline [39474 refs] >>> readline.get_history_item(0) 'import readline' [39476 refs] >>> readline.get_history_item(2) 'readline.get_history_item(2)' [39476 refs] Interestingly, the Apple-supplied Python also behaves this way: Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ python Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import readline >>> readline.get_history_item(0) 'import readline' >>> readline.get_history_item(2) 'readline.get_history_item(2)' If people think this is worth pursuing, I'll put together a proper patch. ---------- assignee: ronaldoussoren components: Build, Extension Modules, Macintosh messages: 92457 nosy: marketdickinson, ronaldoussoren severity: normal status: open title: Support system readline on OS X 10.6 type: feature request versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 23:01:23 2009 From: report at bugs.python.org (Boya Sun) Date: Wed, 09 Sep 2009 21:01:23 +0000 Subject: [New-bugs-announce] [issue6873] posix_lchown: possible overflow of uid, gid In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za> Message-ID: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za> New submission from Boya Sun : posix_lchown(PyObject *self, PyObject *args) { ... int uid, gid; ... if (!PyArg_ParseTuple(args, "etii:lchown", Py_FileSystemDefaultEncoding, &path, &uid, &gid)) ... } uid and gid could cause over flow. A similar bug is issue 5705. Patch attached. Any comment is appreciated! Boya ---------- files: patch.diff keywords: patch messages: 92465 nosy: boya severity: normal status: open title: posix_lchown: possible overflow of uid, gid Added file: http://bugs.python.org/file14869/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 08:46:24 2009 From: report at bugs.python.org (s7v7nislands) Date: Thu, 10 Sep 2009 06:46:24 +0000 Subject: [New-bugs-announce] [issue6874] sequence method .count() and .index() shoud be in immutable sequence method list. In-Reply-To: <1252565184.5.0.887138864217.issue6874@psf.upfronthosting.co.za> Message-ID: <1252565184.5.0.887138864217.issue6874@psf.upfronthosting.co.za> New submission from s7v7nislands : In document 6.6.4. Mutable Sequence Types says: The following operations are defined on mutable sequence types: s.count(x) return number of i?s for which s[i] == x s.index(x[, i[, j]]) return smallest k such that s[k] == x and i <= k < j (4) here, s.count() and s.index() maybe should in immutable sequence types operations list. ---------- assignee: georg.brandl components: Documentation messages: 92471 nosy: georg.brandl, s7v7nislands severity: normal status: open title: sequence method .count() and .index() shoud be in immutable sequence method list. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 13:47:05 2009 From: report at bugs.python.org (Vincent Legoll) Date: Thu, 10 Sep 2009 11:47:05 +0000 Subject: [New-bugs-announce] [issue6875] add os.close() suggestion to mkstemp documentation In-Reply-To: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za> Message-ID: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za> New submission from Vincent Legoll : As per the blog entry http://www.logilab.org/blogentry/17873 I think the tempfile.mkstemp() documentation could be more helpful by suggesting the use of os.close() appropriately. If some native english speaker could give a review of the language I used in the additional text, I'd be grateful. ---------- assignee: georg.brandl components: Documentation files: python-doc-mkstemp.patch keywords: patch messages: 92477 nosy: georg.brandl, vincele severity: normal status: open title: add os.close() suggestion to mkstemp documentation type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file14870/python-doc-mkstemp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 13:49:04 2009 From: report at bugs.python.org (Stefan Schwarzburg) Date: Thu, 10 Sep 2009 11:49:04 +0000 Subject: [New-bugs-announce] [issue6876] readline documentation example error In-Reply-To: <1252583344.25.0.0380300575414.issue6876@psf.upfronthosting.co.za> Message-ID: <1252583344.25.0.0380300575414.issue6876@psf.upfronthosting.co.za> New submission from Stefan Schwarzburg : In the last example in the readline documentation (http://docs.python.org/library/readline.html), the line code.InteractiveConsole.__init__(self) should be changed to code.InteractiveConsole.__init__(self, locals, filename) to work properly. ---------- assignee: georg.brandl components: Documentation messages: 92478 nosy: georg.brandl, schwarz severity: normal status: open title: readline documentation example error versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 14:38:29 2009 From: report at bugs.python.org (Zvezdan Petkovic) Date: Thu, 10 Sep 2009 12:38:29 +0000 Subject: [New-bugs-announce] [issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6 In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za> Message-ID: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za> New submission from Zvezdan Petkovic : The attached patch enables compilation and use of the readline module on Mac OS X 10.5 (Leopard) and 10.6 (Snow Leopard). It utilizes the native editline library (used for emulation of the readline library on Mac). I used the patch for almost two years already with Python 2.4 and since December 2008 with Python 2.6. The only difference is that Python 2.4 did not need the setup.py changes. The patch is written in such a way that it does *not* affect the compilation on systems that use GNU readline library (e.g., Linux). However, I don't have access to any other system that uses editline emulation of readline library besides Mac. I believe it should work the same but some testing would be welcome if anyone is aware of such a system (NetBSD?). With the readline module compiled in, it is enough to put in .editrc python:bind -v and one gets a vi emulation in the python interactive interpreter. You can also try it directly from the shell: >>> import readline >>> readline.parse_and_bind("bind -v") >>> # use editing features to change the lines above to >>> import rlcompleter >>> readline.parse_and_bind("bind ^I rl_complete") >>> # now TAB offers the completions It would be nice if we could get this included into Python-2.6.3 release. ---------- components: Build files: readline-trunk.patch keywords: patch messages: 92480 nosy: zvezdan severity: normal status: open title: enable compilation of readline module on Mac OS X 10.5 and 10.6 type: compile error versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14871/readline-trunk.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 19:25:08 2009 From: report at bugs.python.org (SilentGhost) Date: Thu, 10 Sep 2009 17:25:08 +0000 Subject: [New-bugs-announce] [issue6878] outdated docstring in tkinter.Canvas.coords In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za> Message-ID: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za> New submission from SilentGhost : Doc string for tkinter/__init__.py Canvas.coords (line 2115 in python3.1.1) reads: """Return a list of coordinates for the item given in ARGS.""" actual code: return map(...etc...) I actually don't know whether it's an outdated docstring, may be coords should return a tuple. ---------- components: Tkinter messages: 92495 nosy: SilentGhost severity: normal status: open title: outdated docstring in tkinter.Canvas.coords versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 03:35:46 2009 From: report at bugs.python.org (Gene Ratzlaff) Date: Fri, 11 Sep 2009 01:35:46 +0000 Subject: [New-bugs-announce] [issue6879] misstatement in example explanation using raise In-Reply-To: <1252632946.18.0.482571861035.issue6879@psf.upfronthosting.co.za> Message-ID: <1252632946.18.0.482571861035.issue6879@psf.upfronthosting.co.za> New submission from Gene Ratzlaff : v2.6.2 Python Tutorial http://docs.python.org/tutorial/errors.html#raising-exceptions Section 8. Errors and Exceptions 8.4. Raising Exceptions It appears that in the example, the original may have been: raise(NameError('HiThere')) and was then changed to raise NameError('HiThere') but the explanation was not changed accordingly. The current state and my suggested change are found below, respectively: Currently: """ >>> raise NameError('HiThere') Traceback (most recent call last): File "", line 1, in ? NameError: HiThere The first argument to raise names the exception to be raised. The optional second argument specifies the exception?s argument. Alternatively, the above could be written as raise NameError('HiThere'). Either form works fine, but there seems to be a growing stylistic preference for the latter. """ Suggest change to: """ >>> raise NameError('HiThere') Traceback (most recent call last): File "", line 1, in ? NameError: HiThere The first argument to raise names the exception to be raised. The optional second argument specifies the exception?s argument. Alternatively, the above could be written as raise(NameError('HiThere')). Either form works fine, but there seems to be a growing stylistic preference for the former. """ ---------- assignee: georg.brandl components: Documentation messages: 92501 nosy: bluebloodpole, georg.brandl severity: normal status: open title: misstatement in example explanation using raise versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 03:46:15 2009 From: report at bugs.python.org (Gene Ratzlaff) Date: Fri, 11 Sep 2009 01:46:15 +0000 Subject: [New-bugs-announce] [issue6880] class needs forward reference In-Reply-To: <1252633575.43.0.606508097483.issue6880@psf.upfronthosting.co.za> Message-ID: <1252633575.43.0.606508097483.issue6880@psf.upfronthosting.co.za> New submission from Gene Ratzlaff : http://docs.python.org/tutorial/errors.html#user-defined-exceptions class mechanism used in 8.5 before classes are explained in chapter 9. Suggest first use of word "class" be a forward link to "9. Classes": http://docs.python.org/tutorial/classes.html#classes ---------- assignee: georg.brandl components: Documentation messages: 92502 nosy: bluebloodpole, georg.brandl severity: normal status: open title: class needs forward reference type: feature request versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 11:24:44 2009 From: report at bugs.python.org (egreen) Date: Fri, 11 Sep 2009 09:24:44 +0000 Subject: [New-bugs-announce] [issue6881] incorrect signature in doc for PyByteArray_Resize In-Reply-To: <1252661084.46.0.992588228962.issue6881@psf.upfronthosting.co.za> Message-ID: <1252661084.46.0.992588228962.issue6881@psf.upfronthosting.co.za> New submission from egreen : in Doc/c-api/bytearray.rst: PyObject* PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len) should be: int PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len) as per Include/bytearrayobject.h ---------- assignee: georg.brandl components: Documentation messages: 92506 nosy: egreen, georg.brandl severity: normal status: open title: incorrect signature in doc for PyByteArray_Resize versions: Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 11:59:13 2009 From: report at bugs.python.org (Dirk Haage) Date: Fri, 11 Sep 2009 09:59:13 +0000 Subject: [New-bugs-announce] [issue6882] uuid creates zombies In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za> Message-ID: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za> New submission from Dirk Haage : a simple import uuid will always result in a zombie sh process: $ python3 Python 3.1.1 (r311:74480, Aug 19 2009, 16:23:08) [GCC 4.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import uuid >>> 13528 pts/5 Ss 0:01 \_ bash 18349 pts/5 S+ 0:00 | \_ python3 18352 pts/5 Z+ 0:00 | \_ [sh] confirmed on ubuntu and gentoo with various python3.0 - 3.1.1 builds ---------- messages: 92507 nosy: dhg severity: normal status: open title: uuid creates zombies versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 16:26:28 2009 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 11 Sep 2009 14:26:28 +0000 Subject: [New-bugs-announce] [issue6883] OptionParser.allow_interspersed_args is undocumented In-Reply-To: <60bb7ceb0909110726i738a484ck1b1ca3a31f6ea91b@mail.gmail.com> Message-ID: <60bb7ceb0909110726i738a484ck1b1ca3a31f6ea91b@mail.gmail.com> New submission from Skip Montanaro : The OptionParser.allow_interspersed_args attribute is undocumented in the Sphinx documentation. (It is mentioned in the OptionParser docstring.) By its name it appears to actually part of the official API, so should at least be mentioned in the rst file. ---------- messages: 92510 nosy: skip.montanaro severity: normal status: open title: OptionParser.allow_interspersed_args is undocumented _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 16:28:28 2009 From: report at bugs.python.org (Chris Withers) Date: Fri, 11 Sep 2009 14:28:28 +0000 Subject: [New-bugs-announce] [issue6884] Impossible to include file in sdist that starts with 'build' on Win32 In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za> Message-ID: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za> New submission from Chris Withers : With a simple setup.py: from distutils.core import setup setup(name='packagename') And a MANIFEST.in containing: include buildout.cfg The result of a debug run of python setup.py sdist on Windows is: Distribution.parse_config_files(): options (after parsing config files): no commands known yet options (after parsing command line): option dict for 'sdist' command: {} running sdist Distribution.get_command_obj(): creating 'sdist' command object warning: sdist: missing required meta-data: version, url warning: sdist: missing meta-data: either (author and author_email) or (maintainer and maintainer_email) mus t be supplied checking if setup.py newer than MANIFEST warning: sdist: standard file not found: should have one of README, README.txt reading manifest template 'MANIFEST.in' include buildout.cfg include_pattern: applying regex r'^buildout\.cfg$' adding buildout.cfg Distribution.get_command_obj(): creating 'build' command object exclude_pattern: applying regex r'^build\.*' removing buildout.cfg ... The regex built is incorrect, although it is apparently correctly built on other platforms... ---------- assignee: tarek messages: 92511 nosy: cjw296, tarek priority: normal severity: normal stage: test needed status: open title: Impossible to include file in sdist that starts with 'build' on Win32 type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 20:45:55 2009 From: report at bugs.python.org (Mitchell Model) Date: Fri, 11 Sep 2009 18:45:55 +0000 Subject: [New-bugs-announce] [issue6885] pdb documentation shows running as script using "python" not "python3" In-Reply-To: <1252694755.95.0.997731708213.issue6885@psf.upfronthosting.co.za> Message-ID: <1252694755.95.0.997731708213.issue6885@psf.upfronthosting.co.za> New submission from Mitchell Model : The library documentation page for pdb shows running pdb as a script using the command python -m pdb Shouldn't that be python3 -m pdb ? ---------- assignee: georg.brandl components: Documentation messages: 92515 nosy: MLModel, georg.brandl severity: normal status: open title: pdb documentation shows running as script using "python" not "python3" versions: Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 21:01:57 2009 From: report at bugs.python.org (Mitchell Model) Date: Fri, 11 Sep 2009 19:01:57 +0000 Subject: [New-bugs-announce] [issue6886] cgi.py runs python, not python3 In-Reply-To: <1252695717.33.0.0393751627357.issue6886@psf.upfronthosting.co.za> Message-ID: <1252695717.33.0.0393751627357.issue6886@psf.upfronthosting.co.za> New submission from Mitchell Model : The file cgi.py in the lib directory is an executable beginning with the line: #! /usr/local/bin/python Shouldn't that be python3? ---------- components: Library (Lib) messages: 92517 nosy: MLModel severity: normal status: open title: cgi.py runs python, not python3 versions: Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 21:04:36 2009 From: report at bugs.python.org (Mitchell Model) Date: Fri, 11 Sep 2009 19:04:36 +0000 Subject: [New-bugs-announce] [issue6887] executables in lib use /usr/bin/env python, not python3 In-Reply-To: <1252695876.75.0.468012953798.issue6887@psf.upfronthosting.co.za> Message-ID: <1252695876.75.0.468012953798.issue6887@psf.upfronthosting.co.za> New submission from Mitchell Model : Some of the executables in lib begin with the line: #! /usr/bin/env python Shouldn't that be python3? ---------- components: Library (Lib) messages: 92518 nosy: MLModel severity: normal status: open title: executables in lib use /usr/bin/env python, not python3 versions: Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 22:21:15 2009 From: report at bugs.python.org (Mitchell Model) Date: Fri, 11 Sep 2009 20:21:15 +0000 Subject: [New-bugs-announce] [issue6888] pdb alias command with no arguments is broken In-Reply-To: <1252700475.39.0.749180351016.issue6888@psf.upfronthosting.co.za> Message-ID: <1252700475.39.0.749180351016.issue6888@psf.upfronthosting.co.za> New submission from Mitchell Model : Typing just alias in pdb doesn't work. Because dict.keys() now returns a dict_keys object instead of a list the line keys.sort() in Pdb.do_alias breaks because dict_keys doesn't have a sort method. ---------- components: Library (Lib) messages: 92522 nosy: MLModel severity: normal status: open title: pdb alias command with no arguments is broken versions: Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 22:34:10 2009 From: report at bugs.python.org (flox) Date: Fri, 11 Sep 2009 20:34:10 +0000 Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlNjg4OV0gwqtQeXRob27igJlz?= =?utf-8?q?_default_encoding_is_the_=E2=80=98ascii=E2=80=99_encoding=2E?= =?utf-8?b?wrs=?= In-Reply-To: <1252701250.82.0.768270765436.issue6889@psf.upfronthosting.co.za> Message-ID: <1252701250.82.0.768270765436.issue6889@psf.upfronthosting.co.za> New submission from flox : In the Python ?Unicode HOWTO?, we still read the statement: ?For example, Python's default encoding is the 'ascii' encoding.? Here: http://svn.python.org/view/python/branches/py3k/Doc/howto/unicode.rst?revision=72294&view=markup ---------- assignee: georg.brandl components: Documentation messages: 92523 nosy: flox, georg.brandl severity: normal status: open title: ?Python?s default encoding is the ?ascii? encoding.? versions: Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 22:50:44 2009 From: report at bugs.python.org (Michael Foord) Date: Fri, 11 Sep 2009 20:50:44 +0000 Subject: [New-bugs-announce] [issue6890] IOError has no __unicode__ method - and loses information In-Reply-To: <1252702244.44.0.0923996310102.issue6890@psf.upfronthosting.co.za> Message-ID: <1252702244.44.0.0923996310102.issue6890@psf.upfronthosting.co.za> New submission from Michael Foord : >>> try: ... open('flooble') ... except Exception as e: ... pass ... [39343 refs] >>> str(e) "[Errno 2] No such file or directory: 'flooble'" [39345 refs] >>> unicode(e) u"(2, 'No such file or directory')" The Unicode representation of an IOError has no information about the file or directory name. This is a regression from 2.5. Would be nice to backport a fix to 2.6 if we can. This bit docutils - and can happen as a side-effect of interpolating into a Unicode string with %s. The filename information is lost from the error report. ---------- components: IO keywords: 26backport messages: 92525 nosy: michael.foord severity: normal status: open title: IOError has no __unicode__ method - and loses information versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 23:15:50 2009 From: report at bugs.python.org (flox) Date: Fri, 11 Sep 2009 21:15:50 +0000 Subject: [New-bugs-announce] =?utf-8?q?=5Bissue6891=5D_small_typo_in_?= =?utf-8?q?=C2=ABunicode=2Erst=C2=BB=3A_=C2=ABthe_Uniode_APIs_should_be_us?= =?utf-8?q?ed=C2=BB_and_broken_URL?= In-Reply-To: <1252703750.59.0.33036975142.issue6891@psf.upfronthosting.co.za> Message-ID: <1252703750.59.0.33036975142.issue6891@psf.upfronthosting.co.za> New submission from flox : Found 2 typos: - Uniode instead of Unicode - Acknowledgements instead of Acknowledgments And the following reference is broken (Jason Orendorff website): http://www.jorendorff.com/articles/unicode/ The last version is dated 2007 on the wayback machine: http://web.archive.org/web/*/www.jorendorff.com/articles/unicode/index.html Relevant file is: Doc/howto/unicode.rst ---------- assignee: georg.brandl components: Documentation messages: 92526 nosy: flox, georg.brandl severity: normal status: open title: small typo in ?unicode.rst?: ?the Uniode APIs should be used? and broken URL versions: Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 04:13:00 2009 From: report at bugs.python.org (Mitchell Model) Date: Sat, 12 Sep 2009 02:13:00 +0000 Subject: [New-bugs-announce] [issue6892] optparser example in optparse documentation is broken In-Reply-To: <1252721580.94.0.672952462459.issue6892@psf.upfronthosting.co.za> Message-ID: <1252721580.94.0.672952462459.issue6892@psf.upfronthosting.co.za> New submission from Mitchell Model : The help example in the middle of the optparse library documentation is broken. The code reads: parser = OptionParser() parser.add_option("-h", "--help", action="help"), parser.add_option("-v", action="store_true", dest="verbose", help="Be moderately verbose") parser.add_option("--file", dest="filename", help="Input file to read data from"), The result of executing this code is: optparse.OptionConflictError: option -h/--help: conflicting option string(s): -h, --help I see that the documentation says that normally help is added automatically so you don't need to do it, but doing so shouldn't break especially since the example shows doing it. Also, the trailing commas on two of the lines are weird and should be removed. ---------- assignee: georg.brandl components: Documentation messages: 92530 nosy: MLModel, georg.brandl severity: normal status: open title: optparser example in optparse documentation is broken versions: Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 05:03:43 2009 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 12 Sep 2009 03:03:43 +0000 Subject: [New-bugs-announce] [issue6893] defaultdict example in py3 doc should mention the new Counter class In-Reply-To: <1252724623.36.0.815888015467.issue6893@psf.upfronthosting.co.za> Message-ID: <1252724623.36.0.815888015467.issue6893@psf.upfronthosting.co.za> New submission from Ezio Melotti : The 3rd example of defaultdict [1] shows how to use it to count the letters of a string, but the new Counter class is a better tool for doing that. Possible solutions: 1) "Setting the default_factory to int makes the defaultdict useful for counting (like a bag or multiset in other languages):" -> "Setting the default_factory to int makes the defaultdict useful for basic counting (see also the Counter class for more features):"; 2) remove the example. [1]: http://docs.python.org/dev/py3k/library/collections.html#defaultdict-examples ---------- assignee: georg.brandl components: Documentation messages: 92534 nosy: ezio.melotti, georg.brandl, rhettinger priority: low severity: normal status: open title: defaultdict example in py3 doc should mention the new Counter class versions: Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 12:12:29 2009 From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_Barrois?=) Date: Sat, 12 Sep 2009 10:12:29 +0000 Subject: [New-bugs-announce] [issue6894] urllib2 doesn't respect "no_proxy" environment (python2.6.2) In-Reply-To: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za> Message-ID: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za> New submission from Rapha?l Barrois : I discovered recently that urllib2 doesn't respect the "no_proxy" environment variable on linux (and on other platforms too, I think). Here is an example of the problem : - Set http_proxy and no_proxy environment variables (for instance no_proxy="localhost") proxy_handler = urllib2.ProxyHandler() opener = urllib2.build_opener(proxy_handler) urllib2.install_opener(opener) and then open an "outside" url : everything is OK (urllib2 reads correctly http_proxy), but for "localhost", it tries to open it through the proxy. You would expect urllib2 to understand no_proxy, all the more since all the needed code is already available in urllib. I have prepared a patch for urllib2 which does correct that bug. I don't have other versions of python installed, so I couldn't check that se bug is still present there. ---------- components: Library (Lib) files: python2.6.2-urllib2-no_proxy.patch keywords: patch messages: 92538 nosy: xelnor severity: normal status: open title: urllib2 doesn't respect "no_proxy" environment (python2.6.2) type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14880/python2.6.2-urllib2-no_proxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 16:26:58 2009 From: report at bugs.python.org (Santhosh Thottingal) Date: Sat, 12 Sep 2009 14:26:58 +0000 Subject: [New-bugs-announce] [issue6895] locale._parse_localename fails when localename does not contain encoding information In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za> Message-ID: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za> New submission from Santhosh Thottingal : locale._parse_localename fails when the locale name is in xx_YY format. For example when the system locale is Malayalam(India), ml_IN we get the following result >>> locale._parse_localename("ml_IN") Traceback (most recent call last): File "", line 1, in File "/opt/python311/lib/python3.1/locale.py", line 424, in _parse_localename raise ValueError('unknown locale: %s' % localename) ValueError: unknown locale: ml_IN The expected result is ('ml_IN', None) For Latin languages, locale.py assumes iso-8859-15 as the encoding type if encoding type is not given in localename. In case of other locales, None can be returned for encoding type. Attached patch fixes this. The result after applying patch to locale.py >>> import locale >>> locale._parse_localename("ml_IN") ('ml_IN', None) ---------- components: Library (Lib) files: locale.py-parselocale-patch.diff keywords: patch messages: 92546 nosy: santhosh.thottingal severity: normal status: open title: locale._parse_localename fails when localename does not contain encoding information type: crash versions: Python 3.1 Added file: http://bugs.python.org/file14881/locale.py-parselocale-patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 20:15:14 2009 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 12 Sep 2009 18:15:14 +0000 Subject: [New-bugs-announce] [issue6896] Intermittent failures in test_mailbox In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za> Message-ID: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za> New submission from Ezio Melotti : While running test.regrtest, test_mailbox failed with the error: test test_mailbox failed -- Traceback (most recent call last): File "/home/wolf/py3k/Lib/test/test_mailbox.py", line 116, in test_discard self.assertEqual(len(self._box), 1) AssertionError: 2 != 1 I ran the test again several times and got intermittent failures in several different methods. Attached there's a file with the errors I got. During the first tests I was running test_mailbox after test_zipimport, but then I was able to reproduce the failures running test_mailbox alone. I'm using Python 3.2a0 on Ubuntu 8.04. ---------- components: Tests files: mailboxfailures.txt messages: 92550 nosy: ezio.melotti priority: normal severity: normal status: open title: Intermittent failures in test_mailbox type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file14882/mailboxfailures.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 22:05:58 2009 From: report at bugs.python.org (geremy condra) Date: Sat, 12 Sep 2009 20:05:58 +0000 Subject: [New-bugs-announce] [issue6897] imaplib fails during login In-Reply-To: <1252785958.65.0.870328470051.issue6897@psf.upfronthosting.co.za> Message-ID: <1252785958.65.0.870328470051.issue6897@psf.upfronthosting.co.za> New submission from geremy condra : Getting the following issue- this code: #! /usr/bin/env python3 import getpass, imaplib M = imaplib.IMAP4_SSL("imap.gmail.com") M.login(, ) M.select() typ, data = M.search(None, 'ALL') for num in data[0].split(): typ, data = M.fetch(num, '(RFC822)') print('Message %s\n%s\n' % (num, data[0][1])) M.close() M.logout() taken almost verbatim from the documentation, produces this error: Traceback (most recent call last): File "./imaptest.py", line 6, in M.login(, ) File "/usr/lib/python3.0/imaplib.py", line 514, in login typ, dat = self._simple_command('LOGIN', user, self._quote(password)) File "/usr/lib/python3.0/imaplib.py", line 1072, in _quote arg = arg.replace(b'\\', b'\\\\') TypeError: Can't convert 'bytes' object to str implicitly username and password obviously redeacted. Changing imaplib.py's _quote function to this: def _quote(self, arg): arg = arg.replace('\\', '\\\\') arg = arg.replace('"', '\\"') return '"' + arg + '"' seems to resolve the issue. ---------- components: Library (Lib) messages: 92552 nosy: debatem1 severity: normal status: open title: imaplib fails during login versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 02:57:33 2009 From: report at bugs.python.org (vitvn) Date: Sun, 13 Sep 2009 00:57:33 +0000 Subject: [New-bugs-announce] [issue6898] Unicode Error In-Reply-To: <1252803453.94.0.767926898591.issue6898@psf.upfronthosting.co.za> Message-ID: <1252803453.94.0.767926898591.issue6898@psf.upfronthosting.co.za> New submission from vitvn : >>>viet= "? ? ? ? ? ? ? ? ? ? ? " >>>print(viet) Traceback (most recent call last): File "tiengviet.py", line 4, in print(viet) File "I:\python\python.v3.1_portable\App\lib\encodings\cp1252.py", line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_table)[0] UnicodeEncodeError: 'charmap' codec can't encode character '\u0103' in position 2: character maps to >Exit code: 1 how to fix it ? ---------- components: Unicode messages: 92557 nosy: vitvn severity: normal status: open title: Unicode Error versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 10:50:41 2009 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Sep 2009 08:50:41 +0000 Subject: [New-bugs-announce] [issue6899] Base.replace breaks tree In-Reply-To: <1252831841.16.0.893335369907.issue6899@psf.upfronthosting.co.za> Message-ID: <1252831841.16.0.893335369907.issue6899@psf.upfronthosting.co.za> New submission from Martin v. L?wis : In Base.replace, the method checks that self.parent is not None - however, it (unfortunately), breaks this very property itself if self is new, or self in new. In particular, some fixers return node from transform if they don't want to do anything. In that case, self.parent gets set to None, even though new (which is self) is still connected to the tree. This patch a) short-cuts the case that self is new b) arranges to set parent of the new nodes only after clearing parent of self ---------- components: 2to3 (2.x to 3.0 conversion tool) files: python.patch keywords: patch messages: 92563 nosy: loewis severity: normal status: open title: Base.replace breaks tree Added file: http://bugs.python.org/file14883/python.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 14:06:51 2009 From: report at bugs.python.org (Tom Seddon) Date: Sun, 13 Sep 2009 12:06:51 +0000 Subject: [New-bugs-announce] [issue6900] Sub-optimal "Locate" button behaviour in Windows CHM file In-Reply-To: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za> Message-ID: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za> New submission from Tom Seddon : Behaviour of "Locate" in latest Windows CHM file for Python 2.6.2 is sub-optimal. I first spotted this with the optparse module, so this bug refers to the optparse module. It looks as if this is a global problem, though. First, ensure one has latest patched Python 2.6.2 CHM file. Sample repro steps: - Load Windows CHM file (observe fully collapsed contents tree); - Select "Global Module Index" in contents tree (note availability of "Locate" button); - Click "O" link; - Click "optparse" link. Note that contents remains collapsed and "Locate" button is unavailable. This makes navigating through the page a bit tiring. The Find functionality in the CHM viewer isn't great. Also try: - Load Windows CHM file; - Select Index; - Enter "optparse" in keyword field; - Select "optparse (module)" entry in index. Note lack of Locate button. This looks to be the same thing as selecting optparse from the module index (as it maybe is). Also try: - Load Windows CHM file; - Expand "The Python Standard Library" folder in contents; - ...expand "Generic Operating System Services" folder in contents; - Click "optparse --- More powerful command line option parser" folder in contents (note optparse page appears again, but this time you can see the location line at the top, and Locate button remains available); If one then collapses the "The Python Standard Library" folder, one is then almost where one was in the first set of steps. This time, though, one may click "Locate" to find the entry in the contents so that the page is a bit easier to navigate. Also try: - Load Windows CHM file; - Select "Global Module Index" from content; - Click "C" link; - Select "Carbon.AE" link (note availability of Locate button). In this case, the Locate button IS available. Same goes for some other sub-libraries -- e.g. compiler.ast and wsgiref.handlers -- but not all -- e.g., xml.dom. Expected behaviour: When navigating to any module's doc page from its entry in the global module index, or its entry in the index, or indeed by following any link in the docs, it should be possible to click "Locate" to find it in the contents tree. The document search facilities in the CHM viewer are a bit lame, so having the contents tree at hand is very useful (I might say essential -- but that could just be me). (This was less of an issue in previous versions of the docs, because the pages were split up into parts, so one could use Back once or twice to get to the contents then click a link to go straight to the desired section.) Thanks. ---------- assignee: georg.brandl components: Documentation messages: 92565 nosy: georg.brandl, tom_seddon severity: normal status: open title: Sub-optimal "Locate" button behaviour in Windows CHM file type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 20:10:50 2009 From: report at bugs.python.org (Bernie H. Innocenti) Date: Sun, 13 Sep 2009 18:10:50 +0000 Subject: [New-bugs-announce] [issue6901] Runaway programs often become unresponsive to CTRL-C In-Reply-To: <1252865450.5.0.145838694096.issue6901@psf.upfronthosting.co.za> Message-ID: <1252865450.5.0.145838694096.issue6901@psf.upfronthosting.co.za> New submission from Bernie H. Innocenti : On startup, the Python interpreter changes the default behavior of SIGINT, which results in many Python programs to ignore the keyboard interrupt exactly in the situations when users are most likely to use it (i.e.: when the program becomes unresponsive). Minimal testcase: $ echo "void foo() { for(;;) {} }" >foo.c $ gcc -shared -o foo.so foo.c $ python -c 'import ctypes;ctypes.CDLL("./foo.so").foo()' ^C^C^C ^C ^C DAMN! ^C This scenario mimics a Python program calling some blocking library function. It can also happen with IO-bound functions if they loop on read() and don't abort on short reads. One might be tempted to say "this behavior of the Python intepreter is by design" and suggest users to use CTRL-\ instead of CTRL-C. However, this non-standard behavior is very annoying for users who expect ^C to work on UNIX systems. In fact, no other compiled or interpreted language I know of behaves this way, and Python should not be the only exception. While I see the usefulness of KeyboardInterrupt from the programmer point of view, only a minority of programs actually need to trap SIGINT and do something with it. Other language runtimes require the programmer to manually trap SIGINT when needed. The Python interpreter could maintain backwards compatibility by enabling automatic SIGINT trapping when entering a "try" block that would intercept KeyboardInterrupt. ---------- components: Interpreter Core messages: 92576 nosy: bernie severity: normal status: open title: Runaway programs often become unresponsive to CTRL-C versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 01:36:44 2009 From: report at bugs.python.org (Eric Smith) Date: Sun, 13 Sep 2009 23:36:44 +0000 Subject: [New-bugs-announce] [issue6902] Built-in types format incorrectly with 0 padding. In-Reply-To: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za> Message-ID: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za> New submission from Eric Smith : Originally discussed in issue 6871. Even if an alignment of "<" is specified, "=" is used if the padding character is "0". >>> format(2, '0<20') '00000000000000000002' >>> format(2, '1<20') '21111111111111111111' This is a problem for at least float and integers. This should probably be backported to 2.6 and 3.1, but I'll have to wait and see how invasive the patch is. ---------- assignee: eric.smith components: Interpreter Core messages: 92586 nosy: eric.smith, marketdickinson, skrah priority: normal severity: normal status: open title: Built-in types format incorrectly with 0 padding. versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 02:18:25 2009 From: report at bugs.python.org (Mitchell Model) Date: Mon, 14 Sep 2009 00:18:25 +0000 Subject: [New-bugs-announce] [issue6903] pdb - print in for iteration prints None after printing In-Reply-To: <1252887505.82.0.273261288247.issue6903@psf.upfronthosting.co.za> Message-ID: <1252887505.82.0.273261288247.issue6903@psf.upfronthosting.co.za> New submission from Mitchell Model : Near the bottom of the library documentation for pdb there is an example of a very useful alias: alias pi for k in %1.__dict__.keys(): print("%1.",k,"=",%1.__dict__[k]) It turns out that doing print in a for loop in pdb results in None being printed on a line after each print. For example: (Pdb) for n in range(3): print(n) 0 None 1 None 2 None (Pdb) Seems like a (minor) bug, but if not, the example should be removed or replaced in the documentation. ---------- assignee: georg.brandl components: Documentation, Library (Lib) messages: 92588 nosy: MLModel, georg.brandl severity: normal status: open title: pdb - print in for iteration prints None after printing versions: Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 02:37:25 2009 From: report at bugs.python.org (Thijs Triemstra) Date: Mon, 14 Sep 2009 00:37:25 +0000 Subject: [New-bugs-announce] [issue6904] Broken URL for pyqt In-Reply-To: <1252888645.97.0.828426454306.issue6904@psf.upfronthosting.co.za> Message-ID: <1252888645.97.0.828426454306.issue6904@psf.upfronthosting.co.za> New submission from Thijs Triemstra : using/mac.html#gui-programming-on-the-mac refers to http://www.riverbankcomputing.co.uk/pyqt/ but this should be http://www.riverbankcomputing.co.uk/software/pyqt ---------- assignee: georg.brandl components: Documentation messages: 92589 nosy: georg.brandl, thijs severity: normal status: open title: Broken URL for pyqt versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 05:54:51 2009 From: report at bugs.python.org (Yuv Gre) Date: Mon, 14 Sep 2009 03:54:51 +0000 Subject: [New-bugs-announce] [issue6905] inspect.getargspec(print) fails In-Reply-To: <1252900491.43.0.484997315775.issue6905@psf.upfronthosting.co.za> Message-ID: <1252900491.43.0.484997315775.issue6905@psf.upfronthosting.co.za> New submission from Yuv Gre : >>> import inspect >>> inspect.getargspec(print) Traceback (most recent call last): File "", line 1, in File "F:\Python31\lib\inspect.py", line 787, in getargspec getfullargspec(func) File "F:\Python31\lib\inspect.py", line 814, in getfullargspec raise TypeError('arg is not a Python function') TypeError: arg is not a Python function Is this normal or a known issue? I couldn't find an existing ticket. ---------- components: Library (Lib) messages: 92591 nosy: ubershmekel severity: normal status: open title: inspect.getargspec(print) fails type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 11:29:26 2009 From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Pasternak?=) Date: Mon, 14 Sep 2009 09:29:26 +0000 Subject: [New-bugs-announce] [issue6906] Tkinter sets an unicode environment variable on win32 In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za> Message-ID: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za> New submission from Micha? Pasternak : Hi, I was recently playing with txAmpoule & Twisted on win32. When Twisted spawns processess, the environment is checked for unicode variables (and an exception is raised in case of). Then it came to my attention, that importing Tkinter on win32 sets an environment variable, which value is Unicode. Just have a look: C:\>python ActivePython 2.6.2.2 (ActiveState Software Inc.) based on Python 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> import os >>> os.environ['TK_LIBRARY'] u'C:\\Python26\\tcl\\tk8.5' >>> ^Z Why is it Unicode? Does it really have to be? Do we need that environment variable at all? On Linux, it is different: root at foo:~# python Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> import os >>> os.environ['TK_LIBRARY'] Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__ raise KeyError(key) KeyError: 'TK_LIBRARY' ---------- components: Tkinter messages: 92594 nosy: dotz severity: normal status: open title: Tkinter sets an unicode environment variable on win32 versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 12:20:21 2009 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2009 10:20:21 +0000 Subject: [New-bugs-announce] [issue6907] xmlrpclib.make_connection() is not thread safe In-Reply-To: <1252923621.29.0.493417133777.issue6907@psf.upfronthosting.co.za> Message-ID: <1252923621.29.0.493417133777.issue6907@psf.upfronthosting.co.za> New submission from STINNER Victor : The issue #6099 (part of #6267 superset) introduced a regression: xmlrpclib.make_connection() is not thread safe. If xmlrpclib is used in two threads, the socket is shared, but it doesn't any lock, and so data will be mixed between the two requets. It becomes worse when I use SSL (pyopenssl or m2crypto). A possible solution is to use a different socket for each thread. Note: I really love #6099, it was exactly what I needed :-) ---------- components: Extension Modules messages: 92596 nosy: haypo severity: normal status: open title: xmlrpclib.make_connection() is not thread safe type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 16:47:19 2009 From: report at bugs.python.org (Robert Lehmann) Date: Mon, 14 Sep 2009 14:47:19 +0000 Subject: [New-bugs-announce] [issue6908] Minor markup error in hashlib docs In-Reply-To: <1252939639.99.0.306887711121.issue6908@psf.upfronthosting.co.za> Message-ID: <1252939639.99.0.306887711121.issue6908@psf.upfronthosting.co.za> New submission from Robert Lehmann : The documentation for hashlib.hash.digest_size/block_size (notice the hash) renders as documentation for hashlib.*_size, which does not exist. Fixed by explicitly declaring membership; patch attached. ---------- assignee: georg.brandl components: Documentation files: hashlib-docs.patch keywords: patch messages: 92611 nosy: georg.brandl, lehmannro severity: normal status: open title: Minor markup error in hashlib docs versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14887/hashlib-docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 17:11:08 2009 From: report at bugs.python.org (jeff deifik) Date: Mon, 14 Sep 2009 15:11:08 +0000 Subject: [New-bugs-announce] [issue6909] python 3.1 - filecmp.cmp exception based on file name In-Reply-To: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za> Message-ID: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za> New submission from jeff deifik : I am calling filecmp.cmp on a two files, one of which has a name of './Julio_Iglesias-Un_Hombre_Solo-05-Qu\udce9_no_se_rompa_la_noche.mp3' I get an exception from filecmp.cmp saying: 'ascii' codec can't encode character '\udce9' in position 37: ordinal not in range(128) I do not understand why filecmp.cmp cares what the encoding of the names of the files are, as long as they are valid files. I would think filecmp.cmp would only care about the content of the files. When I give it pure ascii names, filecmp.cmp works file, however some of my files have udce9 encoded names. This is on a windows xp machine running cygwin (linux emulation). I built and compiled python3.1 from source. ---------- messages: 92613 nosy: jdeifik severity: normal status: open title: python 3.1 - filecmp.cmp exception based on file name type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 17:19:41 2009 From: report at bugs.python.org (Mitchell Model) Date: Mon, 14 Sep 2009 15:19:41 +0000 Subject: [New-bugs-announce] [issue6910] 1-char typo in language reference doc of import In-Reply-To: <1252941581.16.0.258073181914.issue6910@psf.upfronthosting.co.za> Message-ID: <1252941581.16.0.258073181914.issue6910@psf.upfronthosting.co.za> New submission from Mitchell Model : Just before 6.11.1 of the Language Reference: "Attempting to use it in class for function definitions" should be "or" not "for" ---------- assignee: georg.brandl components: Documentation messages: 92614 nosy: MLModel, georg.brandl severity: normal status: open title: 1-char typo in language reference doc of import versions: Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 17:26:59 2009 From: report at bugs.python.org (Robert Lehmann) Date: Mon, 14 Sep 2009 15:26:59 +0000 Subject: [New-bugs-announce] [issue6911] Document changes in asynchat In-Reply-To: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za> Message-ID: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za> New submission from Robert Lehmann : asynchat.async_chat grew a _collect_incoming and a _get_data method in 2.6. The constructor has been extended to conform to asyncore.dispatcher's. This should be documented. Apart from that, fifo and simple_producer have been deprecated, and async_chat.ac_out_buffer was replaced by async_chat.incoming. These are internals and were never documented. A patch is attached. ---------- assignee: georg.brandl components: Documentation files: asynchat-docs.patch keywords: patch messages: 92616 nosy: georg.brandl, lehmannro severity: normal status: open title: Document changes in asynchat versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14888/asynchat-docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:57:28 2009 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2009 17:57:28 +0000 Subject: [New-bugs-announce] [issue6912] Add 'with' block support to Tools/Scripts/pindent.py In-Reply-To: <1252951048.2.0.53684997295.issue6912@psf.upfronthosting.co.za> Message-ID: <1252951048.2.0.53684997295.issue6912@psf.upfronthosting.co.za> New submission from Terry J. Reedy : As reported by Miles Kaufmann on python-list, Tools/Scripts/pindent.py has not been updated to support 'with' blocks. I suspect that it would be sufficient to add ",'with'" to start = 'if', 'while', 'for', 'try', 'def', 'class' Since there are no "next['def'/'class']" lines, I suspect none is needed for 'with' either. ---------- components: Demos and Tools messages: 92622 nosy: tjreedy severity: normal status: open title: Add 'with' block support to Tools/Scripts/pindent.py type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 05:31:21 2009 From: report at bugs.python.org (Campbell Barton) Date: Tue, 15 Sep 2009 03:31:21 +0000 Subject: [New-bugs-announce] [issue6913] Py_SetPythonHome incorrectly documented py3.x (rev 74792) In-Reply-To: <1252985481.54.0.861262446626.issue6913@psf.upfronthosting.co.za> Message-ID: <1252985481.54.0.861262446626.issue6913@psf.upfronthosting.co.za> New submission from Campbell Barton : Py_SetPythonHome takes a *wchar_t not a *char, this is obvious from looking at the header, However I tried using this function and couldn't get it working until I made the home variable a static string. when looking at the source this is obvious, but should be documented... void Py_SetPythonHome(wchar_t *home) { default_home = home; } ---------- assignee: georg.brandl components: Documentation files: Py_SetPythonHome_doc.diff keywords: patch messages: 92640 nosy: georg.brandl, ideasman42 severity: normal status: open title: Py_SetPythonHome incorrectly documented py3.x (rev 74792) type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file14891/Py_SetPythonHome_doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 06:07:18 2009 From: report at bugs.python.org (Campbell Barton) Date: Tue, 15 Sep 2009 04:07:18 +0000 Subject: [New-bugs-announce] [issue6914] Py_SetPythonHome, undocumented behavoir In-Reply-To: <1252987638.62.0.948007118413.issue6914@psf.upfronthosting.co.za> Message-ID: <1252987638.62.0.948007118413.issue6914@psf.upfronthosting.co.za> New submission from Campbell Barton : Py_SetPythonHome holds a pointer to the variable passed, this is not documented so passing a variable on the stack will not work as expected unless its static or allocated. ---------- components: None messages: 92642 nosy: ideasman42 severity: normal status: open title: Py_SetPythonHome, undocumented behavoir type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 06:43:16 2009 From: report at bugs.python.org (Ryan Kelly) Date: Tue, 15 Sep 2009 04:43:16 +0000 Subject: [New-bugs-announce] [issue6915] os.listdir inconsistenly releases the GIL on win32 In-Reply-To: <1252989796.76.0.19947250091.issue6915@psf.upfronthosting.co.za> Message-ID: <1252989796.76.0.19947250091.issue6915@psf.upfronthosting.co.za> New submission from Ryan Kelly : The win32 implementation of os.listdir() releases the GIL around calls to FindNextFile, but not around calls to FindFirstFile. Attached is a simple patch to consistently release the GIL around any such calls. ---------- components: None files: listdir_gil.patch keywords: patch messages: 92643 nosy: rfk severity: normal status: open title: os.listdir inconsistenly releases the GIL on win32 type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14892/listdir_gil.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 07:55:56 2009 From: report at bugs.python.org (Robert Lehmann) Date: Tue, 15 Sep 2009 05:55:56 +0000 Subject: [New-bugs-announce] [issue6916] Remove deprecated items from asynchat In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za> Message-ID: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za> New submission from Robert Lehmann : The patches in issue1736190 deprecated fifo and simple_producers. These are safe for removal in Python 3.0. I attached a patch purging fifo and simple_producers from py3k code and tests. The docs are mostly trivial as well but also touched by my other issue issue6911 so I'd like that to settle first, otherwise this might result in a merge conflict. ---------- assignee: georg.brandl components: Documentation, Library (Lib), Tests files: asynchat.patch keywords: patch messages: 92645 nosy: georg.brandl, lehmannro severity: normal status: open title: Remove deprecated items from asynchat versions: Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14894/asynchat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 17:25:24 2009 From: report at bugs.python.org (dauerbaustelle) Date: Tue, 15 Sep 2009 15:25:24 +0000 Subject: [New-bugs-announce] [issue6917] ".et_folder" instead of "get_folder" in mailbox documentation In-Reply-To: <1253028324.31.0.745530277772.issue6917@psf.upfronthosting.co.za> Message-ID: <1253028324.31.0.745530277772.issue6917@psf.upfronthosting.co.za> New submission from dauerbaustelle : In the mailbox documentation, http://docs.python.org/library/mailbox.html#mailbox.Maildir..et_folder should be named "get_folder" instead of ".et_folder". ---------- assignee: georg.brandl components: Documentation messages: 92647 nosy: dauerbaustelle, georg.brandl severity: normal status: open title: ".et_folder" instead of "get_folder" in mailbox documentation versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 23:21:19 2009 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 15 Sep 2009 21:21:19 +0000 Subject: [New-bugs-announce] [issue6918] ctypes compilation error on SnowLeopard In-Reply-To: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za> Message-ID: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za> New submission from Ronald Oussoren : When I compile the trunk on MacOS X 10.6 I get a compile (or rather link) error in ctypes: ld: in build/temp.macosx-10.5-fat3- 2.7/Users/ronald/Projects/python/python-trunk- clean/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.o, unsupported encoding in FDE for architecture ppc This makes it impossible to build a univeral binary Python framework on OSX 10.6. I don't think I'm running into the same issue with PyObjC, it that works I'll port PyObjC's version of ppc-darwin to the version of libffi that's used by ctypes. ---------- assignee: ronaldoussoren components: Macintosh, ctypes messages: 92656 nosy: ronaldoussoren priority: release blocker severity: normal status: open title: ctypes compilation error on SnowLeopard type: compile error versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 06:19:14 2009 From: report at bugs.python.org (Henri Hein) Date: Wed, 16 Sep 2009 04:19:14 +0000 Subject: [New-bugs-announce] [issue6919] Link CRT Statically In-Reply-To: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za> Message-ID: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za> New submission from Henri Hein : Suggestion: Link the CRT statically into Python26.dll/PythonNN.dll and compiled .PYD files, at least when using the Microsoft compiler. There has been a number of bugs related to the msvcrt.dll, msvcr90.dll, etc. Many of these would go away if the CRT was statically linked into PythonNN.dll. The advantages of dynamically linking the CRT are not clear. The binaries are decreased a bit in size, but this is countered by having to redistribute the CRT DLL. Switching to static linking is a little more work than just flipping a switch, as you have to compensate for some of the initialization work the DLL does, but it is both doable and worth doing. ---------- assignee: tarek components: Distutils, Windows messages: 92663 nosy: hankdane, tarek severity: normal status: open title: Link CRT Statically versions: Python 2.4, Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 10:30:53 2009 From: report at bugs.python.org (Yinon Ehrlich) Date: Wed, 16 Sep 2009 08:30:53 +0000 Subject: [New-bugs-announce] [issue6920] IDLE 3 crashes on Ctrl+Space with "'utf8' codec can't decode bytes in position 0-1" In-Reply-To: <1253089853.74.0.832814951262.issue6920@psf.upfronthosting.co.za> Message-ID: <1253089853.74.0.832814951262.issue6920@psf.upfronthosting.co.za> New submission from Yinon Ehrlich : on Ubuntu 8.04 - I downloaded the sources, then: ./configure --prefix=$HOME make && make install in ~/bin/idle3 when I press Ctrl+Space (according to the "Edit" menu, should show completions) idle crashes with the following traceback: Traceback (most recent call last): File "/homes/yinon/bin/idle3", line 5, in main() File "/homes/yinon/lib/python3.1/idlelib/PyShell.py", line 1420, in main root.mainloop() File "/homes/yinon/lib/python3.1/tkinter/__init__.py", line 1009, in mainloop self.tk.mainloop(n) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding ---------- components: IDLE messages: 92667 nosy: Yinon severity: normal status: open title: IDLE 3 crashes on Ctrl+Space with "'utf8' codec can't decode bytes in position 0-1" type: crash versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 17:38:43 2009 From: report at bugs.python.org (David Hanney) Date: Wed, 16 Sep 2009 15:38:43 +0000 Subject: [New-bugs-announce] [issue6921] recursion wierdness ... related to variable scoping? In-Reply-To: <1253115523.94.0.244610185437.issue6921@psf.upfronthosting.co.za> Message-ID: <1253115523.94.0.244610185437.issue6921@psf.upfronthosting.co.za> New submission from David Hanney : I was playing about with ideas behind b-plus-trees and found i python bug the important bit of code is: for p, k in enumerate(self.keys): self.ptrs[p].dump(indent+1, kmin=lk, kmax=k) print sindent + "(" + str(k) + ")" lk = k # # python bug? # show_python_bug = len(sys.argv)>1 if show_python_bug: # # why not this? assert p == len(self.keys)-1 else: # # why do I need this instead? p = len(self.keys)-1 i'm expecting k to still be in scope and equal len(self.keys)-1 sometimes it is and sometimes it isn't (depending on recursion depth) you can try it for yourselves as I attach the full program: ./btree.py runs fine ./btree.py show_python_bug eventually breaks like this: Traceback (most recent call last): File "./btree.py", line 235, in page.dump() File "./btree.py", line 223, in dump self.ptrs[p+1].dump(indent+1, kmin=lk) File "./btree.py", line 223, in dump self.ptrs[p+1].dump(indent+1, kmin=lk) File "./btree.py", line 223, in dump self.ptrs[p+1].dump(indent+1, kmin=lk) File "./btree.py", line 217, in dump assert p == len(self.keys)-1 UnboundLocalError: local variable 'p' referenced before assignment ... despite executing that code many times successfully before this happens ... strange! I hope you can figure it out and that this report proves helpful. ---------- components: Interpreter Core files: btree.py messages: 92691 nosy: mrdiskodave severity: normal status: open title: recursion wierdness ... related to variable scoping? type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14897/btree.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:38:16 2009 From: report at bugs.python.org (Alex) Date: Wed, 16 Sep 2009 17:38:16 +0000 Subject: [New-bugs-announce] [issue6922] Interpreter hangs up while trying to decode invalid utf32 stream. In-Reply-To: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za> Message-ID: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za> New submission from Alex : *** Prerequisites: Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32 *** Description: 'utf_32_le' and 'utf_32_be' codecs are overconsuming memory when input data are damaged and kwarg 'errors' to str.decode is other than 'strict'. *** Steps: 1. Start interpreter 2. Type: '\x01'.decode('utf_32_le', 'replace') or '\x01'.decode('utf32', 'ignore') or ('something'.encode('utf32') + '\x00').decode('utf32', 'ignore') 3. Execute *** Notes: 1. seems like any stream raising UnicodeDecodeError in 'strict' mode causes hangup in 'ignore' or 'replace'. *** Expected result: 1. AssertionError on "assert errors == 'strict'" raised, just as bz2_codec does, if utf32 cannot be partially decoded at all. 2. Behaviour that 'utf8' and 'utf16' implement for such cases. *** Received result: 1. Interpreter hangs, uses up to 100% of CPU kernel and starts to consume RAM. 2. Grows large enough to consume all the RAM it could get (takes up to several minutes on my machine). 3. Produces following traceback: Traceback (most recent call last): File "", line 1, in File "C:\Python26\lib\encodings\utf_32_be.py", line 11, in decode return codecs.utf_32_be_decode(input, errors, True) MemoryError 4. Sometimes traceback is printed, but text "MemoryError" is not, just leaving blank line in the place. ---------- components: Interpreter Core, Library (Lib), Unicode, Windows messages: 92704 nosy: mwizard severity: normal status: open title: Interpreter hangs up while trying to decode invalid utf32 stream. versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 22:03:14 2009 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 16 Sep 2009 20:03:14 +0000 Subject: [New-bugs-announce] [issue6923] Need pthread_atfork-like functionality in CPython In-Reply-To: <1253131394.22.0.862355202249.issue6923@psf.upfronthosting.co.za> Message-ID: <1253131394.22.0.862355202249.issue6923@psf.upfronthosting.co.za> New submission from Thomas Wouters : In order to properly handle multiple threads and fork()-calls from C code (rather than os.fork()), Python should provide pthread_atfork()-like functionality: a function to call before a fork, to acquire any locks that need to be acquired, and a pair of functions to call after the fork, in the parent and the child, to release or re-allocate locks. The acquisitions should be re-entrant and should not require an existing threadstate. Also see . ---------- assignee: twouters components: Interpreter Core messages: 92715 nosy: twouters priority: low severity: normal stage: needs patch status: open title: Need pthread_atfork-like functionality in CPython type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 23:53:20 2009 From: report at bugs.python.org (Emmanuel Bengio) Date: Wed, 16 Sep 2009 21:53:20 +0000 Subject: [New-bugs-announce] [issue6924] struct.unpack weird behavior with "bi" (byte then integer) In-Reply-To: <1253138000.08.0.430539071948.issue6924@psf.upfronthosting.co.za> Message-ID: <1253138000.08.0.430539071948.issue6924@psf.upfronthosting.co.za> New submission from Emmanuel Bengio : Using the following command in Python 2.6.1: >>> struct.unpack("BI","12345") Traceback (most recent call last): File "", line 1, in struct.unpack("BI","12345") error: unpack requires a string argument of length 8 I get this error message. What confused me was that doing >>> struct.unpack("IB","12345") (875770417, 53) Worked just fine. I have found out that this only happens using the native byte order("@"), which is the default. For Example: >>> struct.unpack("!BI","12345") (49, 842216501) Works, and all other variants, =, <, > (native standard,little endian, and small endian) also do. I haven't found anything about that in the documentation. Also, the requested 3 other bytes arent event used: >>> struct.unpack("I","abcd") (1684234849,) # see the big number starting with 16 >>> ord("x") 120 >>> struct.unpack("BI","xabcd") # we get the error Traceback (most recent call last): File "", line 1, in struct.unpack("BI","xabcd") error: unpack requires a string argument of length 8 >>> struct.unpack("BI","xabcdefg") (120, 1734763876) # not the same here >>> struct.unpack("BI","xabcabcd") (120, 1684234849) # same here >>> struct.unpack("BI","x___abcd") (120, 1684234849) # same again ---------- components: Library (Lib) messages: 92724 nosy: Manux severity: normal status: open title: struct.unpack weird behavior with "bi" (byte then integer) type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 01:18:06 2009 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 16 Sep 2009 23:18:06 +0000 Subject: [New-bugs-announce] [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za> Message-ID: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za> New submission from Jason R. Coombs : It appears that somewhere between Python 2.5 and Python 2.6, some socket constants were lost in Windows builds. Python 2.6.2 (r262:71605, Apr 14 2009, 22:46:50) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket; socket.IPPROTO_IPV6 Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'IPPROTO_IPV6' Confirmed this problem on 32-bit builds and Python 3.1.1 also. I suspect the compiler upgrade influenced this behavior. Let me know if I can help track down the issue. ---------- components: IO, Windows messages: 92730 nosy: jaraco severity: normal status: open title: socket module missing IPPROTO_IPV6, IPPROTO_IPV4 type: behavior versions: Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 00:54:42 2009 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Sep 2009 22:54:42 +0000 Subject: [New-bugs-announce] [issue6925] Doc for locals and vars In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za> Message-ID: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za> New submission from Terry J. Reedy : Doc for locals(): after correctly stating "Update and return a dictionary representing the current local symbol table. Note The contents of this dictionary should not be modified; changes may not affect the values of local variables used by the interpreter." current doc goes on to say "Free variables are returned by locals() when it is called in a function block. Modifications of free variables may not affect the values used by the interpreter. Free variables are not returned in class blocks." As best I can understand this, it is wrong and should be removed. Free variables within a function block are global/nonlocal names and by my experimentation with 3.1, (including lambda expressions) are NOT returned by locals(). If it means something else, it needs a rewrite. The doc for var() starts "Without arguments, return a dictionary corresponding to the current local symbol table." I suggest augmenting this with 'update and ' (to match locals doc) and '(same as locals())' to make that fact clear (as it is with help(vars)), even though removing the 'Free variables' stuff will help the latter clearer also. The result would be Without arguments, update and return a dictionary corresponding to the current local symbol table (same as locals()). ---------- messages: 92728 nosy: tjreedy severity: normal status: open title: Doc for locals and vars versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 01:33:33 2009 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Sep 2009 23:33:33 +0000 Subject: [New-bugs-announce] [issue6927] Metaclass doc (Ref 3.3.3) errors In-Reply-To: <1253144013.13.0.919755909189.issue6927@psf.upfronthosting.co.za> Message-ID: <1253144013.13.0.919755909189.issue6927@psf.upfronthosting.co.za> New submission from Terry J. Reedy : 3.3.3. Customizing class creation 3.1/3.2 docs say "If the metaclass keyword argument is based with the bases, it is used." (new version for 3.x) I presume 'based' was meant to be 'passed'. However, with that correction, would it really be correct? I presume the metaclass compatibility issue discussed in #1294232 for 2.x is still relevant for 3.x. The next line "Otherwise, if there is at least one base class, its metaclass is used." (same as for 2.x docs) does not say which 'its' is used if there is more than one. See paragraph above and #1294232. I do not know the actual rule well enough to improve the neglected suggestion in the referenced issue. ---------- assignee: georg.brandl components: Documentation messages: 92732 nosy: georg.brandl, tjreedy severity: normal status: open title: Metaclass doc (Ref 3.3.3) errors versions: Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 01:53:49 2009 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Sep 2009 23:53:49 +0000 Subject: [New-bugs-announce] [issue6928] Doc: Class statements and metaclass = xxx In-Reply-To: <1253145229.65.0.267557560742.issue6928@psf.upfronthosting.co.za> Message-ID: <1253145229.65.0.267557560742.issue6928@psf.upfronthosting.co.za> New submission from Terry J. Reedy : For 3.x, I think 7.7 Class Definitions should mention the metaclass keyword arg and cross-reference 3.3.3 Customizing class creation. Since it is no longer a 'special' name, let alone a 'special method name', there is no reason to know to look for it under that heading (I didn't until I looked for 'metaclass' in the index, which I had to know to look for, of course). A possible sentence after "The class name is bound to this class object in the original local namespace." (and before discussion of @classdeco) "To modify this process, add 'metaclass = xxx' to the list of bases and see CCustomizing class creation." with the last three words being a blue link to 3.3.3. 2.x would need something a bit different, or just less ;-) ---------- assignee: georg.brandl components: Documentation messages: 92733 nosy: georg.brandl, tjreedy severity: normal status: open title: Doc: Class statements and metaclass = xxx versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 11:51:52 2009 From: report at bugs.python.org (Pascal Chambon) Date: Thu, 17 Sep 2009 09:51:52 +0000 Subject: [New-bugs-announce] [issue6929] Confusion between "write" method of rowiobase and rawfileio In-Reply-To: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za> Message-ID: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za> New submission from Pascal Chambon : It seems the properties of the write methods of these two classes are mixed up in documentation. I've checked the sources, and actually it seems the behviour is inverted : rawiobase streams, which can be pipes or other limited streams, may write less than len(b) bytes in one operation, and return ; whereas rawfileio instances, which write on disk, will never fail writing all the data unless the disk is full (resulting in IOError). It's rawiobase which does one system call, not rawiofile which will try again until all is written, isn't it ? RawIoBase write(b) Write the given bytes or bytearray object, b, to the underlying raw stream and return the number of bytes written (never less than len(b), since if the write fails an IOError will be raised). A BlockingIOError is raised if the buffer is full, and the underlying raw stream cannot accept more data at the moment. RawFileIO : write(b) Write the bytes or bytearray object, b, to the file, and return the number actually written. Only one system call is made, so it is possible that only some of the data is written. ---------- assignee: georg.brandl components: Documentation messages: 92751 nosy: georg.brandl, pakal severity: normal status: open title: Confusion between "write" method of rowiobase and rawfileio type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 16:09:59 2009 From: report at bugs.python.org (Jon Foster) Date: Thu, 17 Sep 2009 14:09:59 +0000 Subject: [New-bugs-announce] [issue6930] [PATCH] PyUnicode_DecodeUTF16 docs wrong (byteorder param) In-Reply-To: <1253196599.56.0.25129944047.issue6930@psf.upfronthosting.co.za> Message-ID: <1253196599.56.0.25129944047.issue6930@psf.upfronthosting.co.za> New submission from Jon Foster : The documentation for the C API function PyUnicode_DecodeUTF16() does not match the code. If *byteorder is 1 or -1, the documentation says that the function looks for a BOM. It doesn't. This patch updates the documentation to match the code. (Also, I just realised that the docs for PyUnicode_DecodeUTF32() have the exact same bug. That is NOT fixed by this patch). This patch also clarifies the PyUnicode_EncodeUTF16() docs. ---------- assignee: georg.brandl components: Documentation files: unicodedocs.patch keywords: patch messages: 92764 nosy: JonFoster, georg.brandl severity: normal status: open title: [PATCH] PyUnicode_DecodeUTF16 docs wrong (byteorder param) type: behavior versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file14910/unicodedocs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 16:54:58 2009 From: report at bugs.python.org (=?utf-8?q?Hei=C3=B0ar_Rafn_Har=C3=B0arson?=) Date: Thu, 17 Sep 2009 14:54:58 +0000 Subject: [New-bugs-announce] [issue6931] awful performance in difflib: ndiff and HtmlDiff In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za> Message-ID: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za> New submission from Hei?ar Rafn Har?arson : Relatively small set of lines with differences in most lines can destroy the performance of difflib.HtmlDiff.make_table and difflib.ndiff. I am using it like this: ... htmldiffer = HtmlDiff() return htmldiffer.make_table(src_lines, dst_lines, fromdesc="file1", todesc="file2", context=True) I have written the src_lines and dst_lins to files and tried this with the Tools/scripts/diff.py wrapper with same results when using the switches -m or -n. The performance is fine when using difflib.unified_diff or switch -u on diff.py Attached are files that show this clearly. left200.txt,right200.txt - 200 lines of text - duration 11 seconds. left500.txt,right500.txt - 500 lines of text - duration 2min 58 sec left1000.txt,right1000.txt - 1000 lines of text - duration 29min 4sec tested on Intel dualcore T2500 2GHz with 2 GB of memory, python 2.5.2 on Ubuntu. Same problom on python 2.6 on Fedora-11 For reference, the kdiff3 utility performs beautifully on these files. ---------- components: Library (Lib) files: python.difflib.bug.tgz messages: 92768 nosy: heidar.rafn severity: normal status: open title: awful performance in difflib: ndiff and HtmlDiff type: performance versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file14911/python.difflib.bug.tgz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 17:55:57 2009 From: report at bugs.python.org (Robert Lehmann) Date: Thu, 17 Sep 2009 15:55:57 +0000 Subject: [New-bugs-announce] [issue6932] Open shelves fail when Python exits In-Reply-To: <1253202957.58.0.0745460877644.issue6932@psf.upfronthosting.co.za> Message-ID: <1253202957.58.0.0745460877644.issue6932@psf.upfronthosting.co.za> New submission from Robert Lehmann : I'm reopening issue5483 by Zhigang Wang (zhigang) as a separate bug. Shelves that are still open when Python terminates will try to sync. If writeback=True, this pickles cached items. In this example, serialization of Test() re-imports __main__, which is already gc'd, and raises: Exception cPickle.PicklingError: Can't pickle : it's not the same object as __main__.Test" in }> The error is ignored (due to Python already tearing down) but all cached modifications are lost. The promise "[t]he __del__() method of the Shelf class calls the close() method, so the programmer generally need not do this explicitly" is not true with writeback enabled. I'm unsure if this error can be fixed (probably with atexit/weakref, but that's more trouble than gain). I attached a patch to the docs simply warning the user of this issue (+ documenting Shelf.close, + removing above quote). ---------- assignee: georg.brandl components: Documentation, Extension Modules, Library (Lib) files: example.py messages: 92773 nosy: georg.brandl, lehmannro severity: normal status: open title: Open shelves fail when Python exits type: behavior versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file14912/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 19:01:01 2009 From: report at bugs.python.org (Moray Grieve) Date: Thu, 17 Sep 2009 17:01:01 +0000 Subject: [New-bugs-announce] [issue6933] Threading issue with Tkinter Frame.insert In-Reply-To: <1253206861.41.0.487118668051.issue6933@psf.upfronthosting.co.za> Message-ID: <1253206861.41.0.487118668051.issue6933@psf.upfronthosting.co.za> New submission from Moray Grieve : The attached file has an example where a Tk GUI is launched as a seperate thread - this all works fine in Python 2.5, but in Python 2.6 the thread hangs. The issue seems to be in the line; self.messageBoxDetails.insert(INSERT, "Hello world") Comment this line out, or use an empty string rather than "Hello World", and the example works in both Python 2.5 and Python 2.6. I have not been able to seen any related issues to this and wonder if this is a bug in the 2.6 Tkinter module. ---------- components: Tkinter files: example.py messages: 92781 nosy: moraygrieve severity: normal status: open title: Threading issue with Tkinter Frame.insert type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14914/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 19:46:16 2009 From: report at bugs.python.org (Svetoslav Agafonkin) Date: Thu, 17 Sep 2009 17:46:16 +0000 Subject: [New-bugs-announce] [issue6934] postflight.framework script (from the Mac OS X .dmg installer) fails (patch given). In-Reply-To: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za> Message-ID: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za> New submission from Svetoslav Agafonkin : postflight.framework fails during installation: . . . Sep 17 17:36:53 mcfro Installer[1613]: run postflight script for Python Framework Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python 3.1.1/Python.mpkg/Contents/Packages/PythonFramework- 3.1.pkg/Contents/Resources/postflight: line 9: /Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such file or directory Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python 3.1.1/Python.mpkg/Contents/Packages/PythonFramework- 3.1.pkg/Contents/Resources/postflight: line 14: /Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such file or directory Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python 3.1.1/Python.mpkg/Contents/Packages/PythonFramework- 3.1.pkg/Contents/Resources/postflight: line 19: /Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such file or directory Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python 3.1.1/Python.mpkg/Contents/Packages/PythonFramework- 3.1.pkg/Contents/Resources/postflight: line 24: /Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such file or directory Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: chown: admin: Invalid argument Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: The first problem is that in /Library/Frameworks/Python.framework/Versions/3.1/bin there is no executable 'python' anymore - there is 'python3.1', etc. Also chown at the end should set the group to 'admin', not the owner. I've attached a patch that fixes these issues. (the problem with chown is also present in the installer for 2.6.x ). ---------- assignee: ronaldoussoren components: Installation, Macintosh files: postflight.framework.patch keywords: patch messages: 92786 nosy: ronaldoussoren, slavi severity: normal status: open title: postflight.framework script (from the Mac OS X .dmg installer) fails (patch given). type: compile error versions: Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14916/postflight.framework.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 01:30:26 2009 From: report at bugs.python.org (Mitchell Model) Date: Thu, 17 Sep 2009 23:30:26 +0000 Subject: [New-bugs-announce] [issue6935] Version updates needed in tutorial In-Reply-To: <1253230226.4.0.664611927484.issue6935@psf.upfronthosting.co.za> Message-ID: <1253230226.4.0.664611927484.issue6935@psf.upfronthosting.co.za> New submission from Mitchell Model : Footnote 1 in section 2.1 of the Tutorial and the example of invoking Python in the middle of the page need their version number upped to 3.2 in both the invocation and the greeting. The same page in the 3.1 documentation should have the 'a' removed from the version number in the greeting. ---------- assignee: georg.brandl components: Documentation messages: 92798 nosy: MLModel, georg.brandl severity: normal status: open title: Version updates needed in tutorial versions: Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 01:38:03 2009 From: report at bugs.python.org (Mitchell Model) Date: Thu, 17 Sep 2009 23:38:03 +0000 Subject: [New-bugs-announce] [issue6936] Import needed to quit Python? In-Reply-To: <1253230683.38.0.361310672505.issue6936@psf.upfronthosting.co.za> Message-ID: <1253230683.38.0.361310672505.issue6936@psf.upfronthosting.co.za> New submission from Mitchell Model : Section 2.1 of the tutorial describes using import sys; sys.exit() if ^D or ^Z doesn't work. However, both quit() and exit() work, as documented in the "Built-in Constants" section of the Library documentation. Is there something about them that should be hidden from the ordinary user that they aren't used in place of the import sys; sys.exit() combination? Seems easier to just say use "quit() or exit()", especially for beginners following the tutorial who won't know what import or sys are, or even the dot notation. ---------- assignee: georg.brandl components: Documentation messages: 92799 nosy: MLModel, georg.brandl severity: normal status: open title: Import needed to quit Python? versions: Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 07:10:44 2009 From: report at bugs.python.org (aaditya sood) Date: Fri, 18 Sep 2009 05:10:44 +0000 Subject: [New-bugs-announce] [issue6937] multiprocessing lock on OS X Snow Leopard dumps core In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za> Message-ID: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za> New submission from aaditya sood : On a Snow Leopard system, doing this core dumps: import multiprocessing lck1=multiprocessing.Lock() with lck1: print "foo" The stack trace: Process: Python [23100] Path: /System/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86-64 (Native) Parent Process: zsh [23055] Date/Time: 2009-09-18 10:39:39.611 +0530 OS Version: Mac OS X 10.6.1 (10B504) Report Version: 6 Interval Since Last Report: 83665 sec Crashes Since Last Report: 60 Per-App Crashes Since Last Report: 55 Anonymous UUID: 38A426BB-52F7-4282-9FA8-A04AB8896489 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00000043000000ee Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 org.python.python 0x0000000100096763 _PyArg_ParseTupleAndKeywords_SizeT + 113 1 _multiprocessing.so 0x00000001001fa8c8 sem_timedwait_save + 456 2 org.python.python 0x00000001000891df PyEval_EvalFrameEx + 15001 3 org.python.python 0x000000010008accf PyEval_EvalCodeEx + 1803 4 org.python.python 0x000000010008ad62 PyEval_EvalCode + 54 5 org.python.python 0x00000001000a265a Py_CompileString + 78 6 org.python.python 0x00000001000a44dd PyRun_InteractiveOneFlags + 503 7 org.python.python 0x00000001000a4615 PyRun_InteractiveLoopFlags + 206 8 org.python.python 0x00000001000a4685 PyRun_AnyFileExFlags + 76 9 org.python.python 0x00000001000b0286 Py_Main + 2718 10 org.python.python.app 0x0000000100000e6c start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000004300000043 rbx: 0x0000000100200150 rcx: 0x00000001001fc7f0 rdx: 0x00000001001fb632 rdi: 0x00000001001af050 rsi: 0x000000010003af24 rbp: 0x00007fff5fbfeff0 rsp: 0x00007fff5fbfef20 r8: 0x0000000100096748 r9: 0x00007fff5fbff030 r10: 0x0000000000000000 r11: 0x00000001001fa86f r12: 0x00000000ffffffff r13: 0x00000001004a4570 r14: 0x0000000100123100 r15: 0x00000001001af050 rip: 0x0000000100096763 rfl: 0x0000000000010206 cr2: 0x00000043000000ee Binary Images: 0x100000000 - 0x100000ff7 org.python.python.app 2.6 (2.6) /System/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python 0x100004000 - 0x100114ff7 org.python.python 2.6.1 (2.6.1) <01EBD0D4-F181-045F-C7A8-B7B3C5D4204F> /System/Library/Frameworks/Python.framework/Versions/2.6/Python 0x1001f0000 - 0x1001f2ff7 readline.so ??? (???) /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/readline.so 0x1001f8000 - 0x1001fbfff _multiprocessing.so ??? (???) <03672D74-6FAC-DE76-6DE6-604A8C0F2D50> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_multiprocessing.so 0x1004b0000 - 0x1004ccff7 libedit.2.dylib ??? (???) /usr/lib/libedit.2.dylib 0x1004db000 - 0x1004e0fff itertools.so ??? (???) <06555874-952C-C770-64BF-6BC7A2455E10> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/itertools.so 0x1004e8000 - 0x1004f4fff cPickle.so ??? (???) <98485D07-D504-74EB-B3A1-4EBB2474BFE6> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cPickle.so 0x1004fa000 - 0x1004fbfff cStringIO.so ??? (???) <7600C3A8-3C81-2A81-0853-B09107768C8C> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cStringIO.so 0x100540000 - 0x100541ff7 _functools.so ??? (???) <1CE29F88-7B8C-77CC-5E87-555BA210EA8F> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_functools.so 0x100545000 - 0x100546ff7 time.so ??? (???) <5F01F2A9-8557-5DF1-F006-44E02E0469CE> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/time.so 0x10054d000 - 0x100550fff _collections.so ??? (???) <1F62A5C3-6E6C-D0BC-7AA6-DA2820B5F157> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_collections.so 0x100556000 - 0x100559fff operator.so ??? (???) <68C1CC88-5F73-E029-5C19-685BBADACFA6> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/operator.so 0x10055f000 - 0x10055ffff _weakref.so ??? (???) <89F1302D-1CFA-7B9B-4425-70DA55215DAE> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_weakref.so 0x1005a3000 - 0x1005a7ff7 _struct.so ??? (???) <33156F5C-52ED-7167-533F-15D6CF031150> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_struct.so 0x1005ad000 - 0x1005affe7 binascii.so ??? (???) <5CFE3DC5-850B-B79D-8310-0BA97540841A> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/binascii.so 0x7fff5fc00000 - 0x7fff5fc3bdef dyld 132.1 (???) /usr/lib/dyld 0x7fff80bc1000 - 0x7fff80bc5ff7 libmathCommon.A.dylib ??? (???) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib 0x7fff829f4000 - 0x7fff82bb2ff7 libSystem.B.dylib ??? (???) <66102D4E-6C8B-77D0-6766-2A1788B20C6F> /usr/lib/libSystem.B.dylib 0x7fff85ebc000 - 0x7fff85efbfef libncurses.5.4.dylib ??? (???) /usr/lib/libncurses.5.4.dylib 0x7fff85f81000 - 0x7fff85f92fef libz.1.dylib ??? (???) <3A7A4C48-A4C8-A78A-8B87-C0DDF6601AC8> /usr/lib/libz.1.dylib 0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???) <66102D4E-6C8B-77D0-6766-2A1788B20C6F> /usr/lib/libSystem.B.dylib Model: MacBookPro2,2, BootROM MBP22.00A5.B07, 2 processors, Intel Core 2 Duo, 2.16 GHz, 2 GB, SMC 1.12f5 Graphics: ATI Radeon X1600, ATY,RadeonX1600, PCIe, 128 MB Memory Module: global_name AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x87), Atheros 5416: 2.0.19.4 Bluetooth: Version 2.2.1f7, 2 service, 1 devices, 1 incoming serial ports Network Service: AirPort, AirPort, en1 Serial ATA Device: Hitachi HTS541612J9SA00, 111.79 GB Parallel ATA Device: HL-DT-ST DVDRW GWA4080MA USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8501, 0xfd400000 USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8240, 0x5d200000 USB Device: Apple Internal Keyboard / Trackpad, 0x05ac (Apple Inc.), 0x021a, 0x1d200000 USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8205, 0x7d100000 ---------- components: Extension Modules messages: 92801 nosy: aaditya severity: normal status: open title: multiprocessing lock on OS X Snow Leopard dumps core versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 11:06:51 2009 From: report at bugs.python.org (Zhang Cong) Date: Fri, 18 Sep 2009 09:06:51 +0000 Subject: [New-bugs-announce] [issue6938] Incorrect multiprocessing log string in managers.py (python 2.6.2) In-Reply-To: <1253264811.0.0.554251286265.issue6938@psf.upfronthosting.co.za> Message-ID: <1253264811.0.0.554251286265.issue6938@psf.upfronthosting.co.za> New submission from Zhang Cong : There is an issue in multiprocessing library. Lib/multiprocessing/managers.py:413: util.debug('disposing of obj with id %d', ident) It is '%d' here, but 'ident' is a string. This always cause an TypeError from logging module once enable logging on multiprocessing. Patch is attached to fix the issue. ---------- components: Library (Lib) files: managers-log.patch keywords: patch messages: 92818 nosy: ftofficer severity: normal status: open title: Incorrect multiprocessing log string in managers.py (python 2.6.2) type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14922/managers-log.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:21:53 2009 From: report at bugs.python.org (Pascal Chambon) Date: Fri, 18 Sep 2009 13:21:53 +0000 Subject: [New-bugs-announce] [issue6939] shadows around the io truncate() semantics In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za> Message-ID: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za> New submission from Pascal Chambon : Hello I'm having trouble around the behaviour of the io module's truncate methods, in py3k. If I remember well, under unix and older versions of Python (with other file types), truncate never move the fiel pointer (and had to fake that behaviour under windows as well, by saving/restoring the file pointer). However, I see nothing in the documentation of the io module about that, and studying the _fileio.c code, it seems that now the file pointer is (under all OS) moved to the truncation point, and left there. Maybe it requires discusions on the mailing list, but personally I think that the common unix behaviour (letting the file pointer untouched) would be better for everyone, and that the doc should claim it. Also, additional notes about the behaviour of that truncation (reminding people that on some OS, the padding is zero-filled, on others it's not...) would be great. Current doc of io in py3k : http://docs.python.org/py3k/library/io.html#io.IOBase.truncate truncate(size=None) Truncate the file to at most size bytes. size defaults to the current file position, as returned by tell(). Cheers Pascal ---------- components: IO messages: 92822 nosy: pakal severity: normal status: open title: shadows around the io truncate() semantics type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:58:09 2009 From: report at bugs.python.org (Rajarshi) Date: Fri, 18 Sep 2009 13:58:09 +0000 Subject: [New-bugs-announce] [issue6940] cannot compute sizeof wchar_t on OS X 10.5.7, Python 2.6.2 In-Reply-To: <1253282289.6.0.748940498634.issue6940@psf.upfronthosting.co.za> Message-ID: <1253282289.6.0.748940498634.issue6940@psf.upfronthosting.co.za> New submission from Rajarshi : OS 10.5.7, Python 2.6.2 sources. When I execute: /configure --enable-framework=/Library/Frameworks \ --enable-universalsdk=/ \ MACOSX_DEPLOYMENT_TARGET=10.5 \ --with-universal-archs=all \ --with-readline-dir=/usr/local configure fails with the error checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t) However, if I replace all with 64-bit, it works fine. I note that this issue was reported for OS X 10.4 and fixed. But this still happens gcc information is Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5490~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5490) ---------- components: Build messages: 92824 nosy: rajarshi severity: normal status: open title: cannot compute sizeof wchar_t on OS X 10.5.7, Python 2.6.2 versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 21:58:12 2009 From: report at bugs.python.org (Joshua Purcell) Date: Fri, 18 Sep 2009 19:58:12 +0000 Subject: [New-bugs-announce] [issue6941] Help Message-ID: <1253303892.82.0.946602565128.issue6941@psf.upfronthosting.co.za> Changes by Joshua Purcell : ---------- nosy: 08jpurcell severity: normal status: open title: Help versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 01:53:52 2009 From: report at bugs.python.org (Ross Patterson) Date: Fri, 18 Sep 2009 23:53:52 +0000 Subject: [New-bugs-announce] [issue6942] email.generator.Generator memory consumption In-Reply-To: <1253318032.63.0.187743524666.issue6942@psf.upfronthosting.co.za> Message-ID: <1253318032.63.0.187743524666.issue6942@psf.upfronthosting.co.za> New submission from Ross Patterson : Due to repeated use of StringIO as a way to "look ahead" into subparts while checking that multipart boundaries are unique, memory consumption during email.generator.Generator.flatten() can be up to 3 times the original message size. I implemented a subclass of email.generator.Generator that works around this using email.message.Message.walk() to check message headers and string (final) payloads for the boundary without duplicating their contents into a StringIO. It assumes that the boundary only ever might be duplicated in a single part's headers or in a single part's payload when that part's payload is a string. IOW, it assumes that the boundary will not be duplicated by some combination of all the parts' and recursive subparts' headers and string payloads. If this assumption is safe, then this implementation should work. If this assumption is not safe, then perhaps a different boundary format can be used which will make this assumption safe? You can find my implementation at http://gitorious.org/rpatterson- imappipe/rpatterson- imappipe/blobs/master/rpatterson/imappipe/generator.py ---------- components: Library (Lib) messages: 92853 nosy: rpatterson severity: normal status: open title: email.generator.Generator memory consumption type: resource usage versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 05:18:42 2009 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 19 Sep 2009 03:18:42 +0000 Subject: [New-bugs-announce] [issue6943] setup.py fails to find headers of system libffi In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za> Message-ID: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis : I use --with-system-ffi option, but setup.py fails to find headers of system libffi which are placed outside standard include directory, which causes using of internal copy of libffi. In Gentoo, headers of libffi-3.0.8 are installed into /usr/lib/libffi-3.0.8/include directory, because their content is specific to given architecture. I'm attaching the patch which cause using of `pkg-config libffi -- (Unfortunately subprocess module cannot be used in setup.py, so I'm using os.popen().) ---------- components: Build files: python-fix_search_for_libffi_headers.patch keywords: patch messages: 92856 nosy: Arfrever, loewis severity: normal status: open title: setup.py fails to find headers of system libffi versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14928/python-fix_search_for_libffi_headers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 07:36:10 2009 From: report at bugs.python.org (Marien Zwart) Date: Sat, 19 Sep 2009 05:36:10 +0000 Subject: [New-bugs-announce] [issue6944] socket.getnameinfo raises SystemError on bogus input In-Reply-To: <1253338570.09.0.666408311611.issue6944@psf.upfronthosting.co.za> Message-ID: <1253338570.09.0.666408311611.issue6944@psf.upfronthosting.co.za> New submission from Marien Zwart : socket.getnameinfo passes a PyObject* to PyArg_ParseTuple without checking if it's a tuple first. That means it raises SystemError on invalid input where TypeError would make more sense: >>> socket.getnameinfo('localhost', 0) SystemError: new style getargs format but argument is not a tuple An explicit check for TypeError seems like the best way to fix this. Patch (against Python 3.1.1, but it looked like this applies easily to other branches too) attached, which also removes a bit of dead code. ---------- components: Extension Modules files: diff.patch keywords: patch messages: 92858 nosy: marienz severity: normal status: open title: socket.getnameinfo raises SystemError on bogus input type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14929/diff.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 11:26:59 2009 From: report at bugs.python.org (Armin Ronacher) Date: Sat, 19 Sep 2009 09:26:59 +0000 Subject: [New-bugs-announce] [issue6945] pprint.pprint does not pprint unsortable dicts in Python 3 In-Reply-To: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za> Message-ID: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za> New submission from Armin Ronacher : Currently pprint does not work on dicts it cannot sort. Because in Python 3 sorted(x.items()) is no longer guaranteed to work a new sorting solution has to be found. ---------- messages: 92862 nosy: aronacher severity: normal status: open title: pprint.pprint does not pprint unsortable dicts in Python 3 versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 11:35:44 2009 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sat, 19 Sep 2009 09:35:44 +0000 Subject: [New-bugs-announce] [issue6946] Document: Missing link to datetime.datetime In-Reply-To: <1253352944.46.0.750733496688.issue6946@psf.upfronthosting.co.za> Message-ID: <1253352944.46.0.750733496688.issue6946@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : Please see http://docs.python.org/genindex-D.html. "datetime (class in datetime), [1]" links to same address. I think "[1]" should point to http://docs.python.org/library/datetime.html#datetime-datetime. ---------- assignee: georg.brandl components: Documentation messages: 92863 nosy: georg.brandl, ocean-city severity: normal status: open title: Document: Missing link to datetime.datetime versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 11:44:45 2009 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sat, 19 Sep 2009 09:44:45 +0000 Subject: [New-bugs-announce] [issue6947] Fix distutils test on windows (SO extension) In-Reply-To: <1253353485.29.0.889372129006.issue6947@psf.upfronthosting.co.za> Message-ID: <1253353485.29.0.889372129006.issue6947@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : This will fix distutils test error on windows. ---------- assignee: tarek components: Distutils, Tests files: test_distutils.patch keywords: patch messages: 92864 nosy: ocean-city, tarek severity: normal status: open title: Fix distutils test on windows (SO extension) versions: Python 2.6 Added file: http://bugs.python.org/file14931/test_distutils.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 16:59:00 2009 From: report at bugs.python.org (kewlar) Date: Sat, 19 Sep 2009 14:59:00 +0000 Subject: [New-bugs-announce] [issue6948] list In-Reply-To: <1253372340.63.0.203470162856.issue6948@psf.upfronthosting.co.za> Message-ID: <1253372340.63.0.203470162856.issue6948@psf.upfronthosting.co.za> New submission from kewlar : >>> a = [[0,0,0],[0,0,0],[0,0,0]] >>> a [[0, 0, 0], [0, 0, 0], [0, 0, 0]] >>> a[1][1] = 1 >>> a [[0, 0, 0], [0, 1, 0], [0, 0, 0]] >>> b = [[0]*3]*3 >>> b [[0, 0, 0], [0, 0, 0], [0, 0, 0]] >>> b[1][1] = 1 >>> b [[0, 1, 0], [0, 1, 0], [0, 1, 0]] >>> ---------- messages: 92869 nosy: nutregina severity: normal status: open title: list type: performance versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 18:09:31 2009 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 19 Sep 2009 16:09:31 +0000 Subject: [New-bugs-announce] [issue6949] Support Berkeley DB 4.8 In-Reply-To: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za> Message-ID: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis : Python doesn't detect Berkeley DB 4.8. After updating setup.py, _bsddb module fails to build due to some changes in Berkeley DB. I'm attaching patch which seems to fix these problems. Changes in setup.py were made by me. Changes in Modules/_bsddb.c were copied from bsddb3-4.8.0 [1]. [1] http://www.jcea.es/programacion/pybsddb.htm ---------- components: Build files: python-support_bdb-4.8.patch keywords: patch messages: 92871 nosy: Arfrever severity: normal status: open title: Support Berkeley DB 4.8 versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file14933/python-support_bdb-4.8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 18:24:21 2009 From: report at bugs.python.org (kai zhu) Date: Sat, 19 Sep 2009 16:24:21 +0000 Subject: [New-bugs-announce] [issue6950] online documentation error: PyObject* PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len) In-Reply-To: <1253377461.16.0.726323849113.issue6950@psf.upfronthosting.co.za> Message-ID: <1253377461.16.0.726323849113.issue6950@psf.upfronthosting.co.za> New submission from kai zhu : according to bytearrayobject.c, PyByteArray_Resize should return int (not PyObject *) error found @ http://docs.python.org/dev/py3k/c-api/bytearray.html http://docs.python.org/c-api/bytearray.html ---------- assignee: georg.brandl components: Documentation messages: 92872 nosy: georg.brandl, kaizhu severity: normal status: open title: online documentation error: PyObject* PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len) versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 10:05:16 2009 From: report at bugs.python.org (Ned Deily) Date: Sun, 20 Sep 2009 08:05:16 +0000 Subject: [New-bugs-announce] [issue6951] OS X IDLE has two Preferences menus on 2.6.x with Tk > 8.4.7 In-Reply-To: <1253433916.83.0.225412308187.issue6951@psf.upfronthosting.co.za> Message-ID: <1253433916.83.0.225412308187.issue6951@psf.upfronthosting.co.za> New submission from Ned Deily : Release blocker On OS X IDLE 2.6 shows two Preference menu items, the second dimmed out, but only when running with an installed Tk 8.4 > 8.4.7. This is the same problem identified in Issue6100 and was fixed in trunk but not backported. Now that the Apple-supplied 8.4 Tk in 10.6 is 8.4.19, the problem is more serious on 2.6. The attached patch backports r72946 from trunk. ---------- assignee: ronaldoussoren components: IDLE, Macintosh files: patch-nad0027-26.txt messages: 92883 nosy: ned.deily, ronaldoussoren severity: normal status: open title: OS X IDLE has two Preferences menus on 2.6.x with Tk > 8.4.7 versions: Python 2.6 Added file: http://bugs.python.org/file14937/patch-nad0027-26.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 13:29:46 2009 From: report at bugs.python.org (Barry Alan Scott) Date: Sun, 20 Sep 2009 11:29:46 +0000 Subject: [New-bugs-announce] [issue6952] deprecated conversion from string constant to char * In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za> Message-ID: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za> New submission from Barry Alan Scott : Many Python API functions are causing GCC to rightly complain that const char * strings are being passed to python functions that take char * but do not need to modify the args. g++ reports example.cxx:633: warning: deprecated conversion from string constant to ?char*? The example I encountered today, while testing PyCXX against G++ 4.2.1 on Mac OS X, was PyObject_CallMethod but it is not limited to this function. Would a patch help progress this issue? ---------- components: Interpreter Core messages: 92890 nosy: barry-scott severity: normal status: open title: deprecated conversion from string constant to char * type: compile error versions: Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 16:13:32 2009 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 20 Sep 2009 14:13:32 +0000 Subject: [New-bugs-announce] [issue6953] readline documenation needs work In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za> Message-ID: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za> New submission from Ronald Oussoren : The documentation for the readline module is a bit too minimal. 1) function 'add_history' is described at the end of the documentation, not near the other functions for manipulation the history stack. 2) the index for remove_history_item and replace_history_item is 0- based, while the index for get_history_item is 1-based. The latter is a confusing API in the underlying readline library and should IMO be described in Python's documentation. (If readline were a new addition to the stdlib I'd prefer to fix the interface, but that would have too many backward compatibility issues at this point in time). ---------- assignee: georg.brandl components: Documentation messages: 92893 nosy: georg.brandl, ronaldoussoren severity: normal status: open title: readline documenation needs work type: feature request versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 22:27:43 2009 From: report at bugs.python.org (Ned Batchelder) Date: Sun, 20 Sep 2009 20:27:43 +0000 Subject: [New-bugs-announce] [issue6954] DISTUTILS_DEBUG causes stack trace, really simple fix In-Reply-To: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za> Message-ID: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za> New submission from Ned Batchelder : If you set the environment variable DISTUTILS_DEBUG=1, distutils will run with DEBUG, which will trace internal activity. But one of the traces is incorrect, and leads to this stack trace: Traceback (most recent call last): File "setup.py", line 116, in **more_setup_args File "c:\python31\lib\distutils\core.py", line 123, in setup dist.parse_config_files() File "c:\python31\lib\distutils\dist.py", line 357, in parse_config_files self.announce(" reading", filename) File "c:\python31\lib\distutils\dist.py", line 911, in announce log.log(level, msg) File "c:\python31\lib\distutils\log.py", line 31, in log self._log(level, msg, args) File "c:\python31\lib\distutils\log.py", line 20, in _log if level >= self.threshold: TypeError: unorderable types: str() >= int() The fix is simple: at line 356 of dist.py, change: if DEBUG: self.announce(" reading", filename) to: if DEBUG: self.announce(" reading " + filename) ---------- assignee: tarek components: Distutils messages: 92916 nosy: nedbat, tarek severity: normal status: open title: DISTUTILS_DEBUG causes stack trace, really simple fix versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 05:03:05 2009 From: report at bugs.python.org (lovelygoo2) Date: Mon, 21 Sep 2009 03:03:05 +0000 Subject: [New-bugs-announce] [issue6955] Max() Not Working Properly In-Reply-To: <1253502185.93.0.333528519987.issue6955@psf.upfronthosting.co.za> Message-ID: <1253502185.93.0.333528519987.issue6955@psf.upfronthosting.co.za> New submission from lovelygoo2 : >>> max(['34', '7']) '7' >>> #This happens because it is comparing strings. >>> #I have found a way to fix it though. >>> def Max(li): ... greatest=li[0] ... for item in li: ... for item2 in li: ... if int(item) _______________________________________ From report at bugs.python.org Mon Sep 21 12:54:21 2009 From: report at bugs.python.org (Michael Foord) Date: Mon, 21 Sep 2009 10:54:21 +0000 Subject: [New-bugs-announce] [issue6956] Test creation in unittest.TestProgram should be done in one place In-Reply-To: <1253530461.77.0.303608237398.issue6956@psf.upfronthosting.co.za> Message-ID: <1253530461.77.0.303608237398.issue6956@psf.upfronthosting.co.za> New submission from Michael Foord : Requested by Fernando Perez on the Testing in Python mailing list. Test creation in TestProgram is done in both parseArgs and createTests. It would be better if it was only done in createTests so that controlling test creation only required the overloading of a single method. > in TestProgram.parseArgs we have: > > if len(args) == 0 and self.defaultTest is None: > self.test = self.testLoader.loadTestsFromModule(self.module) > return > > and then later: > > def createTests(self): > self.test = self.testLoader.loadTestsFromNames(self.testNames, > self.module) > > So basically if you want to control how tests are created, you can't just override createTests, because parseArgs also does test creation > (but only sometimes, depending on certain conditions). > I think that parseArgs should perhaps only parse args, and createTests should only create tests, but I'm weird like that :) For the case > above, it could set a flag that createTests can then later use to decide what to do, but parseArgs shouldn't be doing test creation IMO. ---------- assignee: michael.foord components: Library (Lib) messages: 92929 nosy: michael.foord severity: normal stage: needs patch status: open title: Test creation in unittest.TestProgram should be done in one place type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 13:06:00 2009 From: report at bugs.python.org (Ned Deily) Date: Mon, 21 Sep 2009 11:06:00 +0000 Subject: [New-bugs-announce] [issue6957] Extension modules fail to build on OS X 10.6 using python.org 2.x/3.x In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za> Message-ID: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za> New submission from Ned Deily : Potential 2.6.3 release blocker On OS X 10.6 (Snow Leopard), if you attempt to install a package with a extension module using a Python from a python.org OS X installer (say, 2.6.x or 3.1.x), the c compilation steps will likely fail in one of two ways: 1. Recent python.org installers are built using the OS X 10.4 SDK so that one installer image will work on 10.4, 10.5 and now 10.6 (in theory, 10.3.x as well). Building of extension modules also require gcc and the SDKs, which are included as part of Apple's Xcode tools. However, with 10.6 Xcode, the 10.4 SDK is not installed by default so the extension module build will fail due to missing include files. Once the problem is known, it can be solved easily by installing the SDK from the release DVD that comes with the system or upgrade. 2. Even with the 10.4 SDK installed on 10.6, the compilation fails with: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory This can be especially baffling to those unfamiliar with nested include files because the base file stdarg.h does exist in that directory. The root cause here is that Snow Leopard now uses gcc-4.2 by default but the 10.4 SDK does not include headers for 4.2. The solution is to force use of gcc-4.0, the default on 10.4 and 10.5 and included in 10.6, by defining the CC environment variable: $ export CC=/usr/bin/gcc-4.0 $ python setup.py install or $ easy_install xxx Even for experienced developers, these can be non-trivial problems to resolve although the solutions, once known, are easy to implement. Unfortunately, all types of python users can run into these issues simply by trying to install and use a package that includes an extension module. There are a growing number of hits on the web from people trying to install popular packages such as MySQLdb, PIL, and lxml using a python.org Python on 10.6. Note this isn't a problem for users of the Apple-supplied Pythons (2.6 and 2.5) on 10.6 since they do not use the 10.4 SDK. There are two separate issues here I think: 1. What, if anything, to do for users of installers already out in the field? 2. What to do to mitigate the problems for yet-to-be released installers (e.g. 2.6.3)? Documenting and publicizing the problems somehow may be the only viable option for 1. For 2, there is the possibility of some additional actions, perhaps a warning in the installer readme or some such. It probably would make sense to contact the maintainers of such packages so that they can add something to their web pages and documentation. ---------- assignee: ronaldoussoren components: Extension Modules, Macintosh messages: 92930 nosy: ned.deily, ronaldoussoren severity: normal status: open title: Extension modules fail to build on OS X 10.6 using python.org 2.x/3.x versions: Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 13:23:17 2009 From: report at bugs.python.org (Thomas Heller) Date: Mon, 21 Sep 2009 11:23:17 +0000 Subject: [New-bugs-announce] [issue6958] Add Python command line flags to configure logging In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za> Message-ID: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za> New submission from Thomas Heller : I want the Python executable to have command line flags which allow simple configuration of the logging module. Use cases are to run applications/scripts (which use libraries that use logging calls) with different logging output without having to edit (ugly) logging config files. The attached patch demonstrates the idea; it allows to run 'python -l ...' and passes to a new function logging._parse_python_options(). ---------- components: Interpreter Core, Library (Lib) files: logging.patch keywords: patch messages: 92932 nosy: theller severity: normal status: open title: Add Python command line flags to configure logging type: feature request Added file: http://bugs.python.org/file14941/logging.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 20:46:12 2009 From: report at bugs.python.org (cscscs) Date: Mon, 21 Sep 2009 18:46:12 +0000 Subject: [New-bugs-announce] [issue6959] OS X 10.6 / Snow Leopard Message-ID: <1253558772.91.0.545762042171.issue6959@psf.upfronthosting.co.za> Changes by cscscs : ---------- nosy: cscscs severity: normal status: open title: OS X 10.6 / Snow Leopard type: compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 23:34:12 2009 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Sep 2009 21:34:12 +0000 Subject: [New-bugs-announce] [issue6960] test_telnetlib gives spurious output In-Reply-To: <1253568852.27.0.259606507401.issue6960@psf.upfronthosting.co.za> Message-ID: <1253568852.27.0.259606507401.issue6960@psf.upfronthosting.co.za> New submission from Antoine Pitrou : I just got the following traceback: Exception in thread Thread-538: Traceback (most recent call last): File "/home/antoine/py3k/__svn__/Lib/threading.py", line 509, in _bootstrap_inner self.run() File "/home/antoine/py3k/__svn__/Lib/threading.py", line 462, in run self._target(*self._args, **self._kwargs) File "/home/antoine/py3k/__svn__/Lib/test/test_telnetlib.py", line 25, in server conn, addr = serv.accept() File "/home/antoine/py3k/__svn__/Lib/socket.py", line 120, in accept fd, addr = self._accept() socket.error: [Errno 4] Interrupted system call Interestingly, it happens *after* test_telnetlib returned successfully. ---------- components: Tests messages: 92962 nosy: jackdied, pitrou priority: normal severity: normal status: open title: test_telnetlib gives spurious output type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 23:36:18 2009 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Sep 2009 21:36:18 +0000 Subject: [New-bugs-announce] [issue6961] test_distutils failure In-Reply-To: <1253568978.09.0.00053236217628.issue6961@psf.upfronthosting.co.za> Message-ID: <1253568978.09.0.00053236217628.issue6961@psf.upfronthosting.co.za> New submission from Antoine Pitrou : I get the following (deterministic) failure on the py3k branch: test_distutils 0 blocks find: `/home/antoine/tmp/tmpX6PtRb/foo/build/bdist.linux-x86_64/rpm/BUILDROOT/foo-0.1-1.x86_64/usr/lib/debug': Aucun fichier ou dossier de ce type 0 blocks find: `/home/antoine/tmp/tmpNJkuVH/foo/build/bdist.linux-x86_64/rpm/BUILDROOT/foo-0.1-1.x86_64/usr/lib/debug': Aucun fichier ou dossier de ce type test test_distutils failed -- Traceback (most recent call last): File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_util.py", line 145, in test_get_platform self.assertEquals(get_platform(), 'macosx-10.4-universal') AssertionError: 'macosx-10.4-intel' != 'macosx-10.4-universal' 1 test failed: test_distutils ---------- assignee: tarek components: Distutils, Tests messages: 92963 nosy: pitrou, tarek priority: normal severity: normal stage: needs patch status: open title: test_distutils failure type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 00:26:52 2009 From: report at bugs.python.org (thewtex) Date: Mon, 21 Sep 2009 22:26:52 +0000 Subject: [New-bugs-announce] [issue6962] traceback.format_exception_only does not return SyntaxError carot correctly In-Reply-To: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za> Message-ID: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za> New submission from thewtex : On Python 2.6.2, and possibly other versions, in the traceback module, format_exception_only does not behave correctly when printout out a SyntaxError. An extra newline is inserted before the carot. E.g. 38 exceptionType, exceptionValue, exceptionTraceback = sys.exc_info() 39 sys.stderr.write("Exception:\n") 40 ex = traceback.format_exception_only(exceptionType, exceptionValue) 41 sys.stderr.write(repr(ex)) 42 for line in ex: 43 sys.stderr.write(line) yields, e.g. Exception: [' File "/home/matt/apps/posac/source/posac/posac_main.py", line 12\n', ' def run()\n', ' \n^\n', 'SyntaxError: invalid syntax\n'] File "/home/matt/apps/posac/source/posac/posac_main.py", line 12 def run() ^ SyntaxError: invalid syntax When it should be: Exception: [' File "/home/matt/apps/posac/source/posac/posac_main.py", line 12\n', ' def run()\n', ' ^\n', 'SyntaxError: invalid syntax\n'] File "/home/matt/apps/posac/source/posac/posac_main.py", line 12 def run() ^ SyntaxError: invalid syntax Attached is a patch. This patch has been tested on gentoo linux. ---------- messages: 92966 nosy: thewtex severity: normal status: open title: traceback.format_exception_only does not return SyntaxError carot correctly type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 04:28:32 2009 From: report at bugs.python.org (Charles Cazabon) Date: Tue, 22 Sep 2009 02:28:32 +0000 Subject: [New-bugs-announce] [issue6963] Add worker process lifetime to multiprocessing.Pool - patch included In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za> Message-ID: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za> New submission from Charles Cazabon : Worker processes with multiprocessing.Pool live for the duration of the Pool. If the tasks they run happen to leak memory (from a C extension module, or from creating cycles of unreachable objects, etc) or open files or other resources, there's no easy way to clean them up. Similarly, if one task passed to the pool allocates a large amount of memory, but further tasks are small, that additional memory isn't returned to the system because the process involved hasn't exited. A common approach to this problem (as used by Apache, mod_wsgi, and various other software) is to allow worker processes to exit (and be replaced with fresh processes) after completing a specified amount of work. The attached patch (against Python 2.6.2, but applies to various other versions with some fuzz) implements this as optional new behaviour in multiprocessing.Pool(). An additional optional argument is specified for the maximum number of tasks a worker process performs before it exits and is replaced with a fresh worker process. ---------- components: Library (Lib) files: worker-lifetime-python2.6.2.patch keywords: patch messages: 92971 nosy: charlesc severity: normal status: open title: Add worker process lifetime to multiprocessing.Pool - patch included type: feature request versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file14946/worker-lifetime-python2.6.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 11:16:48 2009 From: report at bugs.python.org (Rene Dudfield) Date: Tue, 22 Sep 2009 09:16:48 +0000 Subject: [New-bugs-announce] [issue6964] import new fails In-Reply-To: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za> Message-ID: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za> New submission from Rene Dudfield : python3.1 >>> import new Traceback (most recent call last): File "", line 1, in ImportError: No module named new 2to3-3.1 doesn't mention how to change it. ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 92974 nosy: illume severity: normal status: open title: import new fails type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 11:21:58 2009 From: report at bugs.python.org (djc) Date: Tue, 22 Sep 2009 09:21:58 +0000 Subject: [New-bugs-announce] [issue6965] tmpnam should not be used if tempfile or mkstemp are available In-Reply-To: <1253611318.55.0.148600850079.issue6965@psf.upfronthosting.co.za> Message-ID: <1253611318.55.0.148600850079.issue6965@psf.upfronthosting.co.za> New submission from djc : I have a bug report in the Gentoo tracker (http://bugs.gentoo.org/show_bug.cgi?id=221183): "This is a rather strange request, but please bear me. While building Posix module, python checks (among others) for tmpfile, tmpnam and tmpnam_r however man pages state explicitly, that in case tmpfile is available, other two should not be used if libpython2.5.a is built with either of them, linker complains each time it's added While this doesn't break anything, it's still a bit annoying. so I propose to remove functionality as an enhancement: to change in Modules/posixmodule.c #ifdef HAVE_TMPNAM to #ifdef HAVE_TMPNAM && !defined(HAVE_TMPFILE) Your thoughts?" man 3 tmpnam state "Never use this function. Use mkstemp(3) or tmpfile(3) instead.". Not sure whether this is exposed anywhere, but I figured this bug would be better handled upstream from Gentoo. ---------- components: Extension Modules messages: 92975 nosy: djc severity: normal status: open title: tmpnam should not be used if tempfile or mkstemp are available versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 11:28:07 2009 From: report at bugs.python.org (Johan Tufvesson) Date: Tue, 22 Sep 2009 09:28:07 +0000 Subject: [New-bugs-announce] [issue6966] Ability to refer to arguments in TestCase.fail* methods In-Reply-To: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za> Message-ID: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za> New submission from Johan Tufvesson : In the unittest module, TestCase class: If one wants to provide a more descriptive fail message compared to the default, it is often valuable to be able to refer to the arguments evaluated by the fail*- (or assert*-) method. This can be accomplished by binding names to the evaluated values before the call to the fail*-methods, and then providing a string with the values embedded as needed. This, however, can be quite cumbersome when there are a lot of calls to fail*-methods. Today: Arg1 = RealValue() Arg2 = ExpectedValue() self.failUnlessEqual(Arg1, Arg2, "Got {0}, but expected {1}.".format(Arg1, Arg2)) Proposed solution: In the fail*-methods, check if the msg argument is some kind of string (basestring?), and run the format() method on the string with the supplied arguments. This would result in code like this: self.failUnlessEqual(RealValue(), ExpectedValue(), "Got {0}, but expected {1}.") ---------- components: Library (Lib) messages: 92977 nosy: tuben severity: normal status: open title: Ability to refer to arguments in TestCase.fail* methods type: feature request versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 12:21:23 2009 From: report at bugs.python.org (Sascha) Date: Tue, 22 Sep 2009 10:21:23 +0000 Subject: [New-bugs-announce] [issue6967] codec windows1256 should be windows windows-1256 In-Reply-To: <1253614883.36.0.531547285438.issue6967@psf.upfronthosting.co.za> Message-ID: <1253614883.36.0.531547285438.issue6967@psf.upfronthosting.co.za> New submission from Sascha : It seem that there's a dash missing. http://docs.python.org/dev/library/codecs.html#standard-encodings >>> u'Sorry, this in here makes no sense'.encode('windows1256') Traceback (most recent call last): File "", line 1, in LookupError: unknown encoding: windows1256 On the other hand windows-1256 works. ---------- assignee: georg.brandl components: Documentation files: codecs.rst.patch keywords: patch messages: 92980 nosy: DerSascha, georg.brandl severity: normal status: open title: codec windows1256 should be windows windows-1256 versions: Python 2.5, Python 2.7, Python 3.1 Added file: http://bugs.python.org/file14948/codecs.rst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 14:32:57 2009 From: report at bugs.python.org (Rene Dudfield) Date: Tue, 22 Sep 2009 12:32:57 +0000 Subject: [New-bugs-announce] [issue6968] numpy extensions to distutils... are a source of improvements for distutils In-Reply-To: <1253622777.76.0.936745302949.issue6968@psf.upfronthosting.co.za> Message-ID: <1253622777.76.0.936745302949.issue6968@psf.upfronthosting.co.za> New submission from Rene Dudfield : Hi, numpy includes a numpy/distutils package which has a lot of goodies/fixes which might be able to be incorporated into the main distutils. Adding this note so distutils maintainers are aware of it. cheers, ---------- assignee: tarek components: Distutils messages: 92986 nosy: illume, tarek severity: normal status: open title: numpy extensions to distutils... are a source of improvements for distutils type: feature request _______________________________________ Python tracker