From report at bugs.python.org Sat Nov 1 15:59:31 2008 From: report at bugs.python.org (robwolfe) Date: Sat, 01 Nov 2008 14:59:31 +0000 Subject: [New-bugs-announce] [issue4246] execution model - clear and complete example in documentation In-Reply-To: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za> Message-ID: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za> New submission from robwolfe : I'd like to propose adding some complete example regarding scopes and bindings resolving to execution model description. There is no week on pl.comp.lang.python without a question about UnboundLocalError problem. I'm getting tired answering that. ;-) It does not have to look so verbose as my (attached) example, but please add some example, which will clarify this issue. ---------- assignee: georg.brandl components: Documentation files: scopes.py messages: 75441 nosy: georg.brandl, robwolfe severity: normal status: open title: execution model - clear and complete example in documentation type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file11924/scopes.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 2 03:16:03 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Sun, 02 Nov 2008 02:16:03 +0000 Subject: [New-bugs-announce] [issue4247] Docs: Provide some examples of "pass" use in the tutorial. In-Reply-To: <1225592163.24.0.267149626837.issue4247@psf.upfronthosting.co.za> Message-ID: <1225592163.24.0.267149626837.issue4247@psf.upfronthosting.co.za> New submission from Sean Reifschneider : I'm giving a Python tutorial to a bunch of local people and have decided to use the Python.org tutorial to go by. One of the things I found I wanted in the section on the "pass" statement was more information about it's use. But I also think it's worth mentioning using the NotImplementedError if pass is used for stubbing out code. This patch to the tutorial includes some example use cases, and also a reference to NotImplementedError. I would appreciate some review however, as I'm not sure this discussion is appropriate. Included below is the patch, for ease of reading, but it's also attached as a patch (taken against trunk today). Sean =========== Index: Doc/tutorial/controlflow.rst =================================================================== --- Doc/tutorial/controlflow.rst (revision 67072) +++ Doc/tutorial/controlflow.rst (working copy) @@ -166,7 +166,36 @@ ... pass # Busy-wait for keyboard interrupt (Ctrl+C) ... +This is commonly used for creating minimal classes like with exceptions, or +for skipping unwanted exceptions:: + >>> class ParserError(Exception): + ... pass + ... + >>> try: + ... import audioop + ... except ImportError: + ... pass + ... + +Another place it can be used is as a place-holder for a function or +conditional body when you are working on new code, allowing you to keep +thinking at a more abstract level. However, as :keyword:`pass` is silently +ignored, a better choice may be to raise a :exc:`NotImplementedError` +exception:: + + >>> def initlog(*args): + ... raise NotImplementedError # Open logfile if not already open + ... if not logfp: + ... raise NotImplementedError # Set up dummy log back-end + ... raise NotImplementedError # Call log initialization handler + ... + +If :keyword:`pass` were used here and you later ran tests, they may fail +without indicating why. Using :exc:`NotImplementedError` causes this code +to raise an exception, allowing you to tell exactly where code that you +need to complete is. + .. _tut-functions: Defining Functions ---------- assignee: fdrake components: Documentation files: pass-examples.patch keywords: easy, needs review, patch, patch messages: 75452 nosy: fdrake, jafo priority: normal severity: normal status: open title: Docs: Provide some examples of "pass" use in the tutorial. type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file11926/pass-examples.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 2 05:32:24 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sun, 02 Nov 2008 04:32:24 +0000 Subject: [New-bugs-announce] [issue4248] "class in None" in html help keyword In-Reply-To: <1225600344.66.0.90175485782.issue4248@psf.upfronthosting.co.za> Message-ID: <1225600344.66.0.90175485782.issue4248@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : I noticed built-in class `set` uses "set (class in None)" as index keyword. Please see attached file "snapshot.png". I think "set (builtin class)" or something is better. ---------- assignee: georg.brandl components: Documentation, Windows files: snapshot.png messages: 75453 nosy: georg.brandl, ocean-city severity: normal status: open title: "class in None" in html help keyword versions: Python 2.6 Added file: http://bugs.python.org/file11927/snapshot.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 2 15:56:55 2008 From: report at bugs.python.org (Jon Perez) Date: Sun, 02 Nov 2008 14:56:55 +0000 Subject: [New-bugs-announce] [issue4249] HTTPResponse instance has no attribute 'code' In-Reply-To: <1225637815.26.0.704125161046.issue4249@psf.upfronthosting.co.za> Message-ID: <1225637815.26.0.704125161046.issue4249@psf.upfronthosting.co.za> New submission from Jon Perez : In http_response in HTTPErrorProcessor, the following line code, msg, hdrs = response.code, response.msg, response.info() results in an error because response.code is not a valid attribute, changing it to response.status works, but is this the correct bug fix? See http://www.linuxquestions.org/questions/linux-newbie-8/problem-with-yum-fedora-9-670586/ Traceback (most recent call last): File "/usr/bin/yum", line 30, in yummain.main(sys.argv[1:]) File "/usr/share/yum/yummain.py", line 233, in main clientStuff.get_package_info_from_servers(serverlist, HeaderInfo) File "/usr/share/yum/clientStuff.py", line 846, in get_package_info_from_servers progress_obj=None) File "/usr/share/yum/clientStuff.py", line 1327, in grab bandwidth, conf.retries, retrycodes, checkfunc) File "/usr/share/yum/urlgrabber.py", line 237, in retrygrab progress_obj, throttle, bandwidth) File "/usr/share/yum/urlgrabber.py", line 314, in urlgrab fo = urllib2.urlopen(url) File "/usr/lib/python2.5/urllib2.py", line 121, in urlopen return _opener.open(url, data) File "/usr/lib/python2.5/urllib2.py", line 380, in open response = meth(req, response) File "/usr/lib/python2.5/urllib2.py", line 487, in http_response code, msg, hdrs = response.code, response.msg, response.info() AttributeError: HTTPResponse instance has no attribute 'code' ---------- components: Library (Lib) messages: 75454 nosy: jbperz808 severity: normal status: open title: HTTPResponse instance has no attribute 'code' type: behavior versions: Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 2 15:57:17 2008 From: report at bugs.python.org (Jon Perez) Date: Sun, 02 Nov 2008 14:57:17 +0000 Subject: [New-bugs-announce] [issue4250] urllib2.py: HTTPResponse instance has no attribute 'code' In-Reply-To: <1225637837.09.0.0534571588639.issue4250@psf.upfronthosting.co.za> Message-ID: <1225637837.09.0.0534571588639.issue4250@psf.upfronthosting.co.za> New submission from Jon Perez : In http_response() in HTTPErrorProcessor in urllib2.py, the following line code, msg, hdrs = response.code, response.msg, response.info() results in an error because response.code is not a valid attribute, changing it to response.status works, but is this the correct bug fix? See http://www.linuxquestions.org/questions/linux-newbie-8/problem-with-yum-fedora-9-670586/ Traceback (most recent call last): File "/usr/bin/yum", line 30, in yummain.main(sys.argv[1:]) File "/usr/share/yum/yummain.py", line 233, in main clientStuff.get_package_info_from_servers(serverlist, HeaderInfo) File "/usr/share/yum/clientStuff.py", line 846, in get_package_info_from_servers progress_obj=None) File "/usr/share/yum/clientStuff.py", line 1327, in grab bandwidth, conf.retries, retrycodes, checkfunc) File "/usr/share/yum/urlgrabber.py", line 237, in retrygrab progress_obj, throttle, bandwidth) File "/usr/share/yum/urlgrabber.py", line 314, in urlgrab fo = urllib2.urlopen(url) File "/usr/lib/python2.5/urllib2.py", line 121, in urlopen return _opener.open(url, data) File "/usr/lib/python2.5/urllib2.py", line 380, in open response = meth(req, response) File "/usr/lib/python2.5/urllib2.py", line 487, in http_response code, msg, hdrs = response.code, response.msg, response.info() AttributeError: HTTPResponse instance has no attribute 'code' ---------- components: Library (Lib) messages: 75455 nosy: jbperz808 severity: normal status: open title: urllib2.py: HTTPResponse instance has no attribute 'code' type: behavior versions: Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 2 22:51:45 2008 From: report at bugs.python.org (Winfried Plappert) Date: Sun, 02 Nov 2008 21:51:45 +0000 Subject: [New-bugs-announce] [issue4251] library.pdf documentation: "See also: Module " does not link to xxx inside the PDF File In-Reply-To: <1225662705.73.0.76676836667.issue4251@psf.upfronthosting.co.za> Message-ID: <1225662705.73.0.76676836667.issue4251@psf.upfronthosting.co.za> New submission from Winfried Plappert : I take chapter "19.12 base64?RFC 3548: Base16, Base32, Base64 Data Encodings" (Python 2.6) as an example. At the bottom of the chapter, you find references to other resouces, in this case: See Also: Module binascii Support module containing ASCII-to-binary and binary-to-ASCII conversions. RFC 1521 - MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Section 5.2, ?Base64 Content-Transfer-Encoding,? provides the definition of the base64 encoding. Interestingly enough RFC 1521 points to a web page (the link has been removed in the current HTML documentation). However "Module binascii" does not link to binascii in the library.pdf, whereas the HTML documentation nicely links to http://docs.python.org/library/binascii.html. The file base64.rst IMO indicates that a link should be produced: .. seealso:: Module :mod:`binascii` Support module containing ASCII-to-binary and binary-to-ASCII conversions. :rfc:`1521` - MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies Section 5.2, "Base64 Content-Transfer-Encoding," provides the definition of the base64 encoding. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 75456 nosy: georg.brandl, wplappert severity: normal status: open title: library.pdf documentation: "See also: Module " does not link to xxx inside the PDF File versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 3 02:44:27 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 03 Nov 2008 01:44:27 +0000 Subject: [New-bugs-announce] [issue4252] inactive item not shown in html help index pane In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za> Message-ID: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : Please see index_on_firefox.png and index_on_htmlhelp.png. "and" is inactive item not linking to any page, but this item is not shown in htmlhelp. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) files: index_on_firefox.png messages: 75459 nosy: georg.brandl, ocean-city severity: normal status: open title: inactive item not shown in html help index pane versions: Python 2.6 Added file: http://bugs.python.org/file11929/index_on_firefox.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 3 09:18:44 2008 From: report at bugs.python.org (Marcus CM) Date: Mon, 03 Nov 2008 08:18:44 +0000 Subject: [New-bugs-announce] [issue4253] Maildir dumpmessage on In-Reply-To: <1225700324.91.0.938996340802.issue4253@psf.upfronthosting.co.za> Message-ID: <1225700324.91.0.938996340802.issue4253@psf.upfronthosting.co.za> New submission from Marcus CM : When using maildir on windows, the maildir._dump_message erronously added "\r\n" to "\r\r\n" : in mailbox.py target.write(buffer.read().replace('\n', os.linesep)) ---------- components: Library (Lib) messages: 75463 nosy: marcus at internetnowasp.net severity: normal status: open title: Maildir dumpmessage on versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 3 16:02:09 2008 From: report at bugs.python.org (Roland Brickl) Date: Mon, 03 Nov 2008 15:02:09 +0000 Subject: [New-bugs-announce] [issue4254] _cursesmodule.c callable update_lines_cols() In-Reply-To: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za> Message-ID: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za> New submission from Roland Brickl : curses.update_lines.cols() are normally usable within c programs. With this change, it can now be used too. It only calls the preexisting function that where only used internally. The cast in the return statement are possibly false? But it works. Because this aren't a big change, it would apply to some more python-versions. ---------- components: Extension Modules files: _curses.diff keywords: patch messages: 75464 nosy: nemesis severity: normal status: open title: _cursesmodule.c callable update_lines_cols() type: feature request versions: Python 2.5 Added file: http://bugs.python.org/file11932/_curses.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 3 17:03:03 2008 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 03 Nov 2008 16:03:03 +0000 Subject: [New-bugs-announce] [issue4255] timing module refers to non-existent documentation In-Reply-To: <1225728183.22.0.203004248032.issue4255@psf.upfronthosting.co.za> Message-ID: <1225728183.22.0.203004248032.issue4255@psf.upfronthosting.co.za> New submission from Steven D'Aprano : import timing help(timing) => MODULE DOCS http://www.python.org/doc/current/lib/module-timing.html but there doesn't appear to be any such page: the URL gives Error 404: File Not Found. Searching the reference library for "timing" doesn't find anything that looks relevant. ---------- assignee: georg.brandl components: Documentation messages: 75466 nosy: georg.brandl, stevenjd severity: normal status: open title: timing module refers to non-existent documentation versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 3 17:30:54 2008 From: report at bugs.python.org (Andy Buckley) Date: Mon, 03 Nov 2008 16:30:54 +0000 Subject: [New-bugs-announce] [issue4256] optparse: provide a simple way to get a programmatically useful list of options In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za> Message-ID: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za> New submission from Andy Buckley : optparse is a great option parser, but one thing that would make it even greater would be if it provided a standard option (cf. --help) which lists all the available options in a parseable form. Something prefixed with --help, e.g. --help-options would be ideal since it doesn't clutter the option namespace. This would provide a simple command-line hook for e.g. bash completion customisation with complete/compgen, which could then easily and maintainably obtain the list of available switches via the --help-options flag rather than hard-coding the option names or attempting to grep the output of --help It would also be good if the OptionParser provided a simple Python API way to obtain the names of all option switches, rather than having to loop over OptionGroups, calling the unadvertised 'option_list' and 'get_option_name' methods! ---------- components: Library (Lib) messages: 75469 nosy: andybuckley severity: normal status: open title: optparse: provide a simple way to get a programmatically useful list of options type: feature request versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 3 20:46:40 2008 From: report at bugs.python.org (Roy Smith) Date: Mon, 03 Nov 2008 19:46:40 +0000 Subject: [New-bugs-announce] [issue4257] Documentation for socket.gethostname() needs tweaking In-Reply-To: <1225741600.75.0.864264407654.issue4257@psf.upfronthosting.co.za> Message-ID: <1225741600.75.0.864264407654.issue4257@psf.upfronthosting.co.za> New submission from Roy Smith : The docs say: Return a string containing the hostname of the machine where the Python interpreter is currently executing. If you want to know the current machine's IP address, you may want to use gethostbyname(gethostname()). This operation assumes... It is not clear what the referent of "This" is. Are you saying that gethostname() itself makes that assumption, or the use of gethostbyname() to turn what gethostname() returns into an address makes that assumption? I think it's the latter, but the sentence should be reworded to make it clear. ---------- assignee: georg.brandl components: Documentation messages: 75476 nosy: georg.brandl, roysmith severity: normal status: open title: Documentation for socket.gethostname() needs tweaking versions: Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 4 11:45:12 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 04 Nov 2008 10:45:12 +0000 Subject: [New-bugs-announce] [issue4258] Use 30-bit digits instead of 15-bit digits for Python integers. In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za> Message-ID: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za> New submission from Mark Dickinson : Here's an experimental patch, against the py3k branch, that makes Python represent its long integers internally in base 2**30 instead of base 2**15, on platforms that have 32-bit and 64-bit integers available. On platforms for which autoconf is unable to find both 32-bit and 64-bit integers, the representation falls back to the usual one. See also issue 1814 (GMP for longs), and the discussion at http://mail.python.org/pipermail/python-dev/2008-November/083315.html (note particularly Tim Peter's message at: http://mail.python.org/pipermail/python-dev/2008-November/083355.html ) ---------- components: Interpreter Core files: 30bit_longdigit.patch keywords: patch messages: 75491 nosy: marketdickinson severity: normal status: open title: Use 30-bit digits instead of 15-bit digits for Python integers. type: performance versions: Python 3.1 Added file: http://bugs.python.org/file11935/30bit_longdigit.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 4 22:34:07 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 04 Nov 2008 21:34:07 +0000 Subject: [New-bugs-announce] [issue4259] Update pydoc URLs In-Reply-To: <1225834447.95.0.927155878948.issue4259@psf.upfronthosting.co.za> Message-ID: <1225834447.95.0.927155878948.issue4259@psf.upfronthosting.co.za> New submission from A.M. Kuchling : The URL for module documentation generated by pydoc is no longer valid. The attached patch corrects it for Python 2.5.3 by assembling the URL using the Python version. This patch shouldn't be forward-ported to 2.6 or 2.7; Sphinx changes the URL pattern further, and 2.6 and 2.7 take this into account and get their URLs correct. ---------- files: pydoc-patch.txt messages: 75509 nosy: akuchling severity: normal status: open title: Update pydoc URLs versions: Python 2.5.3 Added file: http://bugs.python.org/file11943/pydoc-patch.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 5 06:51:03 2008 From: report at bugs.python.org (David W. Lambert) Date: Wed, 05 Nov 2008 05:51:03 +0000 Subject: [New-bugs-announce] [issue4260] ctypes.xFUNCTYPE are decorators. In-Reply-To: <1225864263.85.0.365773038706.issue4260@psf.upfronthosting.co.za> Message-ID: <1225864263.85.0.365773038706.issue4260@psf.upfronthosting.co.za> New submission from David W. Lambert : http://docs.python.org/dev/3.0/library/ctypes.html#callback-functions ctypes.xFUNCTYPE are another opportunity to advertise decorators. Please consider inserting yet another qsort example written as a decorator, perhaps as follows. Or---it could be that I'm slow and the average pythonista will figure this out on first read. @CFUNCTYPE(c_int, POINTER(c_int), POINTER(c_int)) def py_cmp_func(*args): (a,b,) = (t[0] for t in args) print("py_cmp_func", a, b) return a-b qsort(ia,len(ia),sizeof(c_int),py_cmp_func) ---------- assignee: georg.brandl components: Documentation messages: 75515 nosy: LambertDW, georg.brandl severity: normal status: open title: ctypes.xFUNCTYPE are decorators. type: feature request versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 5 09:19:22 2008 From: report at bugs.python.org (=?utf-8?q?Peter_=C3=85strand?=) Date: Wed, 05 Nov 2008 08:19:22 +0000 Subject: [New-bugs-announce] [issue4261] The pwd module doesn't distinguish between errors and no user In-Reply-To: <1225873162.85.0.693443096685.issue4261@psf.upfronthosting.co.za> Message-ID: <1225873162.85.0.693443096685.issue4261@psf.upfronthosting.co.za> New submission from Peter ?strand : The getpwnam function in the pwd module does not correctly distinguish between the case when the user does not exist and error conditions. getpwnam() returns NULL in both cases, the the calling code needs to check errno to determine if an error occured or not. This bug is problematic in conjunction with bug https://bugzilla.redhat.com/show_bug.cgi?id=470003, since it means that Pythons getpwnam() will sometimes raise KeyError even for valid users. How to reproduce: $ python Python 2.4.3 (#1, Jan 14 2008, 18:32:40) [GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pwd >>> pwd.getpwnam("astrand") ('astrand', '*', 164, 20164, 'Peter Astrand', '/home/astrand', '/bin/bash') >>> >>> pwd.getpwnam("astrand") Traceback (most recent call last): File "", line 1, in ? KeyError: 'getpwnam(): name not found: astrand' >>> >>> pwd.getpwnam("astrand") ('astrand', '*', 164, 20164, 'Peter Astrand', '/home/astrand', '/bin/bash') >>> I was restarting the OpenLDAP server between the first successful call and the traceback one. ---------- components: Library (Lib) messages: 75516 nosy: astrand severity: normal status: open title: The pwd module doesn't distinguish between errors and no user type: behavior versions: Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 5 11:57:28 2008 From: report at bugs.python.org (Mark Seaborn) Date: Wed, 05 Nov 2008 10:57:28 +0000 Subject: [New-bugs-announce] [issue4262] import and compile() do not treat trailing whitespace the same In-Reply-To: <1225882648.97.0.627285996609.issue4262@psf.upfronthosting.co.za> Message-ID: <1225882648.97.0.627285996609.issue4262@psf.upfronthosting.co.za> New submission from Mark Seaborn : compile() raises a SyntaxError if the source code it is given contains trailing spaces or a trailing carriage return character, but this does happen if the same source code is imported or executed. import subprocess data = "if True:\n pass\n " filename = "/tmp/test.py" fh = open(filename, "w") fh.write(data) fh.close() subprocess.check_call(["python", filename]) subprocess.check_call(["python", "-c", "import test"], cwd="/tmp") compile(data, filename, "exec") This gives: Traceback (most recent call last): File "whitespace.py", line 11, in compile(data, filename, "exec") File "/tmp/test.py", line 3 SyntaxError: invalid syntax This also happens if the data is changed to: data = "if True:\n pass\r" ---------- components: Interpreter Core messages: 75521 nosy: mseaborn severity: normal status: open title: import and compile() do not treat trailing whitespace the same type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 5 19:23:29 2008 From: report at bugs.python.org (Banesiu Sever) Date: Wed, 05 Nov 2008 18:23:29 +0000 Subject: [New-bugs-announce] [issue4263] BufferedWriter non-blocking overage In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za> Message-ID: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za> New submission from Banesiu Sever : In some corner cases io.BufferedWriter raises an io.BlockingIOError "lying" about the number of characters written. I've added some tests and a small change to fix this issue. ---------- components: Library (Lib) files: bw_overage.diff keywords: patch messages: 75523 nosy: banesiu.sever severity: normal status: open title: BufferedWriter non-blocking overage versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file11945/bw_overage.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 5 20:31:33 2008 From: report at bugs.python.org (David Turner) Date: Wed, 05 Nov 2008 19:31:33 +0000 Subject: [New-bugs-announce] [issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za> Message-ID: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za> New submission from David Turner : This is a patch to Tom Lee's AST optimization branch. Python bytecode includes at least one operation which is not directly accessible from Python code: LIST_APPEND, which pops a value and a list off the stack and appends the value to the list. This is used in generating code for list comprehensions: [x for x in somelist] generates the following code for the body of the loop: ... LOAD_FAST 1#a local is generated to hold the new list LOAD_FAST 2 #the iteration variable, x LIST_APPEND ... Whereas if you were to try to write the comprehension directly, you would get: LOAD_FAST 1 LOAD_ATTR 0 #an index into the constant table: ?append? LOAD_FAST 2 CALL_FUNCTION 1 #remove x and the append function from the top of the stack and push the result of the call POP_TOP This is much slower. In part, it?s the cost of doing the attribute lookup each time, which is why it?s common to see code like a = [] ap = a.append for x in ?..: ap(x + ?) return a But the function call is naturally slower than the simpler LIST_APPEND operation. The attached patch tries to determine statically if a local is all circumstances holds a list, and if so, generates LIST_APPEND whenever user code would call local.append. It?s not perfect ? in particular, I could track local types on a more fine-grained level than per-function. But it?s a start. ---------- files: tlee-ast-optimize-appends.diff keywords: patch messages: 75525 nosy: novalis_dt severity: normal status: open title: Patch: optimize code to use LIST_APPEND instead of calling list.append Added file: http://bugs.python.org/file11946/tlee-ast-optimize-appends.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 5 21:26:18 2008 From: report at bugs.python.org (Ammon Riley) Date: Wed, 05 Nov 2008 20:26:18 +0000 Subject: [New-bugs-announce] [issue4265] shutil.copyfile() leaks file descriptors when disk fills In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za> Message-ID: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za> New submission from Ammon Riley : If the disk fills up during the copy operation, shutil.copyfile() leaks file descriptors. The problem is the order of the close() statements in the finally block. In the event the copy operation runs out of disk space, the fdst.close() call triggers an IOError, which prevents the fsrc.close() call from being called. Swapping the two calls, so that fsrc is closed first prevents this issue, though it doesn't solve the underlying problem that IOErrors raised during the close() operation will prevent the second close() from being called. A probably better solution: def copyfile(src, dst): """Copy data from src to dst""" if _samefile(src, dst): raise Error, "`%s` and `%s` are the same file" % (src, dst) fsrc = None fdst = None try: fsrc = open(src, 'rb') fdst = open(dst, 'wb') copyfileobj(fsrc, fdst) finally: try: if fsrc: fsrc.close() finally: if fdst: fdst.close() ---------- components: Library (Lib) messages: 75530 nosy: ammon_riley severity: normal status: open title: shutil.copyfile() leaks file descriptors when disk fills type: resource usage versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 6 05:14:55 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 06 Nov 2008 04:14:55 +0000 Subject: [New-bugs-announce] [issue4266] Python 3.0 docs are broken. In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za> Message-ID: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za> New submission from Barry A. Warsaw : The Python 3.0 documentation is broken. This is blocking the 3.0rc2 release. I'm too tired right now to figure out what the base problem is. This was during the ".../release.py --export 3.0rc2" build phase. pdflatex 'c-api.tex' This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) entering extended mode (./c-api.tex LaTeX2e <2003/12/01> Babel and hyphenation patterns for american, french, german, ngerman, b ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur kish, ukrainian, nohyphenation, loaded. (./manual.cls Document Class: manual 2008/10/18 Document class (Sphinx manual) (/opt/local/share/texmf-dist/tex/latex/base/report.cls Document Class: report 2004/02/16 v1.4f Standard LaTeX document class (/opt/local/share/texmf-dist/tex/latex/base/size10.clo))) (/opt/local/share/texmf-dist/tex/latex/base/inputenc.sty (/opt/local/share/texmf-dist/tex/latex/base/utf8.def (/opt/local/share/texmf-dist/tex/latex/base/t1enc.dfu) (/opt/local/share/texmf-dist/tex/latex/base/ot1enc.dfu) (/opt/local/share/texmf-dist/tex/latex/base/omsenc.dfu))) (/opt/local/share/texmf-dist/tex/latex/base/fontenc.sty (/opt/local/share/texmf-dist/tex/latex/base/t1enc.def)) (/opt/local/share/texmf-dist/tex/generic/babel/babel.sty (/opt/local/share/texmf-dist/tex/generic/babel/english.ldf (/opt/local/share/texmf-dist/tex/generic/babel/babel.def))) (/opt/local/share/texmf-dist/tex/latex/psnfss/times.sty) (./fncychap.sty) (./sphinx.sty (/opt/local/share/texmf-dist/tex/latex/base/textcomp.sty (/opt/local/share/texmf-dist/tex/latex/base/ts1enc.def (/opt/local/share/texmf-dist/tex/latex/base/ts1enc.dfu))) (/opt/local/share/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty) (/opt/local/share/texmf-dist/tex/latex/fancybox/fancybox.sty Style option: `fancybox' v1.3 <2000/09/19> (tvz) ) (/opt/local/share/texmf-dist/tex/latex/titlesec/titlesec.sty) (./tabulary.sty (/opt/local/share/texmf-dist/tex/latex/tools/array.sty)) (/opt/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/opt/local/share/texmf-dist/tex/latex/amsmath/amstext.sty (/opt/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/opt/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/opt/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/opt/local/share/texmf-dist/tex/latex/base/makeidx.sty) (/opt/local/share/texmf-dist/tex/latex/framed/framed.sty) (/opt/local/share/texmf-dist/tex/latex/graphics/color.sty (/opt/local/share/texmf-dist/tex/latex/graphics/color.cfg) (/opt/local/share/texmf-dist/tex/latex/graphics/pdftex.def)) (/opt/local/share/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty Style option: `fancyvrb' v2.6, with DG/SPQR fixes <1998/07/17> (tvz) (/opt/local/share/texmf-dist/tex/latex/graphics/keyval.sty) No file fancyvrb.cfg. ) (/opt/local/share/texmf-dist/tex/latex/graphics/graphicx.sty (/opt/local/share/texmf-dist/tex/latex/graphics/graphics.sty (/opt/local/share/texmf-dist/tex/latex/graphics/trig.sty) (/opt/local/share/texmf-dist/tex/latex/graphics/graphics.cfg))) (/opt/local/share/texmf-dist/tex/plain/pdfcolor/pdfcolor.tex) ! Extra \fi. l.62 \fi\fi ? ---------- assignee: georg.brandl components: Documentation messages: 75544 nosy: barry, georg.brandl priority: release blocker severity: normal stage: needs patch status: open title: Python 3.0 docs are broken. type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 6 08:48:17 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Thu, 06 Nov 2008 07:48:17 +0000 Subject: [New-bugs-announce] [issue4267] sqlite3 documentation In-Reply-To: <1225957697.4.0.46686050905.issue4267@psf.upfronthosting.co.za> Message-ID: <1225957697.4.0.46686050905.issue4267@psf.upfronthosting.co.za> New submission from Gabriel Genellina : Three small changes to sqlite3 documentation: 1) (mostly cosmetic) In the second example, changed what was "a tuple of tuples" to "a list of tuples" to follow common practice. 2) "DEFERRED", "IMMEDIATE" and "EXLUSIVE" (possible values for Connection.isolation_level) are strings, not module constants, so should be surrounded with quotes. 2) The iterdump example is not well written. Currently says: con = sqlite3.connect('existing_db.db') full_dump = os.linesep.join(con.iterdump()) f = open('dump.sql', 'w') f.writelines(full_dump) f.close() Using os.linesep to join lines to be written to a text file has strange results in non-Unix systems; joining the *whole* database dump into a big string isn't a good idea; and finally, writelines(some_string) will write the text one char at a time (!). I've rewritten it as: with open('dump.sql', 'w') as f: for line in con.iterdump(): f.write('%s\n' % line) to take advantage of iterdump's lazy nature. ---------- assignee: georg.brandl components: Documentation files: sqlite3.diff keywords: patch messages: 75548 nosy: gagenellina, georg.brandl severity: normal status: open title: sqlite3 documentation versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11949/sqlite3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 6 10:48:12 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Thu, 06 Nov 2008 09:48:12 +0000 Subject: [New-bugs-announce] [issue4268] functions in email package listed under wrong module In-Reply-To: <1225964892.7.0.454643269656.issue4268@psf.upfronthosting.co.za> Message-ID: <1225964892.7.0.454643269656.issue4268@psf.upfronthosting.co.za> New submission from Gabriel Genellina : Functions message_from_string and message_from_file are documented as belonging to the email.parser module, but in fact they live at the top of the email package. The .rst source looks fine, but the rendered html says `email.parser.message_from_string`. http://docs.python.org/library/email.parser.html#parser-class-api Perhaps it's the `module:: email.parser` directive at the top? A similar problem is in email.mime.rst; all the documented classes are exposed at the top of the email package (i.e. should be email.MIMEBase, not email.mime.MIMEBase) ---------- assignee: georg.brandl components: Documentation messages: 75554 nosy: gagenellina, georg.brandl severity: normal status: open title: functions in email package listed under wrong module versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 6 11:39:40 2008 From: report at bugs.python.org (Berend-Jan Wever) Date: Thu, 06 Nov 2008 10:39:40 +0000 Subject: [New-bugs-announce] [issue4269] Spaces not showing correctly in "split()" documentation on http://www.python.org/doc/2.5.2/lib/string-methods.html In-Reply-To: <1225967980.7.0.461107867511.issue4269@psf.upfronthosting.co.za> Message-ID: <1225967980.7.0.461107867511.issue4269@psf.upfronthosting.co.za> New submission from Berend-Jan Wever : Part of the text of the online documentation for the string.split() method: If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends. Then, words are separated by arbitrary length strings of whitespace characters. Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string or a string consisting of just whitespace returns an empty list. As you may have noticed, there should be multiple spaces in ("'1 2 3'.split()". If you look at the HTML source you will see that they are there. However, because browsers rendering HTML by default replace multiple space with a single space, they are not visible in the documentation. This should be addressed by either using

around the text to preserve formatting or by replacing all instances of multiple spaces with instances of " ". I suspect this problem may be elsewhere in the documentation as well. ---------- assignee: georg.brandl components: Documentation messages: 75558 nosy: SkyLined, georg.brandl severity: normal status: open title: Spaces not showing correctly in "split()" documentation on http://www.python.org/doc/2.5.2/lib/string-methods.html type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 6 18:30:44 2008 From: report at bugs.python.org (Mikhail Terekhov) Date: Thu, 06 Nov 2008 17:30:44 +0000 Subject: [New-bugs-announce] [issue4270] struct module: pack/unpack and byte order on x86_64 In-Reply-To: <1225992644.3.0.448967011031.issue4270@psf.upfronthosting.co.za> Message-ID: <1225992644.3.0.448967011031.issue4270@psf.upfronthosting.co.za> New submission from Mikhail Terekhov : pack/unpack behavior changes unexpectedly depending on the byte order: l:/tmp >uname -pmiovs Linux #1 SMP 2008-10-14 22:17:43 +0200 x86_64 x86_64 x86_64 GNU/Linux l:/tmp >python python Python 2.5.1 (r251:54863, Aug 1 2008, 00:35:20) [GCC 4.2.1 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import struct import struct >>> struct.pack(">L",0xdeadbeef) struct.pack(">L",0xdeadbeef) '\xde\xad\xbe\xef' >>> struct.pack("L",0xdeadbeef) struct.pack("L",0xdeadbeef) '\xef\xbe\xad\xde\x00\x00\x00\x00' >>> struct.pack(">> The length of the result above is 8 when no byte order is specified and 4 when it is. Another example: >>> struct.pack("L",0xdeadbeef00000000) '\x00\x00\x00\x00\xef\xbe\xad\xde' >>> struct.pack(">> struct.pack("!L",0xdeadbeef00000000) '\x00\x00\x00\x00' >>> struct.pack("!L",0x12345678deadbeef) '\xde\xad\xbe\xef' >>> struct.pack("L",0x12345678deadbeef) '\xef\xbe\xad\xdexV4\x12' >>> Last results look strange. ---------- components: Library (Lib) messages: 75569 nosy: mmm77 severity: normal status: open title: struct module: pack/unpack and byte order on x86_64 type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 6 18:31:52 2008 From: report at bugs.python.org (Winfried Plappert) Date: Thu, 06 Nov 2008 17:31:52 +0000 Subject: [New-bugs-announce] [issue4271] conversion tool does not fix "from Tkinter import N, E" In-Reply-To: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za> Message-ID: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za> New submission from Winfried Plappert : I tried to check the tracker for an existing issue with the conversion tool, but I could not find one. I am using the "python2.6 Python2.6/Tools/scripts/2to3 -w -v ." command to convert existing Python scripts to Python3.0. I made two observations: 1. Tkinter from Tkinter import (N, E, ...) does NOT get translated to from tkinter import (N, E, ...) 2. 2to3 produces relative imports for stuff which lives in the same directory, but trying to compile the stuff, I get the error: org: from global_stuff import * 2t3: from .global_stuff import * ValueError: Attempted relative import in non-package ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 75571 nosy: wplappert severity: normal status: open title: conversion tool does not fix "from Tkinter import N,E" type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 6 21:47:10 2008 From: report at bugs.python.org (Jacques Frechet) Date: Thu, 06 Nov 2008 20:47:10 +0000 Subject: [New-bugs-announce] [issue4272] set timestamp in gzip stream In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za> Message-ID: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za> New submission from Jacques Frechet : The gzip header defined in RFC 1952 includes a mandatory "MTIME" field, originally intended to contain the modification time of the original uncompressed file. It is often ignored when decompressing, though gunzip (for example) uses it to set the modification time of the output file if applicable. The Python gzip module always sets the MTIME field to the current time, and always discards MTIME when decompressing. As a result, compressing the same string using gzip produces different output every time. For certain applications, especially those involving comparisons or cryprographic signing of binary files, these spurious changes can be quite inconvenient. Aside from the MTIME field, the gzip module already produces entirely deterministic output. I'm attaching a patch which adds an optional "mtime" argument to the GzipFile class, giving the caller the option of providing a timestamp when compressing. Default behavior is unchanged. I've included updated documentation and three new test cases in the patch. In order to facilitate testing, the patch also includes code to set the "mtime" member of the GzipFile instance when decompressing. The first test case uses the new member to ensure that the timestamp given to the GzipFile constructor is preserved correctly. The second test checks for specific values in the entire gzip header (not just the MTIME field) by reading the compressed file directly, examining individual fields in a (relatively) flexible way. The third compares the entire compressed stream against a predetermined sequence of bytes in a relatively inflexible way. All tests pass on my AMD64 box, and I expect them all to pass on all supported platforms without any problems. However, If anybody is concerned that any of the tests sound like they might be too brittle, I'm certainly not overly attached to them. If anyone has any further suggestions, I'd be delighted to submit a new patch. Thanks! Jacques ---------- components: Library (Lib) files: gzip-mtime-py3k.patch keywords: patch messages: 75580 nosy: jfrechet severity: normal status: open title: set timestamp in gzip stream type: feature request Added file: http://bugs.python.org/file11954/gzip-mtime-py3k.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 6 23:00:03 2008 From: report at bugs.python.org (darrenr) Date: Thu, 06 Nov 2008 22:00:03 +0000 Subject: [New-bugs-announce] [issue4273] cycle created by profile.run In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za> Message-ID: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za> New submission from darrenr : The profile module creates a reference cycle. See attached session. ---------- components: Library (Lib) files: profile_cycle.txt messages: 75582 nosy: darrenr severity: normal status: open title: cycle created by profile.run type: resource usage versions: Python 2.4 Added file: http://bugs.python.org/file11956/profile_cycle.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 7 04:13:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 07 Nov 2008 03:13:52 +0000 Subject: [New-bugs-announce] [issue4274] Finish what's new in 3.0 In-Reply-To: <1226027632.26.0.922705313094.issue4274@psf.upfronthosting.co.za> Message-ID: <1226027632.26.0.922705313094.issue4274@psf.upfronthosting.co.za> New submission from Christian Heimes : The what's new section of the 3.0 docs need lots of extra care. It's short and it doesn't list all PEPs and important changes. Since lot's of people are coming from 2.5 it may also be a wise idea to list relevant 2.5->2.6 changes. ---------- assignee: akuchling components: Documentation messages: 75592 nosy: akuchling, barry, christian.heimes, georg.brandl, gvanrossum priority: deferred blocker severity: normal stage: needs patch status: open title: Finish what's new in 3.0 type: feature request versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 7 04:29:48 2008 From: report at bugs.python.org (Don MacMillen) Date: Fri, 07 Nov 2008 03:29:48 +0000 Subject: [New-bugs-announce] [issue4275] socketserver example code not correctly ported to py3k In-Reply-To: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za> Message-ID: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za> New submission from Don MacMillen : code examples in socketserver do not run in py3k Obvious errors with print stmt (not function call) Less obvious errors with socket.send that does not accept str type (bytearray works fine). Client example below shows problems. import socket import sys HOST, PORT = "localhost", 9999 data = " ".join(sys.argv[1:]) # Create a socket (SOCK_STREAM means a TCP socket) sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # Connect to server and send data sock.connect((HOST, PORT)) sock.send(data + "\n") # Receive data from the server and shut down received = sock.recv(1024) sock.close() print "Sent: %s" % data print "Received: %s" % received ---------- messages: 75595 nosy: macd severity: normal status: open title: socketserver example code not correctly ported to py3k versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 7 04:51:42 2008 From: report at bugs.python.org (Jan Schreuder) Date: Fri, 07 Nov 2008 03:51:42 +0000 Subject: [New-bugs-announce] [issue4276] IDLE in 2.6 fails to launch In-Reply-To: <1226029902.06.0.437223717006.issue4276@psf.upfronthosting.co.za> Message-ID: <1226029902.06.0.437223717006.issue4276@psf.upfronthosting.co.za> New submission from Jan Schreuder : I downloaded and installed Python 2.6 for Mac OSX 10.4. It installed Build Applet, Extras, IDLE and Python Launcher in a Python 2.6 folder in the Applications folder. However, IDLE will not launch. I have Python 2.5 installed. That IDLE version works. ---------- components: IDLE messages: 75596 nosy: JanKarel severity: normal status: open title: IDLE in 2.6 fails to launch versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 7 13:15:53 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 07 Nov 2008 12:15:53 +0000 Subject: [New-bugs-announce] [issue4277] asynchat's handle_error inconsistency In-Reply-To: <1226060153.34.0.769481825348.issue4277@psf.upfronthosting.co.za> Message-ID: <1226060153.34.0.769481825348.issue4277@psf.upfronthosting.co.za> New submission from Giampaolo Rodola' : Suppose you have tow sockets handled by two asynchat.async_chat class instances and from class1 you want to send some data through class2: class1(asynchat.async_chat): ... def mymethod(self): class2_instance.push_with_producer(producer) Since push_with_producer automatically calls initiate_send() if an error occurs while class2 reads the first chunk of data from the producer, class1's handle_error gets called. If the error occurs when reading the next chunks of data class2's handle_error will be called instead. This is an inconsistency that should be fixed so that always class2's handle_error gets called. The patch in attachment does that. ---------- components: Library (Lib) files: asynchat.patch keywords: patch messages: 75601 nosy: giampaolo.rodola, josiah.carlson, josiahcarlson severity: normal status: open title: asynchat's handle_error inconsistency type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file11959/asynchat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 7 14:13:55 2008 From: report at bugs.python.org (Keith Briggs) Date: Fri, 07 Nov 2008 13:13:55 +0000 Subject: [New-bugs-announce] [issue4278] optparse quirks In-Reply-To: <1226063635.77.0.234802837689.issue4278@psf.upfronthosting.co.za> Message-ID: <1226063635.77.0.234802837689.issue4278@psf.upfronthosting.co.za> New submission from Keith Briggs : I got the message: optparse.OptionError: invalid long option string '-T0': must start with --, followed by non-dash This is bad - the real error was that I gave a short option which did not have a single letter. Also, it seems that add_option('--height-of-plot','-h') is not allowed, because -h can only go with --help. How do I override this? Keith ---------- components: Extension Modules messages: 75602 nosy: kbriggs severity: normal status: open title: optparse quirks type: behavior versions: Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 7 14:58:20 2008 From: report at bugs.python.org (Andy) Date: Fri, 07 Nov 2008 13:58:20 +0000 Subject: [New-bugs-announce] [issue4279] Module 'parser' fails to build In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za> Message-ID: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za> New submission from Andy : With a clean checkout of the py3k source it fails to build the Parser exension module (based on Modules/parsermodule.c) when building against a cygwin target. This appears to be related to the movement of the symbol _PyParser_Grammar from graminit.c to Parser\metagrammar.c. (At least this is where it was going by the code comments) Because of this the module now requires Parser\metagrammar.c to get this information via Py_meta_grammar. The patch modifies setup.py to add the required file and modifies parsermodule.c to use the accessor function. (This fails on a clean trunk build in the same way as well - which makes me very suspicious that this is not a "real" issue as the buildbots seem to be green.) My gut feeling is that my modification to setup.py for the module is incorrect - it just looks messy. So I await the inevitable: "That's not how to fix it...." :-) ---------- components: Extension Modules files: parsermodule_fix.diff keywords: patch messages: 75603 nosy: kirkshorts severity: normal status: open title: Module 'parser' fails to build type: compile error versions: Python 3.0 Added file: http://bugs.python.org/file11960/parsermodule_fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 7 20:55:02 2008 From: report at bugs.python.org (Colin J. Williams) Date: Fri, 07 Nov 2008 19:55:02 +0000 Subject: [New-bugs-announce] [issue4280] Version Checker In-Reply-To: <1226087702.6.0.0754542760086.issue4280@psf.upfronthosting.co.za> Message-ID: <1226087702.6.0.0754542760086.issue4280@psf.upfronthosting.co.za> New submission from Colin J. Williams : Versions 2.5, 2.6 and 3.0 contain a Version Checker in the Tools directory. This appears to no longer serve a useful purpose. Perhaps it can be dropped from the distribution. Colin W ---------- components: Tests files: pyversioncheck.py messages: 75611 nosy: cjw severity: normal status: open title: Version Checker type: feature request versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11962/pyversioncheck.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 7 21:32:00 2008 From: report at bugs.python.org (Vlastimil Brom) Date: Fri, 07 Nov 2008 20:32:00 +0000 Subject: [New-bugs-announce] [issue4281] Idle - incorrectly displaying a character (Latin capital letter sharp s) In-Reply-To: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za> Message-ID: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za> New submission from Vlastimil Brom : While experimenting with the new unicodedata for version 5.1 (many thanks for it!) I discovered some strange behaviour of Idle with regard to a character not available in any font on my system, namely Latin capital letter sharp s - U+1E9E. Cf. the following sessions: Python 3.0rc2 (r30rc2:67141, Nov 7 2008, 11:43:46) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ... IDLE 3.0rc2 >>> print("\N{LATIN CAPITAL LETTER SHARP S}") ? >>> print("\N{LATIN CAPITAL LETTER S WITH CEDILLA}") ? >>> print("\N{PHAGS-PA LETTER KA}") ? >>> print("\ufff0") ? >>> hex(ord("?")) '0x1e9e' >>> hex(ord("?")) '0x15e' >>> Of course, the exact view cannot be copied, but basically I see very similar glyphs for the first two characters, while I had expected a "square"-sign or something for the first one; this is what I get with other surely unavailable glyph as well as a non existent character. See the attached screenshot. However, the characters remain clearly distinguished, as can be seen e.g. after copying them as a parameter of ord(...). Python 2.6 behaves the same way: ======================= Python 2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ... IDLE 2.6 >>> print u"\N{LATIN CAPITAL LETTER SHARP S}" ? >>> ... ============================================== Not that it is much important, but I found it a bit surprising. I'm using WinXPh SP3 Czech. ---------- components: IDLE, Tkinter, Unicode files: idle-capital-sharp-s.jpg messages: 75613 nosy: vbr severity: normal status: open title: Idle - incorrectly displaying a character (Latin capital letter sharp s) versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11963/idle-capital-sharp-s.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 8 03:49:32 2008 From: report at bugs.python.org (Takafumi SHIDO) Date: Sat, 08 Nov 2008 02:49:32 +0000 Subject: [New-bugs-announce] [issue4282] (Python3) The profile module deesn't understand the character set definition In-Reply-To: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za> Message-ID: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za> New submission from Takafumi SHIDO : The profile module of Python3 deesn't understand the character set of the script. When a profile is executed (like $python -m profile -o prof.dat foo.py) on a code (say foo.py) which defines its character set in the second line (like #coding:utf-8), the profile crashes with an error message like: "SyntaxError: unknown encoding: utf-8" ---------- messages: 75627 nosy: shidot severity: normal status: open title: (Python3) The profile module deesn't understand the character set definition type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 8 13:56:30 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Sat, 08 Nov 2008 12:56:30 +0000 Subject: [New-bugs-announce] [issue4283] "python3.0 setup.py install --user" raises AttributeError In-Reply-To: <1226148990.03.0.577410643236.issue4283@psf.upfronthosting.co.za> Message-ID: <1226148990.03.0.577410643236.issue4283@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : A simple left-over "dict.iteritems". Patch is attached. ---------- components: Distutils files: distutils.patch keywords: patch messages: 75634 nosy: hagen severity: normal status: open title: "python3.0 setup.py install --user" raises AttributeError type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file11965/distutils.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 8 20:09:50 2008 From: report at bugs.python.org (Anthony Awtrey) Date: Sat, 08 Nov 2008 19:09:50 +0000 Subject: [New-bugs-announce] [issue4284] Python 2.6 64-bit + Vista 64 = Bad MSVCRT In-Reply-To: <1226171390.73.0.943676496028.issue4284@psf.upfronthosting.co.za> Message-ID: <1226171390.73.0.943676496028.issue4284@psf.upfronthosting.co.za> New submission from Anthony Awtrey : Here is the reproduction process. Get Windows box running Vista 64-bit. Download the Python 2.6 64-bit version. Write a script that imports escape from saxutils. See this: C:\Python26>python.exe example_xml_script.py > out.xml Traceback (most recent call last): File "example_xml_script.py", line 11, in from xml.sax.saxutils import escape File "C:\Python26\lib\xml\sax\saxutils.py", line 6, in import os, urlparse, urllib, types File "C:\Python26\lib\urllib.py", line 26, in import socket File "C:\Python26\lib\socket.py", line 46, in import _socket ImportError: DLL load failed: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail. EventViewer says: Activation context generation failed for "C:\Python26\DLLs\_socket.pyd". Error in manifest or policy file "C:\Python26DLLs\Microsoft.VC90.CRT.MANIFEST" on line 12. The value "../msvcr90.dll" of attribute "name" in element "urn:schemas-microsoft-com:asm.v1^file" is invalid. Go download the MSVCRT directly and install it: http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en Then the problem goes away. This issue is particular only to the Python 2.6 64-bit version, as the 32-bit version runs just fine. ---------- components: Windows messages: 75643 nosy: DaGoodBoy severity: normal status: open title: Python 2.6 64-bit + Vista 64 = Bad MSVCRT type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 9 01:04:52 2008 From: report at bugs.python.org (Brett Cannon) Date: Sun, 09 Nov 2008 00:04:52 +0000 Subject: [New-bugs-announce] [issue4285] Use a named tuple for sys.version_info In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za> Message-ID: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za> New submission from Brett Cannon : sys.version_info is just asking for a named tuple consisting of major, minor, micro, releaselevel, and serial. This is assuming, of course, that bootstrapping doesn't get in the way. ---------- assignee: brett.cannon components: Extension Modules keywords: easy messages: 75647 nosy: brett.cannon priority: low severity: normal stage: needs patch status: open title: Use a named tuple for sys.version_info type: behavior versions: Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 9 02:28:25 2008 From: report at bugs.python.org (dlfjessup) Date: Sun, 09 Nov 2008 01:28:25 +0000 Subject: [New-bugs-announce] [issue4286] Discrepancy in format string documentation In-Reply-To: <1226194105.16.0.0970163310493.issue4286@psf.upfronthosting.co.za> Message-ID: <1226194105.16.0.0970163310493.issue4286@psf.upfronthosting.co.za> New submission from dlfjessup : In the documentation for Format Strings (http://docs.python.org/dev/3.0/library/string.html#formatstrings), the grammar has the following rule: > conversion ::= "r" | "s" However, the documentation later reads: > Three conversion flags are currently supported: '!s' which calls str() on the value, '!r' which calls repr() and '!a' which calls ascii(). This implies that the correct rule for the grammar is: > conversion ::= "a" | "r" | "s" ---------- assignee: georg.brandl components: Documentation messages: 75648 nosy: dlfjessup, georg.brandl severity: normal status: open title: Discrepancy in format string documentation versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 9 02:33:59 2008 From: report at bugs.python.org (Fernando Correia) Date: Sun, 09 Nov 2008 01:33:59 +0000 Subject: [New-bugs-announce] [issue4287] Broken URL in documentation style guide In-Reply-To: <1226194439.54.0.969230784102.issue4287@psf.upfronthosting.co.za> Message-ID: <1226194439.54.0.969230784102.issue4287@psf.upfronthosting.co.za> New submission from Fernando Correia : The documentation Style Guide [http://docs.python.org/dev/documenting/style.html] has a broken link to http://developer.apple.com/documentation/UserExperience/Conceptual/APStyleGuide/AppleStyleGuide2006.pdf. This link should be updated to: http://developer.apple.com/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2008.pdf ---------- assignee: georg.brandl components: Documentation messages: 75649 nosy: facorreia, georg.brandl severity: normal status: open title: Broken URL in documentation style guide type: feature request versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 9 13:34:30 2008 From: report at bugs.python.org (Roumen Petrov) Date: Sun, 09 Nov 2008 12:34:30 +0000 Subject: [New-bugs-announce] [issue4288] parsermodule and grammar variable In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za> Message-ID: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za> New submission from Roumen Petrov : After synchronization of my mingw32 cross-compilation environment with trunk some of tests fail. The reason is that parsermodule fail to link. Please check build on officially supported platform: MSVC and cygwin. The attached patch (parser-grammar.patch) solve issue in my environment. ---------- components: Build, Tests files: parser-grammar.patch keywords: patch messages: 75652 nosy: rpetrov severity: normal status: open title: parsermodule and grammar variable versions: Python 2.6 Added file: http://bugs.python.org/file11969/parser-grammar.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 9 13:54:33 2008 From: report at bugs.python.org (Fabio Zadrozny) Date: Sun, 09 Nov 2008 12:54:33 +0000 Subject: [New-bugs-announce] [issue4289] Python 2.6 installer crashes when selecting 'advanced' and cancelling it In-Reply-To: <1226235273.93.0.0512251767655.issue4289@psf.upfronthosting.co.za> Message-ID: <1226235273.93.0.0512251767655.issue4289@psf.upfronthosting.co.za> New submission from Fabio Zadrozny : When installing python-2.6.msi it crashes when doing the following steps on a windows XP (32 bit). I'm not sure if all those steps are needed, but that's how it crashed here: - start python-2.6.msi - check 'install just for me' - change the destination directory (d:\bin\Python26) - click on 'advanced' - click on cancel - confirm cancel At this point windows presents a message: to help protect your computer, Windows has closed this program. ---------- components: Installation messages: 75653 nosy: fabioz severity: normal status: open title: Python 2.6 installer crashes when selecting 'advanced' and cancelling it type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 10 00:04:13 2008 From: report at bugs.python.org (Ondrej Certik) Date: Sun, 09 Nov 2008 23:04:13 +0000 Subject: [New-bugs-announce] [issue4290] 2to3 fails with sympy In-Reply-To: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za> Message-ID: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za> New submission from Ondrej Certik : Download my branch of sympy from here: http://github.com/certik/sympy/tree/division3 and run the 2to3 tool with python2.5: $ python2.5 ../2to3/2to3 sympy/ [...] Traceback (most recent call last): File "../2to3/2to3", line 6, in sys.exit(main("lib2to3.fixes")) File "/home/ondra/repos/2to3/lib2to3/main.py", line 126, in main rt.refactor(args, options.write, options.doctests_only) File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 194, in refactor self.refactor_dir(dir_or_file, write, doctests_only) File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 212, in refactor_dir self.refactor_file(fullname, write, doctests_only) File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 235, in refactor_file tree = self.refactor_string(input, filename) File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 260, in refactor_string self.refactor_tree(tree, name) File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 299, in refactor_tree self.traverse_by(self.post_order, tree.post_order()) File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 323, in traverse_by new = fixer.transform(node, results) File "/home/ondra/repos/2to3/lib2to3/fixes/fix_metaclass.py", line 148, in transform if not has_metaclass(node): File "/home/ondra/repos/2to3/lib2to3/fixes/fix_metaclass.py", line 34, in has_metaclass return has_metaclass(node) File "/home/ondra/repos/2to3/lib2to3/fixes/fix_metaclass.py", line 39, in has_metaclass if leaf_node.value == '__metaclass__': AttributeError: 'Node' object has no attribute 'value' ---------- messages: 75669 nosy: certik severity: normal status: open title: 2to3 fails with sympy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 10 00:57:55 2008 From: report at bugs.python.org (Jeremy Banks) Date: Sun, 09 Nov 2008 23:57:55 +0000 Subject: [New-bugs-announce] [issue4291] Allow Division of datetime.timedelta Objects In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za> Message-ID: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za> New submission from Jeremy Banks : It would be convenient if it were possible to divide one datetime.timedelta object by another to determine their relative durations. Were the datetime module pure Python a crude solution would just be to add two methods like this: def toMicroseconds(self): return ((self.days * 24 * 60) + self.seconds * 1000000) + self.microseconds def __truediv__(self, other): return self.toMicroseconds() / other.toMicroseconds() However, I don't understand know the Python C API well enough to know how to patch the C module. ---------- components: Library (Lib) messages: 75670 nosy: Jeremy Banks severity: normal status: open title: Allow Division of datetime.timedelta Objects type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 10 08:03:55 2008 From: report at bugs.python.org (Ondrej Certik) Date: Mon, 10 Nov 2008 07:03:55 +0000 Subject: [New-bugs-announce] [issue4292] 2to3 fails to convert "from something import (a, b, c)" In-Reply-To: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za> Message-ID: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za> New submission from Ondrej Certik : While converting the SymPy repo: the 2to3 failed to convert stuff like: from something import (a, b, c, ) Attached find the patch that I had to do by hand -- I think 2to3 should be able to fix this as well. ---------- files: import.patch keywords: patch messages: 75683 nosy: certik severity: normal status: open title: 2to3 fails to convert "from something import (a, b, c)" Added file: http://bugs.python.org/file11972/import.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 10 12:36:35 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 10 Nov 2008 11:36:35 +0000 Subject: [New-bugs-announce] [issue4293] Thread Safe Py_AddPendingCall In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za> Message-ID: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : At CCP We have started using the Py_AddPendingCall() mechanism to signal python about a completed IO operation. However, we noticed that the existing mechanism was hoplelessly un- thread safe. This is bad, since on Windows at least, it is very convenient to have such callbacks happen on an arbitrary thread from the system's thread pool. I submit a thread-safe implementation instead to be used if WITH_THREAD is defined. This allows Py_AddPendingCall() to be called from any thread, from any context, even from a PendingCall callback itself. ---------- components: Interpreter Core files: pendingalls.patch keywords: needs review, patch, patch messages: 75691 nosy: krisvale priority: normal severity: normal status: open title: Thread Safe Py_AddPendingCall type: crash versions: Python 2.7 Added file: http://bugs.python.org/file11974/pendingalls.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 10 14:12:32 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 10 Nov 2008 13:12:32 +0000 Subject: [New-bugs-announce] [issue4294] Macros for PyLong: sign, number of digits, fits in an int In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za> Message-ID: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za> New submission from STINNER Victor : It's hard to read Objects/longobject.c because the code depends to much on the implementation. I wrote macros to simplify the code: - PyLong_SIGN(x) - PyLong_EQUALS_ZERO(x) - PyLong_FITS_INT(x) - PyLong_GET_INT(x) - PyLong_NDIGITS(x) Macros are declared in Include/longintrepr.h to be able to use them outside longobject.c. Eg. I used it in Modules/mathmodule.c. The patch also contains extra changes: - create sdigit type (used by PyLong_GET_INT(x)) - use memcpy() in _PyLong_Copy() - use stwodigits in long_mul() - replace many Py_SIZE() hacks by my macros (eg. see long_hash) Using my patch, it will be easier to change long integer implementation, like: - Use 30-bit digits instead of 15-bit digits (issue #4258) - Use GMP for PyLong (issue #1814) Example of changes: i = Py_SIZE(v); x = 0; if (i < 0) { PyErr_SetString(PyExc_OverflowError, "can't convert negative value to unsigned int"); return (unsigned long) -1; } switch (i) { case 0: return 0; case 1: return v->ob_digit[0]; } while (--i >= 0) { ... is replaced by: if (PyLong_SIGN(v) < 0) { PyErr_SetString(PyExc_OverflowError, "can't convert negative value to unsigned int"); return (unsigned long) -1; } if (PyLong_FITS_INT(v)) return (unsigned long) PyLong_GET_INT(v); x = 0; i = PyLong_NDIGITS(v); while (--i >= 0) { ... ---------- files: pylong_macros.patch keywords: patch messages: 75694 nosy: haypo severity: normal status: open title: Macros for PyLong: sign, number of digits, fits in an int versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11975/pylong_macros.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 10 23:57:12 2008 From: report at bugs.python.org (Zooko O'Whielacronx) Date: Mon, 10 Nov 2008 22:57:12 +0000 Subject: [New-bugs-announce] [issue4295] closing stdout in a child process on cygwin means that process doesn't receive bytes from stdin anymore. I think. In-Reply-To: <1226357832.32.0.219991496484.issue4295@psf.upfronthosting.co.za> Message-ID: <1226357832.32.0.219991496484.issue4295@psf.upfronthosting.co.za> New submission from Zooko O'Whielacronx : When someone runs "bin/trial --reactor=select twisted.internet.test.test_process.ProcessTestsBuilder_PollReactor.test_ childConnectionLost" on cygwin, using the cygwin version of Python, either manually (which I've done on two cygwin installations), or from the twisted buildbot -- http://buildbot.twistedmatrix.com/builders/cygwin-py2.5-select -- then once the child process closes its fd #2, it subsequently receives no further bytes from its fd #1, even though the parent process has written some bytes to that pipe. I can reproduce this by running the Twisted unit tests, like this: step 1: get twisted: svn co svn://svn.twistedmatrix.com/svn/Twisted/trunk twisted step 2: cd into the top-level directory, and run trial: cd twisted && python ./bin/trial --reactor=select twisted.internet.test.test_process.ProcessTestsBuilder_PollReactor.test_ childConnectionLost On other platforms that cygwin (see the Twisted buildbot -- http://buildbot.twistedmatrix.com/supported?branch=trunk -- then this test exits quickly with success. On cygwin, using cygwin python.exe, this test instead enter an infinite loop as the child waits to receive further bytes on its stdin, and the parent waits for the child to respond to those bytes. (This doesn't happen on cygwin with the standard Win32 build of python.exe, of course, anymore than it happens on a Windows system without cygwin installed when using that executable.) I've opened a ticket about this on the twisted issue tracker as well: http://twistedmatrix.com/trac/ticket/3529 # closing stdout in a child process on cygwin means that process doesn't receive bytes from stdin anymore. I think. ---------- components: Interpreter Core messages: 75711 nosy: zooko severity: normal status: open title: closing stdout in a child process on cygwin means that process doesn't receive bytes from stdin anymore. I think. type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 11 02:44:42 2008 From: report at bugs.python.org (Michael B Curtis) Date: Tue, 11 Nov 2008 01:44:42 +0000 Subject: [New-bugs-announce] [issue4296] Python assumes identity implies equivalence; contradicts NaN In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za> Message-ID: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za> New submission from Michael B Curtis : Found in Python 2.4; not sure what other versions may be affected. I noticed a contradiction with regards to equivalence when experimenting with NaN, which has the special property that it "is" itself, but it doesn't "==" itself: >>> a = float('nan') >>> a is a True >>> a == a False >>> b = [float('nan')] >>> b is b True >>> b == b True I am not at all familiar with Python internals, but the issue appears to be in PyObject_RichCompareBool of python/trunk/Objects/object.c This method "Guarantees that identity implies equality". However, this doesn't "Gaurantee" this fact, but instead "Assumes" it, because it is not something that is always True. NaN is identical to itself, but not equivalent to itself. At a minimum, the contradiction introduced by this assumption should be documented. However, it may be possible to do better, by fixing it. The assumption appears to be made that identity should imply equivalence, for the common case. Would it therefore be possible to, instead of having objects such as lists perform this optimization and make this assumption, instead have the base object types implement this assumption. That is, for regular objects, when we evaluate equivalence, we return True if the objects are identical. Then, the optimization can be removed from objects such as list, so that when they check the equivalence of each object, the optimization is performed there. NaN can then override the default behavior, so that it always returns False in equivalence comparisons. ---------- components: Interpreter Core messages: 75716 nosy: mikecurtis severity: normal status: open title: Python assumes identity implies equivalence; contradicts NaN type: behavior versions: Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 11 15:22:59 2008 From: report at bugs.python.org (Daniel Watkins) Date: Tue, 11 Nov 2008 14:22:59 +0000 Subject: [New-bugs-announce] [issue4297] Add error_log attribute to optparse.OptionParser In-Reply-To: <1226413379.99.0.188665223227.issue4297@psf.upfronthosting.co.za> Message-ID: <1226413379.99.0.188665223227.issue4297@psf.upfronthosting.co.za> New submission from Daniel Watkins : I've recently had to subclass optparse.OptionParser, and copy-paste the exit method, just to change where errors were printed to (I needed stdout rather than stderr). I've also had a request from a client to log errors with command-line parsing to a file, rather than to stdout. So, this patch adds an error_log parameter to OptionParser.__init__ which is used instead of stderr internally (and, of course, defaults to stderr). ---------- components: Library (Lib) files: optparse-error_log.patch keywords: patch messages: 75741 nosy: odd_bloke severity: normal status: open title: Add error_log attribute to optparse.OptionParser type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file11985/optparse-error_log.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 11 16:07:51 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Tue, 11 Nov 2008 15:07:51 +0000 Subject: [New-bugs-announce] [issue4298] pickle segfault or MemoryError on invalid input In-Reply-To: <1226416071.17.0.696466187419.issue4298@psf.upfronthosting.co.za> Message-ID: <1226416071.17.0.696466187419.issue4298@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : On a 64-bit build pickle.loads segfaults on the following bytes. (Same for pickle.load on a corresponding file.) On a 32-bit build there is only a MemoryError. Python 3.0rc2 (r30rc2:67114, Nov 10 2008, 12:09:54) [GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> pickle.loads(bytes([0x58, 0, 0, 0, 0x54])) Segmentation fault ---------- components: Library (Lib) messages: 75743 nosy: hagen severity: normal status: open title: pickle segfault or MemoryError on invalid input type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 11 16:19:57 2008 From: report at bugs.python.org (Gary VanHorn) Date: Tue, 11 Nov 2008 15:19:57 +0000 Subject: [New-bugs-announce] [issue4299] 3.0rc2.msi Install Fails (Error Code 2755) In-Reply-To: <1226416797.61.0.972163132872.issue4299@psf.upfronthosting.co.za> Message-ID: <1226416797.61.0.972163132872.issue4299@psf.upfronthosting.co.za> New submission from Gary VanHorn : Where can an error code resource be found? ---------- components: Installation messages: 75744 nosy: sharksuit severity: normal status: open title: 3.0rc2.msi Install Fails (Error Code 2755) versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 11 20:04:02 2008 From: report at bugs.python.org (Brian D'Urso) Date: Tue, 11 Nov 2008 19:04:02 +0000 Subject: [New-bugs-announce] [issue4300] error in multiprocessing logging docs In-Reply-To: <1226430242.52.0.860879245755.issue4300@psf.upfronthosting.co.za> Message-ID: <1226430242.52.0.860879245755.issue4300@psf.upfronthosting.co.za> New submission from Brian D'Urso : the 2.6 docs for the multiprocessing module have a minor error in the logging example which causes it to fail: the documentation says to get the logger with 'multiprocessing.get_logger()' which works but the example uses 'multiprocessing.getLogger()' which uses the logging package method name and is not valid. The full example in the docs is: >>> import multiprocessing, logging >>> logger = multiprocessing.getLogger() >>> logger.setLevel(logging.INFO) >>> logger.warning('doomed') [WARNING/MainProcess] doomed >>> m = multiprocessing.Manager() [INFO/SyncManager-1] child process calling self.run() [INFO/SyncManager-1] manager bound to '\\\\.\\pipe\\pyc-2776-0-lj0tfa' >>> del m [INFO/MainProcess] sending shutdown message to manager [INFO/SyncManager-1] manager exiting with exitcode 0 ---------- assignee: georg.brandl components: Documentation messages: 75755 nosy: dursobr, georg.brandl severity: normal status: open title: error in multiprocessing logging docs versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 11 20:50:54 2008 From: report at bugs.python.org (Brian D'Urso) Date: Tue, 11 Nov 2008 19:50:54 +0000 Subject: [New-bugs-announce] [issue4301] incorrect and inconsistent logging in multiprocessing In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za> Message-ID: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za> New submission from Brian D'Urso : logging in multiprocessing seems to give inconsistent results on Linux and XP, but neither appears to match the documentation: According to the docs, when first created "the logger has level logging.NOTSET and has a handler which sends output to sys.stderr using format '[%(levelname)s/%(processName)s] %(message)s'" The example in the docs also does not work, but the full problem is more clearly illustrated with the following: This should print a message from the main process and the subprocess: import multiprocessing, logging def f(): logger = multiprocessing.get_logger() logger.info('info from subprocess') if __name__ == '__main__': logger = multiprocessing.get_logger() logger.setLevel(logging.INFO) logger.info('info from main process') p = multiprocessing.Process(target=f) p.start() p.join() but, on Windows (XP) and Linux (ScientificLinux 5.2, python 2.6 compiled from src) it outputs only: No handlers could be found for logger "multiprocessing" We can 'fix' this by specifying a handler, as in: import multiprocessing, logging def f(): logger = multiprocessing.get_logger() logger.info('info from subprocess') if __name__ == '__main__': logger = multiprocessing.get_logger() logger.setLevel(logging.INFO) handler = logging.StreamHandler() handler.setLevel(logging.INFO) formatter = logging.Formatter('[%(levelname)s/%(processName)s] %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) logger.info('info from main process') p = multiprocessing.Process(target=f) p.start() p.join() Then on Linux I get: [INFO/MainProcess] info from main process [INFO/Process-1] child process calling self.run() [INFO/Process-1] info from subprocess [INFO/Process-1] process shutting down [INFO/Process-1] process exiting with exitcode 0 [INFO/MainProcess] process shutting down which looks better, but on Windows I get: [INFO/MainProcess] info from main process No handlers could be found for logger "multiprocessing" [INFO/MainProcess] process shutting down So, the logger is still not setup correctly in the subprocess on Windows. We can again try to 'fix' this to: import multiprocessing, logging def f(): logger = multiprocessing.get_logger() handler = logging.StreamHandler() handler.setLevel(logging.INFO) formatter = logging.Formatter('[%(levelname)s/%(processName)s] %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) logger.info('info from subprocess') if __name__ == '__main__': logger = multiprocessing.get_logger() logger.setLevel(logging.INFO) handler = logging.StreamHandler() handler.setLevel(logging.INFO) formatter = logging.Formatter('[%(levelname)s/%(processName)s] %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) logger.info('info from main process') p = multiprocessing.Process(target=f) p.start() p.join() Now, on Linux I get: [INFO/MainProcess] info from main process [INFO/Process-1] child process calling self.run() [INFO/Process-1] info from subprocess [INFO/Process-1] info from subprocess [INFO/Process-1] process shutting down [INFO/Process-1] process shutting down [INFO/Process-1] process exiting with exitcode 0 [INFO/Process-1] process exiting with exitcode 0 [INFO/MainProcess] process shutting down i.e. double output from the subprocess! On Windows, I finally get: [INFO/MainProcess] info from main process No handlers could be found for logger "multiprocessing" [INFO/Process-1] info from subprocess [INFO/Process-1] process shutting down [INFO/Process-1] process exiting with exitcode 0 [INFO/MainProcess] process shutting down which is almost OK, but the logger is getting set up too late to pick up the subprocess self.run It seems like the logger is not being setup correctly by multiprocessing.get_logger() and the behavior is different in a subprocess on Windows vs Linux. ---------- components: Library (Lib) messages: 75757 nosy: dursobr severity: normal status: open title: incorrect and inconsistent logging in multiprocessing type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 12 09:17:20 2008 From: report at bugs.python.org (Piers Lauder) Date: Wed, 12 Nov 2008 08:17:20 +0000 Subject: [New-bugs-announce] [issue4302] smtplib.py initialisation defect In-Reply-To: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za> Message-ID: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za> New submission from Piers Lauder : smtplib does not initialise the valriable 'sock' in the case where 'host' is NULL on instantiation of smtplib.SMTP. Eg: % python Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import smtplib >>> client=smtplib.SMTP('') >>> client.sendmail('from at home', 'to at home', 'test') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/smtplib.py", line 676, in sendmail if not (200 <= self.ehlo()[0] <= 299): File "/usr/lib/python2.5/smtplib.py", line 397, in ehlo self.putcmd("ehlo", name or self.local_hostname) File "/usr/lib/python2.5/smtplib.py", line 333, in putcmd self.send(str) File "/usr/lib/python2.5/smtplib.py", line 318, in send if self.sock: AttributeError: SMTP instance has no attribute 'sock' >>> The fix is to add "self.sock = None" in __init__ if host is not set, and then the behaviour is much more helpful: % python Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import smtplib >>> client=smtplib.SMTP('') >>> client.sendmail('from at home', 'to at home', 'test') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/smtplib.py", line 678, in sendmail if not (200 <= self.ehlo()[0] <= 299): File "/usr/lib/python2.5/smtplib.py", line 399, in ehlo self.putcmd("ehlo", name or self.local_hostname) File "/usr/lib/python2.5/smtplib.py", line 335, in putcmd self.send(str) File "/usr/lib/python2.5/smtplib.py", line 327, in send raise SMTPServerDisconnected('please run connect() first') smtplib.SMTPServerDisconnected: please run connect() first >>> ---------- components: Library (Lib) files: smtplib-diff-c messages: 75777 nosy: piers severity: normal status: open title: smtplib.py initialisation defect type: behavior versions: Python 2.5.3 Added file: http://bugs.python.org/file11991/smtplib-diff-c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 12 10:00:54 2008 From: report at bugs.python.org (Matthias Klose) Date: Wed, 12 Nov 2008 09:00:54 +0000 Subject: [New-bugs-announce] [issue4303] [2.5 regression] ctypes fails to build on arm-linux-gnu In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za> Message-ID: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za> New submission from Matthias Klose : ctypes fails to build on arm-linux-gnu, see http://python.org/dev/buildbot/2.5/ARM Linux 2.5/builds/3/step-compile/0 gcc -pthread -fPIC -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I. -I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/./Include -Ibuild/temp.linux-armv5tel-2.5/libffi/include -Ibuild/temp.linux-armv5tel-2.5/libffi -I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Include -I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build -c /home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c -o build/temp.linux-armv5tel-2.5/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.o In file included from /home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c:127: /home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/ctypes.h:72: error: expected specifier-qualifier-list before 'ffi_closure' /home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c: In function 'CFuncPtr_new': /home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c:2955: error: 'CThunkObject' has no member named 'pcl' this is a regression compared to 2.5.2. Not seen on 2.6 or 3.0. Please consider a fix before 2.5.3 is released. ---------- messages: 75779 nosy: doko priority: release blocker severity: normal status: open title: [2.5 regression] ctypes fails to build on arm-linux-gnu versions: Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 12 10:34:41 2008 From: report at bugs.python.org (Matthias Klose) Date: Wed, 12 Nov 2008 09:34:41 +0000 Subject: [New-bugs-announce] [issue4304] build mode which fails for build failures in extensions In-Reply-To: <1226482481.6.0.943122034161.issue4304@psf.upfronthosting.co.za> Message-ID: <1226482481.6.0.943122034161.issue4304@psf.upfronthosting.co.za> New submission from Matthias Klose : as seen in issue4303, the buildbots don't complain about build failures in extensions. it would be nice to have a mode, where the build fails when an extension doesn't build, but is expected to build. exceptions to this set of expected builds should be configurable. ---------- components: Build messages: 75780 nosy: doko severity: normal status: open title: build mode which fails for build failures in extensions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 12 11:00:01 2008 From: report at bugs.python.org (Matthias Klose) Date: Wed, 12 Nov 2008 10:00:01 +0000 Subject: [New-bugs-announce] [issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel) In-Reply-To: <1226484001.23.0.749041410677.issue4305@psf.upfronthosting.co.za> Message-ID: <1226484001.23.0.749041410677.issue4305@psf.upfronthosting.co.za> New submission from Matthias Klose : seen on the mipsel buildbot running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers Traceback (most recent call last): File "./setup.py", line 1880, in main() File "./setup.py", line 1875, in main 'Lib/smtpd.py'] File "/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/core.py", line 152, in setup dist.run_commands() File "/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py", line 975, in run_commands self.run_command(cmd) File "/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py", line 995, in run_command cmd_obj.run() File "/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build.py", line 134, in run self.run_command(cmd_name) File "/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py", line 995, in run_command cmd_obj.run() File "/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build_ext.py", line 343, in run self.build_extensions() File "./setup.py", line 201, in build_extensions build_ext.build_extensions(self) File "/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build_ext.py", line 469, in build_extensions self.build_extension(ext) File "./setup.py", line 234, in build_extension if not self.configure_ctypes(ext): File "./setup.py", line 1684, in configure_ctypes execfile(ffi_configfile, globals(), fficonfig) File "build/temp.linux-mips-2.7-pydebug/libffi/fficonfig.py", line 32, in ffi_sources += ffi_platforms['MIPS'] KeyError: 'MIPS' [47349 refs] make: *** [sharedmods] Error 1 ---------- assignee: theller components: ctypes messages: 75781 nosy: doko, theller severity: normal status: open title: ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel) versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 12 14:16:32 2008 From: report at bugs.python.org (STINNER Victor) Date: Wed, 12 Nov 2008 13:16:32 +0000 Subject: [New-bugs-announce] [issue4306] email package with unicode subject/body In-Reply-To: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za> Message-ID: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za> New submission from STINNER Victor : I never used the email package, so my issue is maybe not a bug. I'm trying to send an email with diacritics in the subject and the body. I'm french so it's natural to use characters not in the ASCII range. I wrote this small program: def main(): # coding: utf8 ADDRESS = 'victor.stinner at haypocalc.com' from email.mime.text import MIMEText msg = MIMEText('accent ???', 'plain', 'utf-8') msg['Subject'] = 'sujet ???' msg['From'] = ADDRESS msg['To'] = ADDRESS text = msg.as_string() print("--- FLATTEN ---") print(text) return import smtplib client=smtplib.SMTP('smtp.free.fr') client.sendmail(ADDRESS, ADDRESS, text) client.quit() main() (remove the "return" to really send the email) The problem: (...) File "/home/haypo/prog/py3k/Lib/email/generator.py", line 141, in _write_headers header_name=h, continuation_ws='\t') File "/home/haypo/prog/py3k/Lib/email/header.py", line 189, in __init__ self.append(s, charset, errors) File "/home/haypo/prog/py3k/Lib/email/header.py", line 262, in append input_bytes = s.encode(input_charset, errors) UnicodeEncodeError: 'ascii' codec can't encode characters in position 6-8: ordinal not in range(128) I don't understand why it uses ASCII whereas I specified that I would like to use the UTF-8 charset. My attached patch reused the message charset to encode the headers, but use ASCII if the header can be encoded as ASCII. The patch included an unit test. ---------- components: Library (Lib) files: email_mime_unicode.patch keywords: patch messages: 75784 nosy: haypo severity: normal status: open title: email package with unicode subject/body versions: Python 3.0 Added file: http://bugs.python.org/file11992/email_mime_unicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 12 17:24:37 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Wed, 12 Nov 2008 16:24:37 +0000 Subject: [New-bugs-announce] [issue4307] inspect.FullArgSpec does not match the docs In-Reply-To: <1226507077.43.0.0744196805458.issue4307@psf.upfronthosting.co.za> Message-ID: <1226507077.43.0.0744196805458.issue4307@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : The docs say that inspect.FullArgSpec is a named tuple FullArgSpec(args, varargs, varkw, defaults, kwonlyargs, kwonlydefaults, annotations) However the implementation has "kwdefaults" instead of "kwonlydefaults". The name in the docs seems to make more sense. A patch fixing this is attached. ---------- components: Library (Lib) files: inspect.patch keywords: patch messages: 75788 nosy: hagen severity: normal status: open title: inspect.FullArgSpec does not match the docs type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file11994/inspect.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 12 17:41:21 2008 From: report at bugs.python.org (Chris Withers) Date: Wed, 12 Nov 2008 16:41:21 +0000 Subject: [New-bugs-announce] [issue4308] repr of httplib.IncompleteRead is stupid In-Reply-To: <1226508081.14.0.590007271511.issue4308@psf.upfronthosting.co.za> Message-ID: <1226508081.14.0.590007271511.issue4308@psf.upfronthosting.co.za> New submission from Chris Withers : The repr of httplib.IncompleteRead contains all the data in the read so far. This is stupid. Consider the download of a 100Mb file which fails after 30Mb. You end up with 90Mb of text in the log entry logged with the python logging framework (eg: logger.error('Something bad happened',exc_info=True) ) ---------- components: Library (Lib) messages: 75789 nosy: cjw296 severity: normal status: open title: repr of httplib.IncompleteRead is stupid type: resource usage versions: Python 2.5, Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 12 21:53:14 2008 From: report at bugs.python.org (David W. Lambert) Date: Wed, 12 Nov 2008 20:53:14 +0000 Subject: [New-bugs-announce] [issue4309] ctypes documentation In-Reply-To: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za> Message-ID: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za> New submission from David W. Lambert : ''' http://docs.python.org/dev/3.0/library/ctypes.html Where web page says >>> printf("An int %d, a double %f\n", 1234, c_double(3.14)) Integer 1234, double 3.1400001049 31 >>> should instead read >>> printf(c_char_p("An int %d, a double %f\n"), 1234, c_double(3.14)) An int 1234, a double 3.140000 31 Although the intent of the message is clear, it is inexact with regard to "An int" and "a double". Core dump is bigger problem: Processor: Dual-Core AMD Opteron(tm) Processor 2218 Python: Python 3.0rc1+ (py3k, Nov 5 2008, 14:44:46) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2 core dumps by segmentation fault for all the printf examples without specifying c_char_p("string"). ''' # this program succeeds from ctypes import * libc = CDLL("libc.so.6") print(libc.printf(c_char_p("An int %d, a double %f\n"), 1234, c_double(3.14))) ---------- assignee: georg.brandl components: Documentation messages: 75793 nosy: LambertDW, georg.brandl severity: normal status: open title: ctypes documentation type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 12 22:07:25 2008 From: report at bugs.python.org (Kyle Brandt) Date: Wed, 12 Nov 2008 21:07:25 +0000 Subject: [New-bugs-announce] [issue4310] Comparison of two ints returns wrong result In-Reply-To: <1226524045.46.0.613067395679.issue4310@psf.upfronthosting.co.za> Message-ID: <1226524045.46.0.613067395679.issue4310@psf.upfronthosting.co.za> New submission from Kyle Brandt : The attached program returns a false result on one of my computers with a Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz processor. Is seems the comparison of two int does not perform correctly. I have python 2.5.2 and 2.6.27-7-generic kernel. The lines of interest are 89-71: print type(f_p),type(largest),f_p,largest if f_p > largest: print 'foo' largest = f_p When running this code: # python id_11-2.py | grep 70600 70600674 51267216 # python id_11-2.py | grep foo #doesn't return anything When I run the same code on another machine the end result of the program is 70600674, whereas my current machine the end result is 51267216. ---------- files: id_11-2.py messages: 75794 nosy: kbrandt severity: normal status: open title: Comparison of two ints returns wrong result type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file11996/id_11-2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 12 23:35:23 2008 From: report at bugs.python.org (Alejandro) Date: Wed, 12 Nov 2008 22:35:23 +0000 Subject: [New-bugs-announce] [issue4311] Race condition on Multiprocessing module documentation In-Reply-To: <1226529323.41.0.396977390286.issue4311@psf.upfronthosting.co.za> Message-ID: <1226529323.41.0.396977390286.issue4311@psf.upfronthosting.co.za> New submission from Alejandro : The "devel" documentation of the "Multiprocessing" module at the "Exchanging objects between processes" section has the following example snippet: from multiprocessing import Process, Queue def f(q): q.put([42, None, 'hello']) if __name__ == '__main__': q = Queue() p = Process(target=f, args=(q,)) p.start() print q.get() # prints "[42, None, 'hello']" p.join() The last two lines should be swapped to avoid a race condition: p.join() print q.get() # prints "[42, None, 'hello']" BTW, Nice work. Keep on going folks =) ---------- assignee: georg.brandl components: Documentation messages: 75804 nosy: alejolp, georg.brandl severity: normal status: open title: Race condition on Multiprocessing module documentation versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 13 14:18:16 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Thu, 13 Nov 2008 13:18:16 +0000 Subject: [New-bugs-announce] [issue4312] Unicode in distutils meta-data? In-Reply-To: <1226582296.84.0.466381976068.issue4312@psf.upfronthosting.co.za> Message-ID: <1226582296.84.0.466381976068.issue4312@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : http://docs.python.org/dev/3.0/distutils/setupscript.html#additional-meta-data says "None of the string values may be Unicode.". How is this to be interpreted (or changed) w.r.t. Python 3.0? ---------- assignee: georg.brandl components: Documentation messages: 75816 nosy: georg.brandl, hagen severity: normal status: open title: Unicode in distutils meta-data? versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 13 14:24:16 2008 From: report at bugs.python.org (STINNER Victor) Date: Thu, 13 Nov 2008 13:24:16 +0000 Subject: [New-bugs-announce] [issue4313] IDLE segfault at exit In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za> Message-ID: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za> New submission from STINNER Victor : With Python 3.0 trunk on Ubuntu Gutsy, IDLE crashs at exit. gdb trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210763072 (LWP 9441)] 0xb79ac133 in Tk_Free3DBorder () from /usr/lib/libtk8.4.so.0 (gdb) where #0 0xb79ac133 in Tk_Free3DBorder () from /usr/lib/libtk8.4.so.0 #1 0xb7a3cb36 in TkTextFreeTag () from /usr/lib/libtk8.4.so.0 #2 0xb7a2aef1 in ?? () from /usr/lib/libtk8.4.so.0 #3 0x084ade70 in ?? () #4 0x084b2410 in ?? () #5 0xbfecb248 in ?? () #6 0xb798e518 in ?? () from /usr/lib/libtcl8.4.so.0 #7 0xbfecb250 in ?? () #8 0x084ade84 in ?? () #9 0xbfecb268 in ?? () #10 0xb798e518 in ?? () from /usr/lib/libtcl8.4.so.0 #11 0x084ade84 in ?? () #12 0x00000001 in ?? () #13 0x00000000 in ?? () ---------- messages: 75817 nosy: haypo severity: normal status: open title: IDLE segfault at exit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 13 15:39:38 2008 From: report at bugs.python.org (ZooKeeper) Date: Thu, 13 Nov 2008 14:39:38 +0000 Subject: [New-bugs-announce] [issue4314] isalpha bug In-Reply-To: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za> Message-ID: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za> New submission from ZooKeeper : This may be a little tricky to recreate but here it is: q = u'??????' q.isalpha() True foo = u'?' foo.isalpha() False So the Russian character u'?' and u'?' as well as a bunch of others is not recognized by isalpha as a alphabetic character, which it is a matter of fact. This applies to both capital and regular versions of the letters. http://en.wikipedia.org/wiki/%D0%81 http://en.wikipedia.org/wiki/Che_(Cyrillic) Using: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 ---------- components: Extension Modules, Unicode messages: 75820 nosy: ZooKeeper severity: normal status: open title: isalpha bug type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 13 17:06:13 2008 From: report at bugs.python.org (Silas S. Brown) Date: Thu, 13 Nov 2008 16:06:13 +0000 Subject: [New-bugs-announce] [issue4315] On some Python builds, exec in a function can't create shadows of variables if these are declared "global" in another function of the same module In-Reply-To: <1226592373.02.0.139711229291.issue4315@psf.upfronthosting.co.za> Message-ID: <1226592373.02.0.139711229291.issue4315@psf.upfronthosting.co.za> New submission from Silas S. Brown : Here's the example code: setting1 = "val1" setting2 = "val2" def dummy(): global setting1 def f(x): d ={"setting1":setting1,"setting2":setting2} exec(x) in d return d['setting1'], d['setting2'] print f("setting1=setting2='new'") Expected result: ('new', 'new') Actual result: ('val1', 'new') The presence of "global setting1" in a different function effectively stops a shadowed setting1 from being created by the exec. Workaround: Add a real assignment before the exec, i.e.: def f(x): setting1 = 0 exec(x) return setting1, setting2 or do the exec in a dictionary instead of in the current scope. Observed in: Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) on Cygwin Python 2.5.2 on 2.6.26-gentoo-r1 (by Christopher Faylor http://www.cygwin.com/ml/cygwin/2008-11/msg00168.html ) Not observed in: Python 2.5.1 (r251:54863, Aug 1 2008, 00:32:16) on SUSE Linux Python 2.4.4 (#2, Apr 17 2008, 01:58:28) (Debian etch, ARM) Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22) (Ubuntu) ---------- components: None messages: 75829 nosy: ssb22 severity: normal status: open title: On some Python builds, exec in a function can't create shadows of variables if these are declared "global" in another function of the same module type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 13 21:28:10 2008 From: report at bugs.python.org (Soren jacobsen) Date: Thu, 13 Nov 2008 20:28:10 +0000 Subject: [New-bugs-announce] [issue4316] Improper use of [] in configure.in leads to useless regexp in configure In-Reply-To: <1226608090.37.0.571135469469.issue4316@psf.upfronthosting.co.za> Message-ID: <1226608090.37.0.571135469469.issue4316@psf.upfronthosting.co.za> New submission from Soren jacobsen : "NetBSD/1.6[A-S]" is what is desired in configure, but the wrong configure.in goop is used, so "NetBSD/1.6A-S" is generated instead. Apply the attached patch, commit configure.in, run autoreconf, commit configure. ---------- components: Build files: netbsd-configure-in.diff keywords: patch messages: 75835 nosy: snj severity: normal status: open title: Improper use of [] in configure.in leads to useless regexp in configure type: compile error Added file: http://bugs.python.org/file12000/netbsd-configure-in.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 13 23:57:50 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 13 Nov 2008 22:57:50 +0000 Subject: [New-bugs-announce] [issue4317] Buffer overflow in imageop module In-Reply-To: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za> Message-ID: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : The interpreter sometimes segfaults when running the test suite, in test_imageop. A more reliable crasher is: >>> import imageop >>> s = "A" * 32000 >>> imageop.rgb2rgb8(s, 1, len(s)) The failure was recently introduced by r66689, a "security fix" :-( and backported today in 2.4! This is a 2.4 release blocker. Patch is attached, please review. ---------- files: rgbcrash.diff keywords: needs review, patch messages: 75840 nosy: amaury.forgeotdarc priority: release blocker severity: normal status: open title: Buffer overflow in imageop module type: crash versions: Python 2.4, Python 2.6 Added file: http://bugs.python.org/file12001/rgbcrash.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 14 01:37:45 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 14 Nov 2008 00:37:45 +0000 Subject: [New-bugs-announce] [issue4318] optparse: formatting of help text/descriptions In-Reply-To: <1226623065.62.0.674807245437.issue4318@psf.upfronthosting.co.za> Message-ID: <1226623065.62.0.674807245437.issue4318@psf.upfronthosting.co.za> New submission from A.M. Kuchling : (Copied from an anonymous submission in the Optik bug tracker.) There have been some recent discussions on comp.lang.python about the optparse/optik module, and Steve Bethard suggested you might be interested in some of the work done there. I don't know if you'd find any of this helpful for inclusion in Optik/optparse, but Steve says it's come up on your mailing list too. The problem at hand involves formatting help-strings so that they respect newlines. Simply passing formatted help-strings off to the textwrap.* methods mungs the newlines and loses them. The original thread: http://groups.google.com/group/comp.lang.python/browse_thread/thread/6df6e6 b541a15bc2/acf1d05cad60fc45?#acf1d05cad60fc45 My solution: http://groups.google.com/group/comp.lang.python/msg/09f28e26af0699b1 Dan then asked about it, and took my solution and ran with it: http://groups.google.com/group/comp.lang.python/browse_thread/thread/e72dee e779d9989b/4ec68cd2a35d52e1?hl=en#4ec68cd2a35d52e1 Feel free to do with it as you like. ---------- components: Library (Lib) messages: 75846 nosy: akuchling severity: normal status: open title: optparse: formatting of help text/descriptions type: feature request versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 14 01:39:22 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 14 Nov 2008 00:39:22 +0000 Subject: [New-bugs-announce] [issue4319] optparse and non-ascii help strings In-Reply-To: <1226623162.39.0.530373397898.issue4319@psf.upfronthosting.co.za> Message-ID: <1226623162.39.0.530373397898.issue4319@psf.upfronthosting.co.za> New submission from A.M. Kuchling : (copied from the Optik bug tracker) Related bug: http://www.mail-archive.com/python-bugs-list at python.org/msg07227.html Hi all, It seems to me that the workaround to the above bug in optparse.py versio 1.5.3 introduces a new bug when help strings are byte strings (as opposed to unicode) containing non-ascii characters. Consider the following script: $ cat test.py #!/usr/bin/env python # -*- coding:latin-1 -*- import optparse parser = optparse.OptionParser() parser.add_option("--test",help="This does not work: ?") parser.parse_args() When called with "$ ./test.py --help", this script fails with the following traceback: $ ./test.py -h Traceback (most recent call last): File "./test.py", line 7, in parser.parse_args() File "/usr/lib/python2.5/optparse.py", line 1385, in parse_args stop = self._process_args(largs, rargs, values) File "/usr/lib/python2.5/optparse.py", line 1429, in _process_args self._process_short_opts(rargs, values) File "/usr/lib/python2.5/optparse.py", line 1536, in _process_short_opts option.process(opt, value, values, self) File "/usr/lib/python2.5/optparse.py", line 782, in process self.action, self.dest, opt, value, values, parser) File "/usr/lib/python2.5/optparse.py", line 804, in take_action parser.print_help() File "/usr/lib/python2.5/optparse.py", line 1655, in print_help file.write(self.format_help().encode(encoding, "replace")) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 117: ordinal not in range(128) This behaviour can be reproduced with utf-8 encoded strings as well. If I understand correctly, line 1655 of optparse.py only works if format_help() returns an ascii byte string or a unicode string, but the call to "encoding" fails when it is a byte string containing non-ascii character. I think this is either a bug and should be fixed, or very misleading (and should be fixed too :). I hope to have helped even a little. Thanks for optparse, and keep up the good work! Cheers, Antoine ---------- components: Library (Lib) messages: 75847 nosy: akuchling severity: normal status: open title: optparse and non-ascii help strings type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 14 01:40:47 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 14 Nov 2008 00:40:47 +0000 Subject: [New-bugs-announce] [issue4320] optparse: "1 2 3" should be seen as one string In-Reply-To: <1226623247.3.0.318499239033.issue4320@psf.upfronthosting.co.za> Message-ID: <1226623247.3.0.318499239033.issue4320@psf.upfronthosting.co.za> New submission from A.M. Kuchling : (copied from the Optik bug tracker -- I haven't tried to replicate this.) ---------- components: Library (Lib) messages: 75848 nosy: akuchling severity: normal status: open title: optparse: "1 2 3" should be seen as one string versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 14 07:03:31 2008 From: report at bugs.python.org (Erick Tryzelaar) Date: Fri, 14 Nov 2008 06:03:31 +0000 Subject: [New-bugs-announce] [issue4321] unintended syntax error with decorators, parenthesis, and dots? In-Reply-To: <1226642611.77.0.508088542922.issue4321@psf.upfronthosting.co.za> Message-ID: <1226642611.77.0.508088542922.issue4321@psf.upfronthosting.co.za> New submission from Erick Tryzelaar : I believe I found an unintentional syntax error with a combination of decorators, parenthesis, and dots. Here's a demonstration: class C: def prop(self, function): return property(function) class F: @C().prop def foo(self): return 5 Which errors out with: File "foo.py", line 6 @C().prop ^ SyntaxError: invalid syntax I can't imagine why this would be desired, since these equivalent forms work: class D: def foo(self): return 5 foo = C().prop(foo) class E: c = C() @c.prop def foo(self): return 5 ---------- components: Interpreter Core messages: 75850 nosy: erickt severity: normal status: open title: unintended syntax error with decorators, parenthesis, and dots? type: compile error versions: Python 2.5.3, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 14 07:44:18 2008 From: report at bugs.python.org (Erick Tryzelaar) Date: Fri, 14 Nov 2008 06:44:18 +0000 Subject: [New-bugs-announce] [issue4322] function with modified __name__ uses original name when there's an arg error In-Reply-To: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za> Message-ID: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za> New submission from Erick Tryzelaar : I ran into a case where I modified the __name__ attribute of a function and then didn't specify the right number of arguments, and I got a TypeError that used the original function name, as demonstrated here: >>> def foo(): pass ... >>> foo.__name__ = 'bar' >>> foo(1) Traceback (most recent call last): File "", line 1, in TypeError: foo() takes no arguments (1 given) I would have expected it to say "TypeError: bar() ...". I'm guessing that the interpreter isn't using the __name__ attribute in this case. ---------- components: Library (Lib) messages: 75853 nosy: erickt severity: normal status: open title: function with modified __name__ uses original name when there's an arg error type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 14 12:03:15 2008 From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9?=) Date: Fri, 14 Nov 2008 11:03:15 +0000 Subject: [New-bugs-announce] [issue4323] Wrong encoding in files saved from IDLE (3.0rc2 on Windows) In-Reply-To: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za> Message-ID: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za> New submission from Andr? : When saving a source file with non-ascii characters from an IDLE window, on Windows platform (XP and Server 2003 at least) with locale English US locale.getdefaultlocale() ('en_US', 'cp1252') IDLE prompts in IOBinding.py with the message "non Ascii found, yet no encoding declared, Add a line like # -*- coding: cp1252 -*-" If accepted, the file is saved with the wrong encoding. Afterwards, it is read back by IDLE without any problem and it looks good in the IDLE window. However, if a string with non-ascii characters is sent to another module (i.e. email MIMEText) the string is wrong. The same source would be rejected by python in terminal mode and by IDLE on Linux. ---------- messages: 75855 nosy: andre severity: normal status: open title: Wrong encoding in files saved from IDLE (3.0rc2 on Windows) type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 14 14:28:31 2008 From: report at bugs.python.org (Kai Willadsen) Date: Fri, 14 Nov 2008 13:28:31 +0000 Subject: [New-bugs-announce] [issue4324] locale documentation is inconsistent In-Reply-To: <1226669311.11.0.409442120812.issue4324@psf.upfronthosting.co.za> Message-ID: <1226669311.11.0.409442120812.issue4324@psf.upfronthosting.co.za> New submission from Kai Willadsen : The documentation for locale.getlocale is not consistent with the example given. The docs for getlocale([category]) say: "category may be one of the LC_* values except LC_ALL." but the example at the bottom of the documentation starts with: >>> import locale >>> loc = locale.getlocale(locale.LC_ALL) # get current locale ... ---------- assignee: georg.brandl components: Documentation messages: 75861 nosy: georg.brandl, kaiw severity: normal status: open title: locale documentation is inconsistent versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 14 16:40:14 2008 From: report at bugs.python.org (dreamlusion) Date: Fri, 14 Nov 2008 15:40:14 +0000 Subject: [New-bugs-announce] [issue4325] Installer crash on cancel installation. In-Reply-To: <1226677214.08.0.98432240651.issue4325@psf.upfronthosting.co.za> Message-ID: <1226677214.08.0.98432240651.issue4325@psf.upfronthosting.co.za> New submission from dreamlusion : Steps to reproduce: 1. Start the installer (python-2.6.msi) 2. Choose install for all users, next. 3. Select default directory, next. 4. Click "Advanced". 5. Click "Cancel" and confirm (click yes). Bang. ---------- components: Installation messages: 75865 nosy: dreamlusion severity: normal status: open title: Installer crash on cancel installation. versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 14 22:36:32 2008 From: report at bugs.python.org (chafporte) Date: Fri, 14 Nov 2008 21:36:32 +0000 Subject: [New-bugs-announce] [issue4326] type of UserList instance returns class instead of instance In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za> Message-ID: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za> New submission from chafporte : from UserList import UserList lu = UserList() type(lu) python2.6 prints: python2.5 prints: ---------- components: None messages: 75885 nosy: chafporte severity: normal status: open title: type of UserList instance returns class instead of instance type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 14 22:47:39 2008 From: report at bugs.python.org (David Turner) Date: Fri, 14 Nov 2008 21:47:39 +0000 Subject: [New-bugs-announce] [issue4327] Patch: simplify complex constant assignment statements In-Reply-To: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za> Message-ID: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za> New submission from David Turner : This patch adds functionality to the optimizer to simplify complex constant assignments like: a, (b, c) = d, e = 1, (2, 3) The simplification is: a = 1 d = 1 b, c = e = 2, 3 Of course, the simplified version is semantically identical. But the bytecode generated is faster, because there is less need to unpack tuples. Naturally, this only works on constants: a, b = 1, a is not the same as a = 1 b = a ---------- files: tlee-ast-optimize-multiassign.diff keywords: patch messages: 75889 nosy: novalis_dt severity: normal status: open title: Patch: simplify complex constant assignment statements Added file: http://bugs.python.org/file12012/tlee-ast-optimize-multiassign.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 15 10:27:24 2008 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Nov 2008 09:27:24 +0000 Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlNDMyOF0gIsOgIiBpbiB1ImZv?= =?utf-8?q?o=22_raises_a_misleading_error?= In-Reply-To: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za> Message-ID: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za> New submission from Ezio Melotti : With Python 2.x: >>> '?' in u'foo' Traceback (most recent call last): File "", line 1, in ? TypeError: 'in ' requires string as left operand >>> '?' in u'x?x' Traceback (most recent call last): File "", line 1, in ? TypeError: 'in ' requires string as left operand The error claims that "'in ' requires string as left operand" when actually the left operand *is* a string. With Python2.6 with unicode_literals: >>> print(b'\x85') ? >>> b'\x85' in 'foo' Traceback (most recent call last): File "", line 1, in TypeError: 'in ' requires string as left operand With Python3.x the error is slightly different: TypeError: 'in ' requires string as left operand, not bytes but then it works with: >>> b'f' in 'foo' True This problem seems somehow related to the implicit decoding of '?'. I guess that '?' in u'foo' should raise a UnicodeDecodeError ('xxx' codec can't decode byte 0x85 ...), not a TypeError. ---------- components: Unicode messages: 75907 nosy: ezio.melotti severity: normal status: open title: "?" in u"foo" raises a misleading error versions: Python 2.4, Python 2.5, Python 2.5.3, Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 15 12:11:25 2008 From: report at bugs.python.org (Michael Becker) Date: Sat, 15 Nov 2008 11:11:25 +0000 Subject: [New-bugs-announce] [issue4329] base64 does not properly handle unicode strings In-Reply-To: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za> Message-ID: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za> New submission from Michael Becker : See below. unicode string causes exception. Explicitly converting it to a regular string addresses the issue. I only noticed this because my input string changed to unicode after updating python to 2.6 and django to 1.0. >>> import base64 >>> a=u'aHR0cDovL3NvdXJjZWZvcmdlLm5ldC90cmFja2VyMi8_ZnVuYz1kZXRhaWwmYWlkPTIyNTg5MzUmZ3JvdXBfaWQ9MTI2OTQmYXRpZD0xMTI2OTQ=' >>> b=base64.urlsafe_b64decode(a) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.6/base64.py", line 112, in urlsafe_b64decode return b64decode(s, '-_') File "/usr/local/lib/python2.6/base64.py", line 71, in b64decode s = _translate(s, {altchars[0]: '+', altchars[1]: '/'}) File "/usr/local/lib/python2.6/base64.py", line 36, in _translate return s.translate(''.join(translation)) TypeError: character mapping must return integer, None or unicode >>> b=base64.urlsafe_b64decode(str(a)) >>> b 'http://sourceforge.net/tracker2/?func=detail&aid=2258935&group_id=12694&atid=112694' ---------- components: Unicode messages: 75911 nosy: mbecker severity: normal status: open title: base64 does not properly handle unicode strings versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 16 01:43:04 2008 From: report at bugs.python.org (Ian Bicking) Date: Sun, 16 Nov 2008 00:43:04 +0000 Subject: [New-bugs-announce] [issue4330] wsgiref.validate doesn't accept arguments to readline In-Reply-To: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za> Message-ID: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za> New submission from Ian Bicking : The method wsgiref.validate:InputWrapper.readline doesn't take any arguments. It should take an optional size argument. Though this isn't part of the WSGI specification, the cgi module uses this argument when parsing the body, and in practice no applications that use cgi.FieldStorage (which is most applications) are compatible with wsgiref.validate as a result. Simply adding a *args that is passed to the underlying file fixes this. ---------- components: Library (Lib) messages: 75920 nosy: ianb severity: normal status: open title: wsgiref.validate doesn't accept arguments to readline versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 16 07:33:00 2008 From: report at bugs.python.org (scott sadler) Date: Sun, 16 Nov 2008 06:33:00 +0000 Subject: [New-bugs-announce] [issue4331] Can't use _functools.partial() created function as method In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za> Message-ID: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za> New submission from scott sadler : Calling a function created by _functools.partial as a method raises an exception: "TypeError: method_new() takes exactly n non-keyword arguments (0 given)" Where method_new is the function passed into partial() and n is the number of arguments it expects. This does not happen when using a python version of partial(). Strangely, in the circumstance that I originally encountered the bug, there was one instance that I was doing this and it _DID WORK_. The function being passed into partial() was the same as in the place where it was failing. The only significant difference that I could see was that the input function to partial() was being imported, rather than being defined in the same namespace as it was used I was unable to reproduce it in my test case (attatched). Tested on 2.6 and 2.5.2 ---------- components: Extension Modules files: partialbug.py messages: 75928 nosy: ssadler severity: normal status: open title: Can't use _functools.partial() created function as method type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file12017/partialbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 17 01:20:32 2008 From: report at bugs.python.org (Christian Becke) Date: Mon, 17 Nov 2008 00:20:32 +0000 Subject: [New-bugs-announce] [issue4332] asyncore.file_dispatcher does not use dup()'ed fd In-Reply-To: <1226881232.51.0.043979894828.issue4332@psf.upfronthosting.co.za> Message-ID: <1226881232.51.0.043979894828.issue4332@psf.upfronthosting.co.za> New submission from Christian Becke : asyncore.file_dispatcher stores the file descriptor passed to asyncore.file_dispatcher.__init__ into the map, not the dup()'ed one created by asyncore.file_wrapper. Because of this, a "select.error (9, 'Bad file descriptor')" is raised in asyncore.loop() if the fd passed to asyncore.file_dispatcher.__init__ is closed while the loop is running. Attached patch fixes the issue. ---------- components: Library (Lib) files: asyncore_file_dispatcher_use_duped_fd.diff keywords: patch messages: 75947 nosy: christianbecke severity: normal status: open title: asyncore.file_dispatcher does not use dup()'ed fd type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file12022/asyncore_file_dispatcher_use_duped_fd.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 17 01:23:24 2008 From: report at bugs.python.org (Guilherme Polo) Date: Mon, 17 Nov 2008 00:23:24 +0000 Subject: [New-bugs-announce] [issue4333] Reworked Dialog.py In-Reply-To: <1226881404.91.0.533308530681.issue4333@psf.upfronthosting.co.za> Message-ID: <1226881404.91.0.533308530681.issue4333@psf.upfronthosting.co.za> New submission from Guilherme Polo : Hi, I have changed the lib-tk/Dialog.py so it handles the cases where one might receive a tuple as a result containing a Tcl_Obj. I've also modified all the rest of it to make it "cleaner". It is b/w compatible although I dislike the usage of cnf, but I guess I'm too late to suggest this change even for py3k :/ A "more complete" description of the changes is in http://svn.python.org/view?rev=67240&view=rev ---------- components: Tkinter files: Dialog.diff keywords: patch messages: 75948 nosy: gpolo severity: normal status: open title: Reworked Dialog.py versions: Python 2.7 Added file: http://bugs.python.org/file12023/Dialog.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 17 01:25:24 2008 From: report at bugs.python.org (Noah Gift) Date: Mon, 17 Nov 2008 00:25:24 +0000 Subject: [New-bugs-announce] [issue4334] Mac Build Script is broken for 2.6 release In-Reply-To: <1226881524.11.0.708163109076.issue4334@psf.upfronthosting.co.za> Message-ID: <1226881524.11.0.708163109076.issue4334@psf.upfronthosting.co.za> New submission from Noah Gift : Just an FYI, the Mac Build script in: Python-2.6 2/Mac/BuildScript/build-installer.py contains broken download URLs for SQLite, and cause the build to fail. I fixed this myself, but noticed this appears to be fixed in the trunk, already. Having a working build script is a fairly big deal for mac users, as they often need to have readline compiled properly with Python, which is a pain. This might be nice to have fixed in the production release. ---------- components: Build messages: 75949 nosy: ngift severity: normal status: open title: Mac Build Script is broken for 2.6 release type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 17 09:09:11 2008 From: report at bugs.python.org (Rafe Sacks) Date: Mon, 17 Nov 2008 08:09:11 +0000 Subject: [New-bugs-announce] [issue4335] inspect.getsourcelines ignores last line in module In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> Message-ID: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za> New submission from Rafe Sacks : Hi, If the last line of the function is also the last line of the module, it is ignored. To repro: 1) Create module 'repro' def test(): module_line_2 = None module_line_3 = None module_line_4 = None module_line_5 = None 2) Run test: >>> import repro >>> import inspect >>> inspect.getsourcelines(tmp.test) (['def test():\n', ' module_line_2 = None\n', ' module_line_3 = None\n', ' module_line_4 = None\n'], 1) notice no module_line_5. cheers, - Rafe ---------- components: Library (Lib) messages: 75953 nosy: RafeSacks severity: normal status: open title: inspect.getsourcelines ignores last line in module versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 17 15:33:41 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 17 Nov 2008 14:33:41 +0000 Subject: [New-bugs-announce] [issue4336] Fix performance issues in xmlrpclib In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za> Message-ID: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : There are two performance problems in xmlrpclib.py: POST requests use two send() calls, one to send the headers and one to send the data. This can invoke the Nagle/Delayed ACK performance problem. On many socket implementations (including some windows platforms) it can introduce delays of up to 200ms when talking over the wire (as opposed to localhost) The second is the use of no buffering when reading the xmlrpc response. It is done using the readline() call on a file-like object constructed from the socket. When no buffering is in effect, this causes a separate recv() call for each character. This patch fixes these issues separately: 1) We provide a new getheaderdata() function in httplib which just returns the data for the headers instead of sending it. This can be used instead of endheaders() if the intention is to subsequently send more data. xmlrpclib then uses this method of framing its POST messages. 2) We provide the named artgument bufsize=0 to the HTTPResponse class in httplib, and also so on for the HTTPConnection.getresponse() and HTTP.getreply(). xmlrpclib then passes bufsize=-1 to HTTP.getreply() to get default buffering for the response fileobject. This patch focuses on fixing the problems with xmlrpclib. but issue 1) above also has a number of other manifestations in the lib, there are other places where we can use getheaderdata() and send() instead of endheaders() to avoid possible Nagle/Ack problems, e.g. in urllib.py, distutils.py and loggin/handlers.py ---------- components: Extension Modules files: xmlrpc.patch keywords: easy, patch, patch messages: 75962 nosy: krisvale severity: normal status: open title: Fix performance issues in xmlrpclib type: performance versions: Python 2.7 Added file: http://bugs.python.org/file12030/xmlrpc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 17 16:54:36 2008 From: report at bugs.python.org (Jean-Michel Fauth) Date: Mon, 17 Nov 2008 15:54:36 +0000 Subject: [New-bugs-announce] [issue4337] Iteration over a map object with list() In-Reply-To: <1226937276.11.0.323552231555.issue4337@psf.upfronthosting.co.za> Message-ID: <1226937276.11.0.323552231555.issue4337@psf.upfronthosting.co.za> New submission from Jean-Michel Fauth : win XP sp2, Py3.0c2 I had to face an annoying problem when iterating over a map object. With a range class, this works >>> r = range(5) >>> list(r) [0, 1, 2, 3, 4] With dict_keys/values/items objects, the following works >>> d = {1: 'a', 2:'b', 3:'c'} >>> list(d.keys()) [1, 2, 3] >>> list(d.values()) ['a', 'b', 'c'] >>> list(d.items()) [(1, 'a'), (2, 'b'), (3, 'c')] But with a map object... >>> def plus(i): return i + 1 >>> a = list(range(3)) >>> a [0, 1, 2] >>> r = map(plus, a) >>> r >>> for e in r: print(e) 1 2 3 >>> list(r) [] >>> #empty list! Bug or feature? ---------- components: None messages: 75965 nosy: jmfauth severity: normal status: open title: Iteration over a map object with list() versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 17 18:40:10 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Mon, 17 Nov 2008 17:40:10 +0000 Subject: [New-bugs-announce] [issue4338] TypeError (bytes/str) in distutils command "upload" In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za> Message-ID: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : "python3.0 setup.py upload" (on an otherwise sane setup script) results in the following: Traceback (most recent call last): File "setup.py", line 5, in import py3setup File "/home/MP/hagenf/src/pyskein/py3setup.py", line 22, in ext_modules=[ext]) File "/home/MP/hagenf/local/lib/python3.0/distutils/core.py", line 149, in setup dist.run_commands() File "/home/MP/hagenf/local/lib/python3.0/distutils/dist.py", line 942, in run_commands self.run_command(cmd) File "/home/MP/hagenf/local/lib/python3.0/distutils/dist.py", line 962, in run_command cmd_obj.run() File "/home/MP/hagenf/local/lib/python3.0/distutils/command/upload.py", line 55, in run self.upload_file(command, pyversion, filename) File "/home/MP/hagenf/local/lib/python3.0/distutils/command/upload.py", line 116, in upload_file auth = "Basic " + base64.encodestring(self.username + ":" + self.password).strip() File "/home/MP/hagenf/local/lib/python3.0/base64.py", line 338, in encodestring raise TypeError("expected bytes, not %s" % s.__class__.__name__) TypeError: expected bytes, not str ---------- components: Distutils messages: 75975 nosy: hagen severity: normal status: open title: TypeError (bytes/str) in distutils command "upload" type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 17 21:14:19 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 17 Nov 2008 20:14:19 +0000 Subject: [New-bugs-announce] [issue4339] Fix set-like dictview doc In-Reply-To: <1226952859.0.0.283857665516.issue4339@psf.upfronthosting.co.za> Message-ID: <1226952859.0.0.283857665516.issue4339@psf.upfronthosting.co.za> New submission from Terry J. Reedy : I see two problems with the current (.rc2) doc on "Dictionary view objects" that are set-like. 1. The first paragraph of the section ends with the fragment "The keys and items views have a set-like character since their entries" This is not only incomplete, but wrong. Items views are set-like (entries are unique and hashable) only if all values are hashable, as revealed way at the end in a 'warning' that is only needed because of the previous over-generalization. I recommend that this fragment, the one sentence after the 'x in dictview' entry, and the warning be combined into one paragraph that tells the complete story at the appropriate place, which is where the 'one sentence' is now. "Keys views are set-like since their entries are unique and hashable. If all values are hashable, so that (key,value) pairs are unique and hashable, then an items view is also set-like. (Values views are not treated as set-like since the entries are generally not unique.) Let 'set-view' and 'other' each be a set or set-like view. Then the following set operations are available." This suggestion also addresses the second problem I see. The set operations are symmetric, but 'dictview op other' is not. It excludes the valid combination 'set op dictview'. So I think all 4 ops should be listed as 'set-view op other' instead, after the revised introduction above. ---------- assignee: georg.brandl components: Documentation messages: 75979 nosy: georg.brandl, tjreedy severity: normal stage: needs patch status: open title: Fix set-like dictview doc versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 17 21:55:59 2008 From: report at bugs.python.org (Mike Watkins) Date: Mon, 17 Nov 2008 20:55:59 +0000 Subject: [New-bugs-announce] [issue4340] xmlrpc.client - default 'SlowParser' not defined In-Reply-To: <1226955359.62.0.344103118813.issue4340@psf.upfronthosting.co.za> Message-ID: <1226955359.62.0.344103118813.issue4340@psf.upfronthosting.co.za> New submission from Mike Watkins : Running example code from docs: http://docs.python.org/dev/3.0/library/xmlrpc.client.html#example-of- client-usage z% python Python 3.0rc2+ (py3k:67152, Nov 7 2008, 16:48:55) [GCC 4.2.1 20070719 [FreeBSD]] on freebsd7 Type "help", "copyright", "credits" or "license" for more information. >>> str(None) 'None' >>> from xmlrpc.client import ServerProxy, Error >>> server = ServerProxy("http://betty.userland.com") >>> print(server) >>> print(server) >>> print(server.examples.getStateName(41)) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1095, in __call__ return self.__send(self.__name, args) File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1353, in __request verbose=self.__verbose File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1136, in request return self._parse_response(resp, None) File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1235, in _parse_response p, u = self.getparser() File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1145, in getparser return getparser(use_datetime=self._use_datetime) File "/usr/local/lib/python3.0/xmlrpc/client.py", line 975, in getparser parser = SlowParser(target) NameError: global name 'SlowParser' is not defined No definition of SlowParser in client.py: /src/py3k/Lib/xmlrpc% grep -n SlowParser client.py 116: SlowParser Slow but safe standard parser (based on xmllib) 975: parser = SlowParser(target) ---------- components: Library (Lib) messages: 75980 nosy: mwatkins severity: normal status: open title: xmlrpc.client - default 'SlowParser' not defined versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 17 22:48:35 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 17 Nov 2008 21:48:35 +0000 Subject: [New-bugs-announce] [issue4341] Update __hash__ doc In-Reply-To: <1226958515.3.0.535002715337.issue4341@psf.upfronthosting.co.za> Message-ID: <1226958515.3.0.535002715337.issue4341@psf.upfronthosting.co.za> New submission from Terry J. Reedy : Language/data model/special method names/ __hash__ Sentence 1: "Called for the key object for dictionary operations, and by the built-in function hash()." Also called for the members of set and frozenset (and any other hashed based collection). Suggestion 1: "Called by the built-in function hash() and for operations on members or keys of hashed collections. These currently include the built-in classes set, frozenset, and dict." Corresponding future-proof changes later in the text: >From "its instances will not be usable as dictionary keys" to "its instances will not be usable as hashable members or keys". >From "since the dictionary implementation requires" to "since hashable collection implementations require" ============================== Sentence 2: "Should return an integer usable as a hash value for dictionary operations." I am confused by the qualification 'usable....'. If it does not qualify, it is meaningless and should be removed. If it does qualify, it should be replaced by what it means. My impression is that integers of any value are usable since 2.5. It is also my impression that 2.x specifically requires an int or long. If so, "Should return an int or long integer." would be clearer. For 3.0, I don't know what the boundaries are. A float works, even if not integral. [bug?] A Fraction does not, even if integral, even though int(Fraction(n,1)) returns n. ---------- assignee: georg.brandl components: Documentation messages: 75984 nosy: georg.brandl, tjreedy severity: normal stage: needs patch status: open title: Update __hash__ doc versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 18 01:41:32 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 18 Nov 2008 00:41:32 +0000 Subject: [New-bugs-announce] [issue4342] (Tkinter) Please backport these In-Reply-To: <1226968892.91.0.114807177432.issue4342@psf.upfronthosting.co.za> Message-ID: <1226968892.91.0.114807177432.issue4342@psf.upfronthosting.co.za> New submission from Guilherme Polo : Please consider backporting r59653 and r59654 to release25-maint branch. It may be of interest to backport r52688 too, also, r63776 together with r63914 (without these last two I get segfault when passing a list as an option value). Finally there is this issue4333 which wasn't committed anywhere, but if it gets committed I would like to see it getting backported too. Thanks. ---------- components: Tkinter messages: 75995 nosy: gpolo severity: normal status: open title: (Tkinter) Please backport these versions: Python 2.5.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 18 13:39:19 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 18 Nov 2008 12:39:19 +0000 Subject: [New-bugs-announce] [issue4343] New function in Tkinter.py: setup_master In-Reply-To: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za> Message-ID: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za> New submission from Guilherme Polo : Hi, I've added a new function called setup_master. This function is responsible for returning an usable master to the caller, or fail and say so. The function is useful for any wrapper basically, since all them has to set up a master sometime (or maybe always require a master, but that is not very nice) and will usually do it half wrong. The half wrong is about relying on _default_root being available in Tkinter, which is not the case if support for default root has been disabled. There are two patches, the first adds the function, the second applies it self where necessary in Tkinter. The later also adds some new behaviour in Tkinter, previously Variable class and subclasses wouldn't work properly without prior creation of a master (there are similar problems in other parts too). ---------- components: Tkinter files: setup_master.diff keywords: patch messages: 76005 nosy: gpolo severity: normal status: open title: New function in Tkinter.py: setup_master versions: Python 2.7, Python 3.0 Added file: http://bugs.python.org/file12040/setup_master.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 18 13:49:41 2008 From: report at bugs.python.org (kasper) Date: Tue, 18 Nov 2008 12:49:41 +0000 Subject: [New-bugs-announce] [issue4344] crash upon launch In-Reply-To: <1227012581.68.0.953294205264.issue4344@psf.upfronthosting.co.za> Message-ID: <1227012581.68.0.953294205264.issue4344@psf.upfronthosting.co.za> New submission from kasper : Hi I'm new at programming and have chosen to start with python, and so I have installed python 2.6, and played around with it a little. However, a problem has occured: yesterday when i tried to run the program - pythonwin editor 2.6.0 - a crash occured immediately upon launch. All i do is start up the program, and while trying to open, the program crashes, and a windows error window pops up, telling me that 'the program has encountered an error, and will now exit' - not telling me anything useful about what kind of error has occured, or why. As usual, the windows errorreport is of no use. And so I have little idea of what causes the crash, but I do have a suspicion that the .dll mfc90.dll might be a part of the problem, since it is mentioned in the beginning of the errorreport. Looking forward to hear from you. Kasper ---------- components: Windows messages: 76006 nosy: source.mod severity: normal status: open title: crash upon launch type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 18 15:01:15 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 18 Nov 2008 14:01:15 +0000 Subject: [New-bugs-announce] [issue4345] Implement nb_nonzero for PyTclObject In-Reply-To: <1227016875.57.0.463307209634.issue4345@psf.upfronthosting.co.za> Message-ID: <1227016875.57.0.463307209634.issue4345@psf.upfronthosting.co.za> New submission from Guilherme Polo : Implementing it makes this "crazy" check in http://bugs.python.org/issue3767 (http://bugs.python.org/file12043/tkColorChooser.diff) be no longer needed ---------- components: Tkinter files: _tkinter__nonzero__.diff keywords: patch messages: 76008 nosy: gpolo severity: normal status: open title: Implement nb_nonzero for PyTclObject versions: Python 2.6, Python 2.7, Python 3.0 Added file: http://bugs.python.org/file12044/_tkinter__nonzero__.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 18 15:15:20 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 18 Nov 2008 14:15:20 +0000 Subject: [New-bugs-announce] [issue4346] PyObject_CallMethod changes the exception message already set by PyObject_GetAttr In-Reply-To: <1227017720.01.0.112991590053.issue4346@psf.upfronthosting.co.za> Message-ID: <1227017720.01.0.112991590053.issue4346@psf.upfronthosting.co.za> New submission from Guilherme Polo : Why is PyObject_CallMethod resetting the exception message that is already set (if an exception happened, that is) by PyObject_Getattr ? ---------- components: Interpreter Core files: abstract_dont_re_set_except_msg.diff keywords: patch messages: 76009 nosy: gpolo severity: normal status: open title: PyObject_CallMethod changes the exception message already set by PyObject_GetAttr versions: Python 2.7 Added file: http://bugs.python.org/file12045/abstract_dont_re_set_except_msg.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 18 16:28:11 2008 From: report at bugs.python.org (Thomas Lee) Date: Tue, 18 Nov 2008 15:28:11 +0000 Subject: [New-bugs-announce] [issue4347] Dependencies of graminit.h are not rebuilt when the file is regenerated In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> New submission from Thomas Lee : It's important that dependencies of grammar.h get rebuilt if graminit.h is regenerated (e.g. the Grammar is modified). If these dependencies do not get rebuilt, the constants associated with each type of parse node will have inconsistent values between the different intermediate files. The net result is that a program afflicted by this might build without errors, but then crash unexpectedly at runtime due to the inconsistent constant values. The patch is quite simple and ensures that all files that currently depend on graminit.h are rebuilt if it changes. It also removes an unnecessary #include from Python/future.c. I believe a similar situation might occur with Python-ast.h and the *_kind enumerations, but have yet to run into such a specific issue. I'll post a separate patch if I do find this to be a problem. ---------- components: Build files: graminit-dependencies.patch keywords: patch messages: 76010 nosy: thomas.lee severity: normal status: open title: Dependencies of graminit.h are not rebuilt when the file is regenerated type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file12046/graminit-dependencies.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 18 22:29:15 2008 From: report at bugs.python.org (Dino Viehland) Date: Tue, 18 Nov 2008 21:29:15 +0000 Subject: [New-bugs-announce] [issue4348] bytearray methods returning self In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za> Message-ID: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za> New submission from Dino Viehland : In 2.6 but not in 3.0 RC2: x = bytearray(b'abc') y = x.replace(b'abc', b'bar', 0) id(x) == id(y) In 2.6 and in 3.0 RC2: t = bytearray() for i in range(256): t.append(i) x = bytearray(b'') y = x.translate(t) id(x) == id(y) ---------- messages: 76012 nosy: DinoV severity: normal status: open title: bytearray methods returning self type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 18 22:36:32 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Tue, 18 Nov 2008 21:36:32 +0000 Subject: [New-bugs-announce] [issue4349] sys.path includes extraneous junk In-Reply-To: <1227044192.68.0.160920298977.issue4349@psf.upfronthosting.co.za> Message-ID: <1227044192.68.0.160920298977.issue4349@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone : With a recent build of the py3k branch, sys.path ends up with this element: /home/exarkun/Projects/python/branches/py3k/Lib/plat-linux2 at EXTRAMACHDEPPATH@ which doesn't exist and doesn't look like it should exist. plat-linux2, which does exist, doesn't end up winth sys.path. ---------- components: Interpreter Core messages: 76013 nosy: exarkun severity: normal status: open title: sys.path includes extraneous junk type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 19 01:14:19 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 19 Nov 2008 00:14:19 +0000 Subject: [New-bugs-announce] [issue4350] Remove dead code from Tkinter.py In-Reply-To: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za> Message-ID: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za> New submission from Guilherme Polo : There are some methods (which call tk commands) that no longer exist, for a long time now so this patch remove them. There are also these "indices" functions, which do not belong to the module space and now are gone too. ---------- files: remove_dead_code.diff keywords: patch messages: 76030 nosy: gpolo severity: normal status: open title: Remove dead code from Tkinter.py versions: Python 2.7, Python 3.0 Added file: http://bugs.python.org/file12050/remove_dead_code.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 19 01:22:34 2008 From: report at bugs.python.org (Philip Jenvey) Date: Wed, 19 Nov 2008 00:22:34 +0000 Subject: [New-bugs-announce] [issue4351] [PATCH] Better stacklevel for GzipFile.filename DeprecationWarning In-Reply-To: <1227054154.01.0.966318023814.issue4351@psf.upfronthosting.co.za> Message-ID: <1227054154.01.0.966318023814.issue4351@psf.upfronthosting.co.za> New submission from Philip Jenvey : This should be a stacklevel of 2 so we're told who accessed the attribute ---------- components: Library (Lib) files: gzip-deprecation_r67276.diff keywords: patch messages: 76031 nosy: pjenvey severity: normal status: open title: [PATCH] Better stacklevel for GzipFile.filename DeprecationWarning type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file12051/gzip-deprecation_r67276.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 19 06:17:46 2008 From: report at bugs.python.org (Jukka Aho) Date: Wed, 19 Nov 2008 05:17:46 +0000 Subject: [New-bugs-announce] [issue4352] imp.find_module() causes UnicodeDecodeError with non-ASCII search paths In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za> Message-ID: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za> New submission from Jukka Aho : imp.find_module() seems to cause an UnicodeDecodeError when the path list contains paths with non-ASCII names. Tested on Windows [1]; see the attached test case which demonstrates the problem. [1] Python 3.0rc2 (r30rc2:67141, Nov 7 2008, 11:43:46) [MSC v.1500 32 bit (Intel)] on win32 ---------- components: Library (Lib), Unicode, Windows files: find_module.py messages: 76038 nosy: Jukka Aho severity: normal status: open title: imp.find_module() causes UnicodeDecodeError with non-ASCII search paths type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file12055/find_module.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 19 16:34:27 2008 From: report at bugs.python.org (rocky bernstein) Date: Wed, 19 Nov 2008 15:34:27 +0000 Subject: [New-bugs-announce] [issue4353] Move description what a trace should should return to settrace from pdb section into sys.settrace section In-Reply-To: <1227108867.52.0.266510859122.issue4353@psf.upfronthosting.co.za> Message-ID: <1227108867.52.0.266510859122.issue4353@psf.upfronthosting.co.za> New submission from rocky bernstein : This sentence: The local trace function should return a reference to itself (or to another function for further tracing in that scope), or None to turn off tracing in that scope. which appears under "How it [the debugger] Works" (http://docs.python.org http://docs.python.org/library/pdb.html#debugger-hooks) should appear under the description of (sys.settrace http://docs.python.org/library/sys.html) since this really part of the settrace interface and is not limited to the python debugger, pdb, or debuggers in general. ---------- assignee: georg.brandl components: Documentation messages: 76051 nosy: georg.brandl, rocky severity: normal status: open title: Move description what a trace should should return to settrace from pdb section into sys.settrace section type: crash versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 19 17:11:58 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Wed, 19 Nov 2008 16:11:58 +0000 Subject: [New-bugs-announce] [issue4354] distutils.command.register is broken In-Reply-To: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za> Message-ID: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : The distutils command "register" has two problems with Python 3.0: 1. The authentication dialog crashes because of a problem with the functiopn raw_input defined there. 2. Uploading the data fails because of str/bytes confusion. The attached patch addresses both problems. ---------- components: Distutils files: distutils_register.patch keywords: patch messages: 76055 nosy: hagen severity: normal status: open title: distutils.command.register is broken type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file12058/distutils_register.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 19 17:19:54 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Wed, 19 Nov 2008 16:19:54 +0000 Subject: [New-bugs-announce] [issue4355] Error in docs of urllib.request and urllib.parse In-Reply-To: <1227111594.24.0.921624476893.issue4355@psf.upfronthosting.co.za> Message-ID: <1227111594.24.0.921624476893.issue4355@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : The docs refer to urllib.urlencode instead of urllib.parse.urlencode. A patch is attached. ---------- assignee: georg.brandl components: Documentation files: doc_urlencode.patch keywords: patch messages: 76056 nosy: georg.brandl, hagen severity: normal status: open title: Error in docs of urllib.request and urllib.parse versions: Python 3.0 Added file: http://bugs.python.org/file12059/doc_urlencode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 19 18:17:28 2008 From: report at bugs.python.org (Miki Tebeka) Date: Wed, 19 Nov 2008 17:17:28 +0000 Subject: [New-bugs-announce] [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> New submission from Miki Tebeka : It'd be helpful of the functions in the "bisect" modules will have a "key" argument just like "sort". ---------- messages: 76060 nosy: tebeka severity: normal status: open title: Add "key" argument to "bisect" module functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 19 18:41:28 2008 From: report at bugs.python.org (Alex Samuel) Date: Wed, 19 Nov 2008 17:41:28 +0000 Subject: [New-bugs-announce] [issue4357] frozen?set operations create incorrectly initialized instances of subclasses In-Reply-To: <1227116488.66.0.564572723144.issue4357@psf.upfronthosting.co.za> Message-ID: <1227116488.66.0.564572723144.issue4357@psf.upfronthosting.co.za> New submission from Alex Samuel : Methods of set and frozenset that return new set or frozenset instances return instances of subclasses, but these instances are not initialized correctly. In the attached code sample, z is an instance of MySet but MySet.__new__ and MySet.__init__ are never called on it. It seems to me that such a method should return a fully-initialized instance of the subclass. Barring that, it should just return a set or frozenset instance, not an instance of the subclass. ---------- assignee: theller components: ctypes files: fs.py messages: 76062 nosy: alexhsamuel, theller severity: normal status: open title: frozen?set operations create incorrectly initialized instances of subclasses type: behavior versions: Python 2.5, Python 3.0 Added file: http://bugs.python.org/file12062/fs.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 19 19:34:30 2008 From: report at bugs.python.org (Farshad Khoshkhui) Date: Wed, 19 Nov 2008 18:34:30 +0000 Subject: [New-bugs-announce] [issue4358] Segfault in stringobject.c In-Reply-To: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za> Message-ID: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za> New submission from Farshad Khoshkhui : I'm encountering random segfaults on multiple machines. By examining core dumps, it's all happening in stringobject.c (_PyString_Resize or string_join). By using pyframev I figured out it's always happening inside xmlrpclib.py (/usr/lib/python2.5/xmlrpclib.py (716): dump_struct or /usr/lib/python2.5/xmlrpclib.py (627): dumps) I'm using Python 2.5.2 on debian in a threaded environment with heavy use of xmlrpc. ---------- assignee: theller components: XML, ctypes files: backtrace1 messages: 76066 nosy: farshad, theller severity: normal status: open title: Segfault in stringobject.c type: crash versions: Python 2.5 Added file: http://bugs.python.org/file12063/backtrace1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 20 00:52:17 2008 From: report at bugs.python.org (Toshio Kuratomi) Date: Wed, 19 Nov 2008 23:52:17 +0000 Subject: [New-bugs-announce] [issue4359] at runtime, distutils uses buildtime files In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za> Message-ID: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za> New submission from Toshio Kuratomi : When using some distutils functions, distutils attempts to use buildtime files like Makefile and pyconfig*.h as data sources. For instance, this snippet:: from distutils.command.install import install from distutils.core import Distribution dist = Distribution({"name": "foopkg"}) cmd = install(dist) cmd.ensure_finalized() There's two reasons this should change. 1) Some Linux distributions separate the python runtime and buildtime files and put the buildtime files in a -devel package. Depending on these buildtime files means that the -devel package can be needed for running python scripts. For instance, here's the traceback that occurs when the previous commands are run without python-devel on Fedora Linux:: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/distutils/cmd.py", line 117, in ensure_finalized self.finalize_options() File "/usr/lib/python2.5/distutils/command/install.py", line 273, in finalize_options (prefix, exec_prefix) = get_config_vars('prefix', 'exec_prefix') File "/usr/lib/python2.5/distutils/sysconfig.py", line 493, in get_config_vars func() File "/usr/lib/python2.5/distutils/sysconfig.py", line 352, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/lib/python2.5/config/Makefile (No such file or directory) 2) keeping the information in a Makefile and *.h files and then having regular expressions pull the information out is fragile and not what the tools were meant for. Using a defined data format is much better. The variables necessary for building extensions should be placed in a data file of some sort. This can be built by the configure script at the same time as it's substituting variables into the Makefile and pyconfig files. xml is good for interoperability and we have good modules in the std library for that now. .ini is less verbose and we have modules to deal with that as well. ---------- components: Distutils messages: 76083 nosy: a.badger severity: normal status: open title: at runtime, distutils uses buildtime files type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 20 11:29:20 2008 From: report at bugs.python.org (kai zhu) Date: Thu, 20 Nov 2008 10:29:20 +0000 Subject: [New-bugs-announce] [issue4360] SystemError when method has both super() & closure In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za> Message-ID: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za> New submission from kai zhu : ################################ # super_closure.py class A(object): def foo(self): return super() # remove the closure below # & SystemError goes away ??? lambda: self A().foo() ################################ when run on 3.0rc1 & 3.0rc2: hpc-login2 3 ~/work/py3to2: python3.0 super_closure.py Traceback (most recent call last): File "super_closure.py", line 9, in A().foo() File "super_closure.py", line 5, in foo return super() SystemError: super(): __class__ is not a type (A) SystemError seems to b raised from typeobject.c (line6155): static int super_init(PyObject *self, PyObject *args, PyObject *kwds) {... if (!PyType_Check(type)) { PyErr_Format(PyExc_SystemError, "super(): __class__ is not a type (%s)", Py_TYPE(type)->tp_name); return -1; } break; ---------- components: Build, Interpreter Core messages: 76093 nosy: kaizhu severity: normal status: open title: SystemError when method has both super() & closure type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 20 13:42:48 2008 From: report at bugs.python.org (thp) Date: Thu, 20 Nov 2008 12:42:48 +0000 Subject: [New-bugs-announce] [issue4361] Docstring for "Lib/string.py" is outdated In-Reply-To: <1227184968.64.0.811041606953.issue4361@psf.upfronthosting.co.za> Message-ID: <1227184968.64.0.811041606953.issue4361@psf.upfronthosting.co.za> New submission from thp : The docstring in "Lib/string.py" in the source of "Python 3.0rc2" is wrong. It currently says "lowercase", "uppercase" and "letters" where it should say "ascii_lowercase", "ascii_uppercase" and "ascii_letters". ---------- assignee: georg.brandl components: Documentation files: Lib_string_py-docstring.patch keywords: patch messages: 76097 nosy: georg.brandl, thp severity: normal status: open title: Docstring for "Lib/string.py" is outdated versions: Python 3.0 Added file: http://bugs.python.org/file12069/Lib_string_py-docstring.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 20 14:18:28 2008 From: report at bugs.python.org (David M. Beazley) Date: Thu, 20 Nov 2008 13:18:28 +0000 Subject: [New-bugs-announce] [issue4362] FileIO object in io module In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za> Message-ID: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za> New submission from David M. Beazley : The FileIO object defined in the new io library has "name" and "mode" properties. However, attempts to access either value result in an AttributeError exception. The C source code in _fileio.c doesn't even implement a name attribute and it uses a different name for mode ("mode" instead of "_mode" that the property is looking for). Broken in 2.6 and 3.0rc2. ---------- components: Library (Lib) messages: 76100 nosy: beazley severity: normal status: open title: FileIO object in io module type: behavior versions: Python 2.6 _______________________________________ Python tracker