301 Moved Permanently

Does this work fine with common Web browsers, including not-most-recent versions, and various resolutions? (?fine? being defined as ?not worse than before the patch?) http://codereview.appspot.com/4090042/diff/1/Lib/pydoc.py#newcode2591 Lib/pydoc.py:2591: return '%s' % (name, name) I see no reason for polluting the key value with ?.html? http://codereview.appspot.com/4090042/diff/1/Lib/pydoc.py#newcode2713 Lib/pydoc.py:2713: raise TypeError('unknown content type %r' % ([url, content_type])) You can remove the extraneous parens around the list. http://codereview.appspot.com/4090042/diff/1/Lib/test/test_pydoc.py File Lib/test/test_pydoc.py (right): http://codereview.appspot.com/4090042/diff/1/Lib/test/test_pydoc.py#newcode431 Lib/test/test_pydoc.py:431: ("", "PyDoc: Index of Modules"), I?m not sure ?PyDoc? is better than ?Python?. What about ?Python Doc?? Very clear and still short. http://codereview.appspot.com/4090042/ ---------- messages: 126765 nosy: eric.araujo priority: normal severity: normal status: open title: #10961: Pydoc touchups in new 3.2 Web server (issue4090042) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 21 20:01:49 2011 From: report at bugs.python.org (hhas) Date: Fri, 21 Jan 2011 19:01:49 +0000 Subject: [New-bugs-announce] [issue10976] json.loads() throws TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> New submission from hhas : json.loads() accepts strings but errors on bytes objects. Documentation and API indicate that both should work. Review of json/__init__.py code shows that the loads() function's 'encoding' arg is ignored and no decoding takes place before the object is passed to JSONDecoder.decode() Tested on Python 3.1.2 and Python 3.2rc1; fails on both. Example: ################################################# #!/usr/local/bin/python3.2 import json print(json.loads('123')) # 123 print(json.loads(b'123')) # /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/json/decoder.py:325: # TypeError: can't use a string pattern on a bytes-like object print(json.loads(b'123', encoding='utf-8')) # /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/json/decoder.py:325: # TypeError: can't use a string pattern on a bytes-like object ################################################# Patch attached. ---------- components: Library (Lib) files: json.diff keywords: patch messages: 126772 nosy: hhas priority: normal severity: normal status: open title: json.loads() throws TypeError on bytes object type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20481/json.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 22 00:49:39 2011 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 21 Jan 2011 23:49:39 +0000 Subject: [New-bugs-announce] [issue10977] Concrete object C API needs abstract path for subclasses of builtin types In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za> Message-ID: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za> New submission from Raymond Hettinger : Currently, the concrete object C API bypasses any methods defined on subclasses of builtin types. It has long been accepted that subclasses of builtin types need to override many methods rather than just a few because the type itself was implemented with direct internal calls. This work-around requires extra work but still makes it possible to create a consistent subclass (a case-insensitive dictionary for example). However, there is another problem with this workaround. Any subclassed builtin may still be bypassed by other functions and methods using the concrete C API. For example, the OrderedDict class overrides enough dict methods to make itself internally consistent and fully usable by all pure python code. However, any builtin or extension using PyDict_SetItem() or PyDict_DelItem() will update the OrderedDict's internal unordered dict and bypass all the logic keeping dict ordering invariants intact. Note, this problem would still impact OrderedDict even if it were rewritten in C. The concrete calls would directly access the original dict structure and ignore any of the logic implemented in the subclass (whether coded in pure python or in C). Since OrderedDict is written in pure python, the consequence of having its invariants violated would result in disorganization, but not in a crash. However if OrderedDict were rewritten in C, augmenting the inherited data structure with its own extra state, then this problem could result in seg-faulting. Note this is only one example. Pretty much any subclass of a builtin type that adds additional state is vulnerable to a concrete C API that updates only part of the state while leaving the extra state information in an inconsistent state. Another example would be a list subclass that kept extra state tracking the number of None objects contained within. There is no way to implement that subclass, either in C or pure python, even if every method were overridden, that wouldn't be rendered inconsistent by an external tool using PyList_SetItem(). My recommendation is to find all of the mutating methods for the concrete C API and add an alternate path for subclasses. The alternate path should use the abstract API. Pseudo-code for PyList_SetItem(): if type(obj) is list: # proceed as currently implemented else: # use PyObject_SetItem() adapting the # function parameters and return values if necessary # to match the API for PyList_SetItem(). else: raise BadInternalCall('object should be a list') ---------- components: Interpreter Core messages: 126800 nosy: rhettinger priority: normal severity: normal status: open title: Concrete object C API needs abstract path for subclasses of builtin types type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 22 01:15:36 2011 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 22 Jan 2011 00:15:36 +0000 Subject: [New-bugs-announce] [issue10978] Add optional argument to Semaphore.release for releasing multiple threads In-Reply-To: <1295655336.58.0.55708711889.issue10978@psf.upfronthosting.co.za> Message-ID: <1295655336.58.0.55708711889.issue10978@psf.upfronthosting.co.za> New submission from Raymond Hettinger : Call sem.release(5) would have the same effect as: with lock: for i in range(5): sem.release() The use case is when a single semaphore is holding up multiple threads and needs to release them all. According to "The Little Book of Semaphores ", this is a common design pattern. Basic patch attached. If the proposal meets with acceptance, will add tests and a doc update. ---------- components: Library (Lib) files: sem.diff keywords: patch messages: 126804 nosy: rhettinger priority: normal severity: normal status: open title: Add optional argument to Semaphore.release for releasing multiple threads type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file20483/sem.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 22 05:13:31 2011 From: report at bugs.python.org (Brandon Craig Rhodes) Date: Sat, 22 Jan 2011 04:13:31 +0000 Subject: [New-bugs-announce] [issue10979] setUpClass exception causes explosion with "-b" In-Reply-To: <1295669611.84.0.453494131357.issue10979@psf.upfronthosting.co.za> Message-ID: <1295669611.84.0.453494131357.issue10979@psf.upfronthosting.co.za> New submission from Brandon Craig Rhodes : Normally, unittest cleanly reports an exception in a setUpClass method. But if I place the attached test in a directory by itself and then run "python -m unittest discover -b" from inside of the same directory, then instead of being shown the setUpClass exception I am instead shown a long traceback because unittest seems to think that it has put a stringIO in place of sys.stdout but a file is there instead. ---------- components: Library (Lib) files: test_example.py messages: 126816 nosy: brandon-rhodes priority: normal severity: normal status: open title: setUpClass exception causes explosion with "-b" type: crash versions: Python 2.7 Added file: http://bugs.python.org/file20484/test_example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 22 13:45:54 2011 From: report at bugs.python.org (Armin Ronacher) Date: Sat, 22 Jan 2011 12:45:54 +0000 Subject: [New-bugs-announce] [issue10980] http.server Header Unicode Bug In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za> Message-ID: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za> New submission from Armin Ronacher : I have a critical bugfix that should make it into Python 3.2 even when it's in release candidate state. Currently http.server.BaseHTTPServer encodes headers with ASCII charset. This is at least in violation with PEP 3333 which demands that latin1 is used. Because HTTP itself suggests latin1 (iso-8859-1) I strongly recommend changing this in BaseHTTPServer and not wsgiref. The attached patch fixes that in a backwards compatible fashion. ---------- assignee: georg.brandl components: Library (Lib) files: http-server-unicode.patch keywords: patch messages: 126832 nosy: aronacher, georg.brandl priority: normal severity: normal stage: patch review status: open title: http.server Header Unicode Bug type: behavior Added file: http://bugs.python.org/file20486/http-server-unicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 22 13:49:12 2011 From: report at bugs.python.org (David Caro) Date: Sat, 22 Jan 2011 12:49:12 +0000 Subject: [New-bugs-announce] [issue10981] options starting with -- match substrings In-Reply-To: <1295700552.8.0.933174530734.issue10981@psf.upfronthosting.co.za> Message-ID: <1295700552.8.0.933174530734.issue10981@psf.upfronthosting.co.za> New submission from David Caro : When parsing option like --optionname, --option will match it too example: >>> import argparse >>> parser = argparse.ArgumentParser() >>> parser = argparse.ArgumentParser() >>> parser.add_argument('--superstring') _StoreAction(option_strings=['--superstring'], dest='superstring', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None) >>> parser.parse_args(['--super','value']) Namespace(superstring='value') I'm using argparse 1.1 with python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39), on ubuntu 10.10 32bit ---------- messages: 126833 nosy: David.Caro priority: normal severity: normal status: open title: options starting with -- match substrings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 22 19:03:06 2011 From: report at bugs.python.org (k1h) Date: Sat, 22 Jan 2011 18:03:06 +0000 Subject: [New-bugs-announce] [issue10982] asyncore timeouts do not work correctly In-Reply-To: <1295719386.38.0.705218895334.issue10982@psf.upfronthosting.co.za> Message-ID: <1295719386.38.0.705218895334.issue10982@psf.upfronthosting.co.za> New submission from k1h : Asyncore for the versions of Python examined do not check for the empty sequences select.select returns to indicate a timeout. The attached patch served my immediate needs, but no effort was made to verify that all scenarios were covered or that other issues weren't introduced. ---------- components: Library (Lib) files: asyncore_timeout_patch_with_example.txt messages: 126846 nosy: k1h priority: normal severity: normal status: open title: asyncore timeouts do not work correctly versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20487/asyncore_timeout_patch_with_example.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 22 22:49:21 2011 From: report at bugs.python.org (nooB) Date: Sat, 22 Jan 2011 21:49:21 +0000 Subject: [New-bugs-announce] [issue10983] Errors in http.client.HTTPConnection class (python3) In-Reply-To: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za> Message-ID: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za> New submission from nooB : In python 3.x http.client.HTTPConnection class, I saw few problems. 1) `_tunnel_headers` not initialized in the __init__ method. This causes `set_tunnel` method to raise `AttributeError` when called without `headers` keyword argument. 2) In `_tunnel` method, `self._tunnel_headers.iteritems()` has been used instead of `self._tunnel_headers.items()`, which caused AttributeError. 3) In `_tunnel` method, the CONNECT request is incomplete and hangs. self.send(b'\r\n') is missing after sending the headers. ---------- messages: 126857 nosy: nooB priority: normal severity: normal status: open title: Errors in http.client.HTTPConnection class (python3) versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 23 00:02:00 2011 From: report at bugs.python.org (Chris Lasher) Date: Sat, 22 Jan 2011 23:02:00 +0000 Subject: [New-bugs-announce] [issue10984] argparse add_mutually_exclusive_group should accept existing arguments to register conflicts In-Reply-To: <1295737320.83.0.942830837874.issue10984@psf.upfronthosting.co.za> Message-ID: <1295737320.83.0.942830837874.issue10984@psf.upfronthosting.co.za> New submission from Chris Lasher : argparse supports registering conflicting arguments, however, it does so in a way that an argument may belong to at most one group of conflicting arguments. The inspiration for this bug is Stack Overflow question #4770576. http://stackoverflow.com/questions/4770576/does-argparse-python-support-mutually-exclusive-groups-of-arguments The most straightforward use case argparse can not accommodate is the following: the user has three flags, '-a', '-b', and '-c'. The flag '-b' is incompatible with both '-a' and with '-c', however, '-a' and '-c' are compatible with each other. Current practice is to register a conflict by first defining a conflict group with parser.add_mutually_exclusive_group(), and then create new arguments within that group using group.add_argument(). Because the programmer is not allowed to create the argument prior to creating the group, an argument cannot be registered in two exclusive groups. I feel it would be much more useful to be given the option to create exclusive groups after the programmer has defined and created the options, as is the design for ConflictsOptionParser http://pypi.python.org/pypi/ConflictsOptionParser/ ---------- components: Library (Lib) messages: 126862 nosy: gotgenes priority: normal severity: normal status: open title: argparse add_mutually_exclusive_group should accept existing arguments to register conflicts type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 23 01:18:09 2011 From: report at bugs.python.org (Brett Cannon) Date: Sun, 23 Jan 2011 00:18:09 +0000 Subject: [New-bugs-announce] [issue10985] test_sys triggers a fatal python error when run under coverage.py In-Reply-To: <1295741889.19.0.432522991902.issue10985@psf.upfronthosting.co.za> Message-ID: <1295741889.19.0.432522991902.issue10985@psf.upfronthosting.co.za> New submission from Brett Cannon : If you run test_sys under coverage.py with ``./python.exe -m coverage run --pylib Lib/test/regrtest.py test_sys`` you get:: Fatal Python error: Cannot recover from stack overflow Have not taken the time to try to figure out exactly what code is triggering the recursion, but coverage.py is being used w/o its extension coverage support. Could be caused by coverage.py, but I'm a bit surprised that it's a fatal error instead of a recursion limit exception. ---------- messages: 126865 nosy: brett.cannon priority: normal severity: normal stage: unit test needed status: open title: test_sys triggers a fatal python error when run under coverage.py type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 23 03:47:00 2011 From: report at bugs.python.org (Benjamin VENELLE) Date: Sun, 23 Jan 2011 02:47:00 +0000 Subject: [New-bugs-announce] [issue10986] traceback's rendering behavior while throwing custom exception In-Reply-To: <1295750820.31.0.636288532577.issue10986@psf.upfronthosting.co.za> Message-ID: <1295750820.31.0.636288532577.issue10986@psf.upfronthosting.co.za> New submission from Benjamin VENELLE : Hi, >From few days, I've acknowledge when throwing an exception, the last traceback entry is always related to the raise statement. This is ok when the exception takes source from a non fail-safe code. But when an exception is raised due to a function's inputs sanity check (like an assertion error) the last traceback entry is non-sense. I've done a script to spot this behavior. Is there a way to prevent last traceback rendering (not suppressing) while exception is displayed without explicit call to traceback.print_exception ? If not, it would be useful to have a boolean declared in Exception's classes which will allow last traceback entry rendering or not. ---------- components: Interpreter Core files: traceback_rendering.py messages: 126871 nosy: Kain94 priority: normal severity: normal status: open title: traceback's rendering behavior while throwing custom exception type: feature request versions: Python 3.1 Added file: http://bugs.python.org/file20488/traceback_rendering.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 23 07:06:10 2011 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 23 Jan 2011 06:06:10 +0000 Subject: [New-bugs-announce] [issue10987] Bizarre pickle -- exception interaction bug In-Reply-To: <1295762770.11.0.0669999171717.issue10987@psf.upfronthosting.co.za> Message-ID: <1295762770.11.0.0669999171717.issue10987@psf.upfronthosting.co.za> New submission from Terry J. Reedy : Tool/scripts/find_recursionlimit.py includes test_cpickle() which, like the other test_xxx functions, is supposed to raise a RuntimeError when the recursion limit is reached. It appears to work correctly on 3.1 and I presume previously. On 3.2, test_cpickle() hangs. Here is much reduced code that shows the behavior: import itertools import io import _pickle # extracted from 'def test_cpickle' and condensed: l = None for n in itertools.count(): try: raise KeyError except KeyError: for i in range(100): l = [l] print(n,i) _pickle.Pickler(io.BytesIO(), protocol=-1).dump(l) The added print line prints 0,99 1,99, ... indefinitely. If the recursive list l is added to the print function, the attempt to create repr(l) raises a runtime error at n = 9. If we remove the try-except part: l = None for n in itertools.count(): for i in range(100): l = [l] print(n,i) _pickle.Pickler(io.BytesIO(), protocol=-1).dump(l) *pickle* now raises a RuntimeError, as expected in the original context, at n=4! 1. I do not actually know which behavior is buggy. I suppose the next step would be to capture and not toss the pickle output to see what is the difference. 2. At least for the present, I think the call to test_cpickle should be commented out in find_recursionlimit.py. There seems to be other pickle and recursive structure issues, like #9269, but I did not see any the same as this. ---------- files: frl_pickle1.py messages: 126874 nosy: belopolsky, pitrou, terry.reedy priority: normal severity: normal status: open title: Bizarre pickle -- exception interaction bug type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file20489/frl_pickle1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 23 19:38:05 2011 From: report at bugs.python.org (Joshua Arnold) Date: Sun, 23 Jan 2011 18:38:05 +0000 Subject: [New-bugs-announce] [issue10988] Descriptor protocol documentation for super bindings is incorrect In-Reply-To: <1295807885.2.0.206629380861.issue10988@psf.upfronthosting.co.za> Message-ID: <1295807885.2.0.206629380861.issue10988@psf.upfronthosting.co.za> New submission from Joshua Arnold : In 'Doc/reference/datamodel.rst', the 'Invoking Descriptors' documentation specifies the following behavior for super objects: [snip] Super Binding If ``a`` is an instance of :class:`super`, then the binding ``super(B, obj).m()`` searches ``obj.__class__.__mro__`` for the base class ``A`` immediately preceding ``B`` and then invokes the descriptor with the call: ``A.__dict__['m'].__get__(obj, A)``. [snip] In the above paragrah, the call: A.__dict__['m'].__get__(obj, A) is incorrect. In reality, the descriptor is invoked via: A.__dict__['m'].__get__(obj, obj.__class__) Loosely speaking, the 'owner' argument is set to the subclass associated with the super object, not the superclass. There is a similar error in the 'Descriptor HowTo Guide' under 'Invoking Descriptors' (Strictly speaking, the specification is inaccurate on some other points. It assumes obj is not a class and doesn't state that the entire mro preceding 'B' is searched for 'm'. But those may be considered simplifications for the sake of brevity) I considered reporting this as a bug in the implementation rather than the specification. But I think the implementation's algorithm is the correct one. In particular, it yields the desired behavior for classmethods In any case, the current behavior has been around for a while (it was the fix for issue #535444, dating back to 2.2) Code demonstrating the current behavior: class Desc(object): def __get__(self, instance, owner): return owner class A(object): attr = Desc() class B(A): pass class C(B): pass instance = C() assert super(B,instance).attr == C assert super(B,C).attr == C #According to the specification, the assertions should be: #assert super(B,instance).attr == A #assert super(B,C).attr == A ---------- assignee: docs at python components: Documentation messages: 126895 nosy: Joshua.Arnold, docs at python priority: normal severity: normal status: open title: Descriptor protocol documentation for super bindings is incorrect versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 23 23:02:05 2011 From: report at bugs.python.org (STINNER Victor) Date: Sun, 23 Jan 2011 22:02:05 +0000 Subject: [New-bugs-announce] [issue10989] ssl.SSLContext(True).load_verify_locations(None, True) segfault In-Reply-To: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za> Message-ID: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za> New submission from STINNER Victor : ssl.SSLContext(True).load_verify_locations(None, True) does segfault. Py_DECREF(cafile_bytes) in Modules/_ssl.c:1686 should be replaced by Py_XDECREF(cafile_bytes). ---------- components: Library (Lib) messages: 126901 nosy: haypo, pitrou priority: normal severity: normal status: open title: ssl.SSLContext(True).load_verify_locations(None, True) segfault versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 00:21:16 2011 From: report at bugs.python.org (Brett Cannon) Date: Sun, 23 Jan 2011 23:21:16 +0000 Subject: [New-bugs-announce] [issue10990] tests mutating sys.gettrace() w/o re-instating previous state In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za> Message-ID: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za> New submission from Brett Cannon : The attached patch adds resource monitoring to test.regrtest to detect which tests are changing the trace function w/o putting back to what it was previously. The tests listed below are thus all being naughty. This is a meta-issue to help track which tests need to be changed to stop this behavior. test_doctest test_exceptions test_io test_pdb test_pickle test_pickletools test_richcmp test_runpy test_scope test_sys_settrace test_zipimport_support ---------- components: Tests files: sys_gettrace_monitor.diff keywords: patch messages: 126908 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: tests mutating sys.gettrace() w/o re-instating previous state type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20498/sys_gettrace_monitor.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 00:31:12 2011 From: report at bugs.python.org (Brett Cannon) Date: Sun, 23 Jan 2011 23:31:12 +0000 Subject: [New-bugs-announce] [issue10991] trace fails when test imported a temporary file In-Reply-To: <1295825472.67.0.685273364418.issue10991@psf.upfronthosting.co.za> Message-ID: <1295825472.67.0.685273364418.issue10991@psf.upfronthosting.co.za> New submission from Brett Cannon : If you run ``test.regrtest -T`` you will discover that (at least) test_importlib and test_runpy prevent coverage data from being written out as 'trace' will try to find files which no longer exist. Both test suites create temp files, import them, and then delete them. Unfortunately 'trace' doesn't ignore that fact and throws an exception that the temporary files are gone. Since the file is simply gone it probably makes sense to have 'trace' just print out a warning that the file could not be found and move on. ---------- components: Library (Lib) messages: 126909 nosy: brett.cannon priority: normal severity: normal stage: unit test needed status: open title: trace fails when test imported a temporary file type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 03:27:06 2011 From: report at bugs.python.org (Brett Cannon) Date: Mon, 24 Jan 2011 02:27:06 +0000 Subject: [New-bugs-announce] [issue10992] tests failing when run under coverage In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za> Message-ID: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za> New submission from Brett Cannon : A bunch of tests fail when run under coverage (trend seems to be refcount tests). This is to act as a meta-issue to keep track of what tests need to be fixed. [fail under both coverage.py and regrtest -T] test_ctypes test_descr test_gc test_metaclass test_pydoc test_trace [coverage.py only] test_genexps test_sys [regrtest -T only] test_array test_importlib test_runpy ---------- components: Tests messages: 126913 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: tests failing when run under coverage type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 11:51:43 2011 From: report at bugs.python.org (Tanakorn Leesatapornwongsa) Date: Mon, 24 Jan 2011 10:51:43 +0000 Subject: [New-bugs-announce] [issue10993] HTTPSConnection does not close when call close() method In-Reply-To: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za> Message-ID: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za> New submission from Tanakorn Leesatapornwongsa : With this code on python 2.6, I found that HTTPSConnection does not close connection properly. from httplib import HTTPSConnection for i in range(1000): https = HTTPSConnection("google.com") https.connect() https.request("GET", "/") response = https.getresponse() response.close() https.close() print i After searching python library, I guess that in ssl.py, implementation of close() method of SSLSocket is wrong. socket.close(self) should not be called when self._makefile_refs < 1 but should be call when self._makefile_refs == 1, isn't it? I modified the code, made the patch and attached it with this issue. ---------- components: Library (Lib) files: ssl.py.patch keywords: patch messages: 126919 nosy: tanakorn priority: normal severity: normal status: open title: HTTPSConnection does not close when call close() method type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file20501/ssl.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 14:43:40 2011 From: report at bugs.python.org (Maciej Fijalkowski) Date: Mon, 24 Jan 2011 13:43:40 +0000 Subject: [New-bugs-announce] [issue10994] implementation details in sys module In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za> Message-ID: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za> New submission from Maciej Fijalkowski : sys module documentation (as it is online) has some things that in my opinion should be marked as implementation details, but are not. Feel free to counter why not. Some of them has info it should be used for specialized purposes only, but IMO it's not the same as not mandatory for other implementations. Temporary list: _clear_type_cache dllhandle getrefcount getdlopenflags (?) getsizeof - it might be not well defined on other implementations setdlopenflags api_version ---------- assignee: docs at python components: Documentation messages: 126925 nosy: docs at python, fijall priority: normal severity: normal status: open title: implementation details in sys module type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 15:23:46 2011 From: report at bugs.python.org (Steffen Daode Nurpmeso) Date: Mon, 24 Jan 2011 14:23:46 +0000 Subject: [New-bugs-announce] [issue10995] mailbox.py open() calls don't set encoding In-Reply-To: <1295879026.46.0.299345130238.issue10995@psf.upfronthosting.co.za> Message-ID: <1295879026.46.0.299345130238.issue10995@psf.upfronthosting.co.za> New submission from Steffen Daode Nurpmeso : I'm using the en_GB.UTF-8 locale and thus the entire I/O layer defaults to use UTF-8 encoding. Perfect. The problem is that mailboxes are *not* and *never* in UTF-8, generally speaking, according to RFC mail standards! So i suggest that mailbox.py either offers additional 'encoding="latin1"' constructor arguments or always uses "latin1" in open() calls. This suffices to make mailbox.py usable - i.e., the mailbox will be loaded/saved without causing encoder errors, and email.py will behave correctly according to message *content* anyway! P.S.: i am far from being a Python(1) freak and feel a bit lost on *.python.org, so i might have blown the wrong whistles too load. Sorry, if this is the case. Thanks for python(1), it's damn slow and i love C and Perl. ;-) ---------- components: Library (Lib) messages: 126930 nosy: Steffen.Daode.Nurpmeso priority: normal severity: normal status: open title: mailbox.py open() calls don't set encoding type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 18:50:59 2011 From: report at bugs.python.org (Daniel Urban) Date: Mon, 24 Jan 2011 17:50:59 +0000 Subject: [New-bugs-announce] [issue10996] Typo in What's New in 3.2 In-Reply-To: <1295891459.95.0.208045787052.issue10996@psf.upfronthosting.co.za> Message-ID: <1295891459.95.0.208045787052.issue10996@psf.upfronthosting.co.za> New submission from Daniel Urban : In http://docs.python.org/dev/py3k/whatsnew/3.2.html#abc the example has two typos: farenheit -> fahrenheit celsium -> celsius ---------- assignee: docs at python components: Documentation messages: 126938 nosy: docs at python, durban priority: normal severity: normal status: open title: Typo in What's New in 3.2 type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 19:35:16 2011 From: report at bugs.python.org (Ned Deily) Date: Mon, 24 Jan 2011 18:35:16 +0000 Subject: [New-bugs-announce] [issue10997] Duplicate entries in IDLE "Recent Files" menu item on OS X In-Reply-To: <1295894116.03.0.647571188002.issue10997@psf.upfronthosting.co.za> Message-ID: <1295894116.03.0.647571188002.issue10997@psf.upfronthosting.co.za> New submission from Ned Deily : When IDLE is run with an OS X Aqua Tk (Carbon 8.4 or Cocoa 8.5), using the File -> Recent Files menu item to open a previously used file causes that file to show up a second time in the updated menu item and with the same keyboard shortcut. With X11-based Tk on OS X, no duplicate is seen. The problem stems from a difference in the way the Tk versions generate sub menus. With the X11 Tk the sub menu appears to start with a separator in menu index 0 and the first file is added in index 1. With Aqua Tk, there is no separator and the first file is in index 0. The code in IDLE to update the menu deletes from 1 to END so, with Aqua Tk, the file name inserted into index 0 is not removed. The attached patch fixes the problem with Aqua Tk and appears to cause no problems with a current X11 Tk 8.5 on OS X. Before committing it, though, it should be tested on Windows, which I'm not currently set up to do. ---------- assignee: ned.deily files: issue_idle_dup_recent.patch keywords: patch messages: 126941 nosy: ned.deily priority: normal severity: normal status: open title: Duplicate entries in IDLE "Recent Files" menu item on OS X type: behavior versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20504/issue_idle_dup_recent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 20:25:50 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 24 Jan 2011 19:25:50 +0000 Subject: [New-bugs-announce] [issue10998] Remove last traces of -Q / sys.flags.division_warning / Py_DivisionWarningFlag In-Reply-To: <1295897150.32.0.288530737397.issue10998@psf.upfronthosting.co.za> Message-ID: <1295897150.32.0.288530737397.issue10998@psf.upfronthosting.co.za> New submission from ?ric Araujo : The -Q command-line option has been removed in Python 3 but there are some leftovers. Attached patch removes them; tests pass; please review. I think 3.1 should be fixed too, since no sane program should use those leftovers. I removed the now-pointless tests in test_cmd_line. They were not failing; this may be a bug in verify_valid_flag, out of scope for this report. While I was editing the table used to document sys.flags, I added some link-generating markup (to the respective option doc) and made the table markup easier to read and edit. I can make those changes in another commit if you prefer it. ---------- assignee: eric.araujo components: Interpreter Core files: division_warning.diff keywords: needs review, patch messages: 126943 nosy: benjamin.peterson, eric.araujo, georg.brandl priority: normal severity: normal stage: commit review status: open title: Remove last traces of -Q / sys.flags.division_warning / Py_DivisionWarningFlag type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20505/division_warning.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 20:41:15 2011 From: report at bugs.python.org (R. David Murray) Date: Mon, 24 Jan 2011 19:41:15 +0000 Subject: [New-bugs-announce] [issue10999] os.chflags refers to stat constants, but the constants are not documented in the stat module In-Reply-To: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za> Message-ID: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za> New submission from R. David Murray : Title pretty much says it all. The constants are there in the stat module, but they aren't documented. When they are documented the mentions in the os.chflags entry can be turned into cross reference links. ---------- assignee: docs at python messages: 126947 nosy: docs at python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: os.chflags refers to stat constants, but the constants are not documented in the stat module type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 21:07:58 2011 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 24 Jan 2011 20:07:58 +0000 Subject: [New-bugs-announce] [issue11000] Doc: ast.parse parses source, not just expressions In-Reply-To: <1295899678.27.0.449949701251.issue11000@psf.upfronthosting.co.za> Message-ID: <1295899678.27.0.449949701251.issue11000@psf.upfronthosting.co.za> New submission from Terry J. Reedy : "ast.parse(expr, filename='', mode='exec') Parse an expression into an AST node. Equivalent to compile(expr, filename, mode, ast.PyCF_ONLY_AST)." but "compile(source, ...) Compile the source into a code or AST object. ... The mode argument specifies what kind of code must be compiled; it can be 'exec' if source consists of a sequence of statements," and indeed, with all three versions, >>> import ast >>> e3=ast.parse('x=1; y=2\nif x: print(y)') >>> o3 = compile(e3,'','exec') >>> exec(o3) 2 >>> print(x,y) (1, 2) Attached patch (untested) changes doc and doc string. Inquiry: I suspect that the filename is *not* attached to the ast. (In any case, it must be explicitly supplied to a subsequent compile() call.) If so, it is a useless parameter and the api and doc should be parse(source, mode) ... Equivalent to compile(source, '', ... If so, and failing such a change, should the doc warn people to not bother supplying a filename arg? I also wonder whether the mode arg has any effect on the ast. If not, same question. ---------- assignee: docs at python components: Documentation files: zast.diff keywords: patch messages: 126952 nosy: docs at python, georg.brandl, terry.reedy priority: normal severity: normal status: open title: Doc: ast.parse parses source, not just expressions versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20506/zast.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 24 23:27:45 2011 From: report at bugs.python.org (Luke Plant) Date: Mon, 24 Jan 2011 22:27:45 +0000 Subject: [New-bugs-announce] [issue11001] Various obvious errors in cookies documentation In-Reply-To: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za> Message-ID: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za> New submission from Luke Plant : Docs for SimpleCookie, BaseCookie.value_encode and BaseCookie.value_decode are obviously incorrect. Attempt at patch attached. The error has existed in every Python version I've seen, I've tagged the ones I believe can receive fixes, sorry if I've made a mistake. Thanks. ---------- assignee: docs at python components: Documentation files: http_cookies_doc_corrections.diff keywords: patch messages: 126962 nosy: docs at python, spookylukey priority: normal severity: normal status: open title: Various obvious errors in cookies documentation versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20507/http_cookies_doc_corrections.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 25 05:44:24 2011 From: report at bugs.python.org (Anthony Long) Date: Tue, 25 Jan 2011 04:44:24 +0000 Subject: [New-bugs-announce] [issue11002] 'Upload' link on Files page is broken In-Reply-To: <1295930664.52.0.312765274224.issue11002@psf.upfronthosting.co.za> Message-ID: <1295930664.52.0.312765274224.issue11002@psf.upfronthosting.co.za> New submission from Anthony Long : On pypi, when you are inside of your packages' files area, the link that is attached to 1. Use the setup.py "upload" command. # "upload" is broken, it links to http://www.python.org/doc/dist/package-upload.html which returns a 404. http://d.pr/mmie ---------- assignee: docs at python components: Documentation messages: 126988 nosy: antlong, docs at python priority: normal severity: normal status: open title: 'Upload' link on Files page is broken type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 25 11:41:56 2011 From: report at bugs.python.org (Jakob Bowyer) Date: Tue, 25 Jan 2011 10:41:56 +0000 Subject: [New-bugs-announce] [issue11003] os.system should be deprecated in favour of subprocess module In-Reply-To: <1295952116.86.0.340970955055.issue11003@psf.upfronthosting.co.za> Message-ID: <1295952116.86.0.340970955055.issue11003@psf.upfronthosting.co.za> New submission from Jakob Bowyer : os.system is broken in several fundamental ways. We already have the subprocess module for accessing other processes, lets send os.system the same way as os.Popen. ---------- components: Library (Lib) messages: 126995 nosy: Jakob.Bowyer priority: normal severity: normal status: open title: os.system should be deprecated in favour of subprocess module type: feature request versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 25 13:36:09 2011 From: report at bugs.python.org (STINNER Victor) Date: Tue, 25 Jan 2011 12:36:09 +0000 Subject: [New-bugs-announce] [issue11004] AssertionError on collections.deque().count(1) In-Reply-To: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za> Message-ID: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za> New submission from STINNER Victor : Attached script, bug.py, ends with: $ python3.2 source2.py deque.remove(x): x not in deque python: ./Modules/_collectionsmodule.c:536: deque_count: Assertion `leftblock->rightlink != ((void *)0)' failed. Abandon (core dumped) ---------- components: Library (Lib) files: bug.py messages: 127001 nosy: haypo priority: normal severity: normal status: open title: AssertionError on collections.deque().count(1) type: crash versions: Python 3.2 Added file: http://bugs.python.org/file20512/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 25 13:44:28 2011 From: report at bugs.python.org (STINNER Victor) Date: Tue, 25 Jan 2011 12:44:28 +0000 Subject: [New-bugs-announce] [issue11005] Assertion error on RLock._acquire_restore In-Reply-To: <1295959468.18.0.305168366567.issue11005@psf.upfronthosting.co.za> Message-ID: <1295959468.18.0.305168366567.issue11005@psf.upfronthosting.co.za> New submission from STINNER Victor : Attached script (bug2.py) ends with: $ ~/prog/SVN/py3k/python bug2.py python: ./Modules/_threadmodule.c:399: rlock_acquire_restore: Assertion `self->rlock_count == 0' failed. Abandon It should raise a classic Python exception, instead of stopping with a fatal assertion error. ---------- components: Library (Lib) files: bug2.py messages: 127004 nosy: haypo priority: normal severity: normal status: open title: Assertion error on RLock._acquire_restore versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file20513/bug2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 25 15:30:09 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Jan 2011 14:30:09 +0000 Subject: [New-bugs-announce] [issue11006] warnings with subprocess and pipe2 In-Reply-To: <1295965809.48.0.183733964181.issue11006@psf.upfronthosting.co.za> Message-ID: <1295965809.48.0.183733964181.issue11006@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Since r87651, subprocess can raise a RuntimeWarning if pipe2() fails. I'm not sure there's any point in that, since it's very low-level and it's nothing the user can do about anyway. Ironically, there is no warning if pipe2() is not available at all. ---------- components: Library (Lib) messages: 127011 nosy: georg.brandl, gregory.p.smith, pitrou priority: normal severity: normal status: open title: warnings with subprocess and pipe2 type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 25 16:12:25 2011 From: report at bugs.python.org (Joshua Blount) Date: Tue, 25 Jan 2011 15:12:25 +0000 Subject: [New-bugs-announce] [issue11007] stack tracebacks should give the relevant class name In-Reply-To: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za> Message-ID: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za> New submission from Joshua Blount : When I get a stack traceback, it would be very handy if the traceback gave me the relevant class name (along with all the current information). ---------- components: Interpreter Core messages: 127015 nosy: stickwithjosh priority: normal severity: normal status: open title: stack tracebacks should give the relevant class name type: feature request versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 25 18:18:34 2011 From: report at bugs.python.org (Day Barr) Date: Tue, 25 Jan 2011 17:18:34 +0000 Subject: [New-bugs-announce] [issue11008] logging.dictConfig not documented as new in version 2.7 In-Reply-To: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za> Message-ID: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za> New submission from Day Barr : logging.dictConfig is new in version 2.7 but the documentation does not say this. http://docs.python.org/release/2.7/library/logging.html#logging.dictConfig c.f. NullHandler, also new in version 2.7 and explicitly documented as such: http://docs.python.org/release/2.7/library/logging.html#nullhandler ---------- assignee: docs at python components: Documentation messages: 127024 nosy: daybarr, docs at python priority: normal severity: normal status: open title: logging.dictConfig not documented as new in version 2.7 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 25 21:24:38 2011 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 25 Jan 2011 20:24:38 +0000 Subject: [New-bugs-announce] [issue11009] urllib.splituser is not documented In-Reply-To: <1295987078.02.0.421774194417.issue11009@psf.upfronthosting.co.za> Message-ID: <1295987078.02.0.421774194417.issue11009@psf.upfronthosting.co.za> New submission from anatoly techtonik : I'm studying old code that uses urllib.splituser() call and can't find description of this function in Python 2.6.6 docs. ---------- assignee: docs at python components: Documentation messages: 127047 nosy: docs at python, techtonik priority: normal severity: normal status: open title: urllib.splituser is not documented versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 25 22:25:59 2011 From: report at bugs.python.org (onpon4) Date: Tue, 25 Jan 2011 21:25:59 +0000 Subject: [New-bugs-announce] [issue11010] Unicode BOM left in loaded text In-Reply-To: <1295990759.68.0.350940217236.issue11010@psf.upfronthosting.co.za> Message-ID: <1295990759.68.0.350940217236.issue11010@psf.upfronthosting.co.za> New submission from onpon4 : This is for Python 2.7.1. It isn't an issue on 2.6.5 and I haven't tested it on 3.1. Quite simply, the Unicode BOM (unichr(65279)) is included in the text loaded from a UTF-8 text file. This can cause issues in some cases, but is easily worked around by calling "s.strip(unichr(65279))" on the first line of loaded text. ---------- components: IO, Unicode messages: 127055 nosy: onpon4 priority: normal severity: normal status: open title: Unicode BOM left in loaded text type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 25 23:32:22 2011 From: report at bugs.python.org (Jason Baker) Date: Tue, 25 Jan 2011 22:32:22 +0000 Subject: [New-bugs-announce] [issue11011] More functools functions In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za> Message-ID: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za> New submission from Jason Baker : I've created a patch that adds some common functional programming tools to functools. I've made the patch to work against Python 3.2, but that may be a bit aggressive. If so, then I can adapt it to work with 3.3. I also wouldn't be opposed to writing some of these in C if there's a performance need. The functions I added are: * flip - flip the first two arguments of a function * const - return a function that always returns the same thing * compose - compose multiple functions together * identity - returns what is passed in to it * trampoline - calls a function and then calls any returned functions. ---------- components: Library (Lib) files: functools.patch keywords: patch messages: 127062 nosy: Jason.Baker priority: normal severity: normal status: open title: More functools functions versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20520/functools.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 26 00:25:01 2011 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 25 Jan 2011 23:25:01 +0000 Subject: [New-bugs-announce] [issue11012] Add log1p(), exp1m(), gamma(), and lgamma() to cmath In-Reply-To: <1295997901.71.0.113497713942.issue11012@psf.upfronthosting.co.za> Message-ID: <1295997901.71.0.113497713942.issue11012@psf.upfronthosting.co.za> New submission from Raymond Hettinger : Where it makes sense, cmath needs to stay in-sync with the math module as much as possible: >>> set(dir(math)) - set(dir(cmath)) {'pow', 'fsum', 'ldexp', 'hypot', 'fabs', 'floor', 'lgamma', 'frexp', 'degrees', 'modf', 'factorial', 'copysign', 'ceil', 'trunc', 'expm1', 'radians', 'atan2', 'erf', 'erfc', 'fmod', 'log1p', 'gamma'} At some point, it may make sense to implement cmath.fsum() along the lines of: c_fsum = lambda iterable: complex(*map(fsum, zip(*((z.real, z.imag) for z in iterable)))) ---------- assignee: mark.dickinson components: Extension Modules messages: 127070 nosy: mark.dickinson, rhettinger priority: normal severity: normal stage: needs patch status: open title: Add log1p(), exp1m(), gamma(), and lgamma() to cmath type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 26 03:10:32 2011 From: report at bugs.python.org (Geoge R. Goffe) Date: Wed, 26 Jan 2011 02:10:32 +0000 Subject: [New-bugs-announce] [issue11013] Build of CVS version 2.7 fails in readline In-Reply-To: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za> Message-ID: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za> New submission from Geoge R. Goffe : Howdy, I just updated my copy of the SVN version of 2.7 and got the following error messages. Did I do something wrong? Regards, George... building dbm using bdb building 'readline' extension gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -I/usr/lsd/Linux/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/google/tools/python/release27-maint/Include -I/usr/local/google/tools/python/release27-maint -c /usr/local/google/tools/python/release27-maint/Modules/readline.c -o build/temp.linux-x86_64-2.7-pydebug/usr/local/google/tools/python/release27-maint/Modules/readline.o /usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?write_history_file?: /usr/local/google/tools/python/release27-maint/Modules/readline.c:147: warning: implicit declaration of function ?history_truncate_file? /usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?_py_free_history_entry?: /usr/local/google/tools/python/release27-maint/Modules/readline.c:385: warning: passing argument 1 of ?free? discards qualifiers from pointer target type /usr/include/stdlib.h:488: note: expected ?void *? but argument is of type ?const char *? /usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?py_replace_history?: /usr/local/google/tools/python/release27-maint/Modules/readline.c:436: warning: implicit declaration of function ?replace_history_entry? /usr/local/google/tools/python/release27-maint/Modules/readline.c:436: warning: assignment makes pointer from integer without a cast /usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?_py_get_history_length?: /usr/local/google/tools/python/release27-maint/Modules/readline.c:523: error: ?HISTORY_STATE? undeclared (first use in this function) /usr/local/google/tools/python/release27-maint/Modules/readline.c:523: error: (Each undeclared identifier is reported only once /usr/local/google/tools/python/release27-maint/Modules/readline.c:523: error: for each function it appears in.) /usr/local/google/tools/python/release27-maint/Modules/readline.c:523: error: ?hist_st? undeclared (first use in this function) /usr/local/google/tools/python/release27-maint/Modules/readline.c:523: warning: implicit declaration of function ?history_get_history_state? /usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?insert_text?: /usr/local/google/tools/python/release27-maint/Modules/readline.c:628: warning: implicit declaration of function ?rl_insert_text? /usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?flex_complete?: /usr/local/google/tools/python/release27-maint/Modules/readline.c:847: error: ?rl_completion_suppress_append? undeclared (first use in this function) /usr/local/google/tools/python/release27-maint/Modules/readline.c:853: warning: implicit declaration of function ?rl_completion_matches? /usr/local/google/tools/python/release27-maint/Modules/readline.c:853: error: ?rl_compentry_func_t? undeclared (first use in this function) /usr/local/google/tools/python/release27-maint/Modules/readline.c:853: error: expected expression before ?)? token /usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?setup_readline?: /usr/local/google/tools/python/release27-maint/Modules/readline.c:886: warning: passing argument 2 of ?rl_bind_key_in_map? from incompatible pointer type /usr/lsd/Linux/include/readline/readline.h:195: note: expected ?int (*)(const char *, int)? but argument is of type ?int (*)(int, int)? /usr/local/google/tools/python/release27-maint/Modules/readline.c:887: warning: passing argument 2 of ?rl_bind_key_in_map? from incompatible pointer type /usr/lsd/Linux/include/readline/readline.h:195: note: expected ?int (*)(const char *, int)? but argument is of type ?int (*)(int, int)? /usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?readline_until_enter_or_signal?: /usr/local/google/tools/python/release27-maint/Modules/readline.c:940: error: ?rl_catch_signals? undeclared (first use in this function) /usr/local/google/tools/python/release27-maint/Modules/readline.c:979: warning: implicit declaration of function ?rl_free_line_state? /usr/local/google/tools/python/release27-maint/Modules/readline.c:980: warning: implicit declaration of function ?rl_cleanup_after_signal? Python build finished, but the necessary bits to build these modules were not found: bsddb185 dl gdbm imageop sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: readline ---------- components: Build messages: 127080 nosy: grgoffe at yahoo.com priority: normal severity: normal status: open title: Build of CVS version 2.7 fails in readline type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 26 03:27:25 2011 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 26 Jan 2011 02:27:25 +0000 Subject: [New-bugs-announce] [issue11014] 'filter' argument for Tarfile.add needs to be a keyword-only argument In-Reply-To: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za> Message-ID: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za> New submission from Raymond Hettinger : In 3.2, tarfile.Tarfile added a 'filter' argument while deprecating the 'exclude' argument that precedes it positionally. The 'filter' argument needs to be keyword-only argument, or any code that uses it positionally will fail when the 'exclude' argument is ultimately removed. ---------- assignee: georg.brandl components: Library (Lib) files: tarfile.patch keywords: patch messages: 127083 nosy: georg.brandl, rhettinger priority: high severity: normal stage: patch review status: open title: 'filter' argument for Tarfile.add needs to be a keyword-only argument type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file20524/tarfile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 26 03:46:09 2011 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 26 Jan 2011 02:46:09 +0000 Subject: [New-bugs-announce] [issue11015] Bring test.support docs up to date In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za> Message-ID: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za> New submission from Nick Coghlan : The test.support docs are there to help CPython devs with writing good unit tests more easily. There are a few additions we've made in recent years that haven't made it into the .rst file, so it is easy to miss useful tools if you don't go looking through the module source code. There are some other helper modules (such as test.script_helper) that could also stand to be made easier to find. Fixing this is just a matter of doing a pass through test.support and the test directory looking for things that might be worth mentioning in the test package docs. ---------- assignee: docs at python keywords: easy messages: 127086 nosy: docs at python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Bring test.support docs up to date type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 26 11:57:26 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 26 Jan 2011 10:57:26 +0000 Subject: [New-bugs-announce] [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Solaris has an additional kind of special files named doors. The standard headers define the following macro: #define S_ISDOOR(mode) (((mode)&0xF000) == 0xd000) Perhaps it would be nice to include the equivalent in the stat module. (although funnily even the "stat" command doesn't recognize them and displayed "weird file" instead: $ stat /var/run/syslog_door File: `/var/run/syslog_door' Size: 0 Blocks: 0 IO Block: 0 weird file Device: 8bc0000h/146538496d Inode: 44 Links: 1 Access: (0644/Drw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2011-01-26 11:52:34.332492612 +0100 Modify: 2011-01-26 11:52:34.332492612 +0100 Change: 2011-01-26 11:52:34.332499428 +0100 ) ---------- components: Library (Lib) messages: 127100 nosy: jcea, loewis, movement, pitrou priority: normal severity: normal status: open title: Add S_ISDOOR to the stat module type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 26 13:29:24 2011 From: report at bugs.python.org (hensing) Date: Wed, 26 Jan 2011 12:29:24 +0000 Subject: [New-bugs-announce] [issue11017] optparse: error: invalid integer value In-Reply-To: <1296044964.44.0.826782436299.issue11017@psf.upfronthosting.co.za> Message-ID: <1296044964.44.0.826782436299.issue11017@psf.upfronthosting.co.za> New submission from hensing : OptionParser can't parse int "08" and "09". "8", "9" and "01..07" works. ---------- components: Library (Lib) files: minimal.py messages: 127106 nosy: hensing priority: normal severity: normal status: open title: optparse: error: invalid integer value type: crash versions: Python 2.6 Added file: http://bugs.python.org/file20531/minimal.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 26 14:36:59 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 26 Jan 2011 13:36:59 +0000 Subject: [New-bugs-announce] [issue11018] typo in test_bz2 In-Reply-To: <1296049019.27.0.765900313708.issue11018@psf.upfronthosting.co.za> Message-ID: <1296049019.27.0.765900313708.issue11018@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This was found by Nadeem in issue5863. Index: Lib/test/test_bz2.py =================================================================== --- Lib/test/test_bz2.py (r?vision 88199) +++ Lib/test/test_bz2.py (copie de travail) @@ -86,7 +86,7 @@ if not str: break text += str - self.assertEqual(text, text) + self.assertEqual(text, self.TEXT) def testRead100(self): # "Test BZ2File.read(100)" ---------- components: Tests messages: 127116 nosy: georg.brandl, pitrou priority: normal severity: normal stage: patch review status: open title: typo in test_bz2 type: behavior versions: Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 26 21:57:16 2011 From: report at bugs.python.org (R. David Murray) Date: Wed, 26 Jan 2011 20:57:16 +0000 Subject: [New-bugs-announce] [issue11019] BytesGenerator fails if the Message body is None In-Reply-To: <1296075436.52.0.0716312714806.issue11019@psf.upfronthosting.co.za> Message-ID: <1296075436.52.0.0716312714806.issue11019@psf.upfronthosting.co.za> New submission from R. David Murray : This was discovered by Haypo during work on #9124. I'll attach a patch with test shortly. ---------- assignee: r.david.murray messages: 127139 nosy: r.david.murray priority: high severity: normal stage: commit review status: open title: BytesGenerator fails if the Message body is None type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 00:29:00 2011 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 26 Jan 2011 23:29:00 +0000 Subject: [New-bugs-announce] [issue11020] Pyclbr broken because of missing 2-to-3 conversion In-Reply-To: <1296084540.01.0.814516700337.issue11020@psf.upfronthosting.co.za> Message-ID: <1296084540.01.0.814516700337.issue11020@psf.upfronthosting.co.za> New submission from Raymond Hettinger : The command line invocation of pyclbr failed because of a 2-to-3 error. The dict.values() call returns a dictview which doesn't support the sort() method. Invoke with: $ python -m pyclbr Lib/collections.py ---------- components: Library (Lib) messages: 127156 nosy: rhettinger priority: high severity: normal stage: patch review status: open title: Pyclbr broken because of missing 2-to-3 conversion type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 00:47:25 2011 From: report at bugs.python.org (David Caro) Date: Wed, 26 Jan 2011 23:47:25 +0000 Subject: [New-bugs-announce] [issue11021] email MIME-Version headers for each part in multipart message In-Reply-To: <1296085645.01.0.978524639714.issue11021@psf.upfronthosting.co.za> Message-ID: <1296085645.01.0.978524639714.issue11021@psf.upfronthosting.co.za> New submission from David Caro : When attaching a subpart to a multipart message, python should follow the recomendations of the rfcs and remove the MIME-Version header of each part, leaving only one MIME-Version header at the beggining of the message. >>> from email.mime.multipart import MIMEMultipart >>> from email.mime.text import MIMEText >>> usermail=MIMEMultipart('alternative') >>> part=MIMEText('text') >>> print part >From nobody Thu Jan 27 00:33:50 2011 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit text >>> usermail.attach(part) >>> print usermail >From nobody Thu Jan 27 00:45:26 2011 Content-Type: multipart/alternative; boundary="===============1006894803==" MIME-Version: 1.0 --===============1006894803== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit text --===============1006894803==-- ---------- components: Library (Lib) messages: 127161 nosy: david.caro priority: normal severity: normal status: open title: email MIME-Version headers for each part in multipart message type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 12:00:25 2011 From: report at bugs.python.org (Steffen Daode Nurpmeso) Date: Thu, 27 Jan 2011 11:00:25 +0000 Subject: [New-bugs-announce] [issue11022] locale.setlocale() doesn't change I/O codec, os.environ[] does In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za> Message-ID: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za> New submission from Steffen Daode Nurpmeso : This bug may be based on same problem as Issue 6203. - My system locale is en_GB.UTF-8. - Given a latin1 text file, open()+ will fail with 'UnicodeDecodeError: 'utf8' codec can't decode byte 0xf6...' - Using locale.setlocale(..., ...) - Re-open causes same error, I/O layer codec has not been changed! - Using os.environ["LC_ALL"] = ... - Re-open works properly, I/O layer codec has been changed. P.S.: i am new to Python, please don't assume i can help in solving the problem! ---------- components: Library (Lib) messages: 127177 nosy: sdaoden priority: normal severity: normal status: open title: locale.setlocale() doesn't change I/O codec, os.environ[] does versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 14:17:15 2011 From: report at bugs.python.org (Alan Isaac) Date: Thu, 27 Jan 2011 13:17:15 +0000 Subject: [New-bugs-announce] [issue11023] pep 227 missing text In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za> Message-ID: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za> New submission from Alan Isaac : In PEP 227 missing text is marked with XXX. Most of this is just calls for examples and elaboration. However under the Implementation section XXX marks a substantive question about the documentation. Fixing this may be low priority, but a tracker search suggested it is currently not even being tracked ... ---------- assignee: docs at python components: Documentation messages: 127184 nosy: aisaac, docs at python priority: normal severity: normal status: open title: pep 227 missing text type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 14:35:01 2011 From: report at bugs.python.org (Sebastian Spaeth) Date: Thu, 27 Jan 2011 13:35:01 +0000 Subject: [New-bugs-announce] [issue11024] imaplib: Time2Internaldate() returns localized strings In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za> Message-ID: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za> New submission from Sebastian Spaeth : imaplib's Time2Internaldate returns invalid (as localized) INTERNALDATE strings. Appending a message with such a time string leads to a: 19 BAD Command Argument Error. 11 (for MS?Exchange IMAP servers) it returned "26-led-2011 18:23:44 +0100", however: http://tools.ietf.org/html/rfc2060.html defines: date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" so it expects an English date format. imaplib's Time2Internaldate uses time.strftime() to create the final string which uses the current locale, returning things such as: "26-led-2011 18:23:44 +0100" rather than "26-Jan-2011 18:23:44 +0100". For the right thing to do, we would need to set locale.setlocale(locale.LC_TIME, '') to get English formatting or we would need to use some home-grown parser that hardcodes the proper terms. ---------- components: Library (Lib) messages: 127186 nosy: spaetz priority: normal severity: normal status: open title: imaplib: Time2Internaldate() returns localized strings type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 15:17:02 2011 From: report at bugs.python.org (Boris FELD) Date: Thu, 27 Jan 2011 14:17:02 +0000 Subject: [New-bugs-announce] [issue11025] Distutils2 install command without setup.py or setup.cfg create an UNKNOWN-UNKNOWN.dist-info distribution In-Reply-To: <1296137822.54.0.488417839066.issue11025@psf.upfronthosting.co.za> Message-ID: <1296137822.54.0.488417839066.issue11025@psf.upfronthosting.co.za> New submission from Boris FELD : Distutils2 install command don't display error if you try to launch it in a directory without setup.py nor setup.cfg files. It install an UNKNOWN-UNKNOWN.dist-info distribution in your site-package with all meta-data file set to UNKNOWN. ---------- assignee: tarek components: Distutils2 files: METADATA messages: 127190 nosy: Boris.FELD, eric.araujo, tarek, tarek-ziade priority: normal severity: normal status: open title: Distutils2 install command without setup.py or setup.cfg create an UNKNOWN-UNKNOWN.dist-info distribution versions: Python 2.6 Added file: http://bugs.python.org/file20545/METADATA _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 15:35:35 2011 From: report at bugs.python.org (Boris FELD) Date: Thu, 27 Jan 2011 14:35:35 +0000 Subject: [New-bugs-announce] [issue11026] Distutils2 install command fail with python 2.5/2.7 In-Reply-To: <1296138935.4.0.881048172812.issue11026@psf.upfronthosting.co.za> Message-ID: <1296138935.4.0.881048172812.issue11026@psf.upfronthosting.co.za> New submission from Boris FELD : Distutils2 install command fail with both python 2.5 and python 2.7 while it works with python 2.6. $ python -V python 2.5.4 $ python -m "distutils2.run" install usage: run.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: run.py --help [cmd1 cmd2 ...] or: run.py --help-commands or: run.py cmd --help error: Invalid command install ################################ $ python -V Python 2.7.1 $ python -m "distutils2.run" install usage: run.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: run.py --help [cmd1 cmd2 ...] or: run.py --help-commands or: run.py cmd --help error: Invalid command install It fail it a setup.cfg exists or not in the current directory. ---------- assignee: tarek components: Distutils2 messages: 127192 nosy: Boris.FELD, eric.araujo, tarek, tarek-ziade priority: normal severity: normal status: open title: Distutils2 install command fail with python 2.5/2.7 versions: Python 2.5, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 15:37:05 2011 From: report at bugs.python.org (Kunjesh Kaushik) Date: Thu, 27 Jan 2011 14:37:05 +0000 Subject: [New-bugs-announce] [issue11027] Allow spaces around section header in ConfigParser In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za> Message-ID: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za> New submission from Kunjesh Kaushik : It is often desirable to be able to write a section with spaces around the header, as in "[ default ]" instead of "[default]" for the sake of readability of configuration file. I am not sure if this is the "standard" format of configuration files. The following (attached) patch will achieve the desired result. It is also backward-compatible. Kindly arrange for the patch to be applied to the repository or to a future release. Original Code Location: http://svn.python.org/view/*checkout*/python/branches/release27-maint/Lib/ConfigParser.py?revision=84443 Index: Lib/ConfigParser.py =================================================================== --- Lib/ConfigParser.py (revision 84443) +++ Lib/ConfigParser.py (working copy) @@ -432,7 +432,7 @@ # SECTCRE = re.compile( r'\[' # [ - r'(?P

[^]]+)' # very permissive! + r'\s*(?P

[^]]+)\s*' # very permissive! r'\]' # ] ) OPTCRE = re.compile( ---------- components: Library (Lib) files: allow_spaces_around_section_header.diff keywords: patch messages: 127193 nosy: Kunjesh.Kaushik priority: normal severity: normal status: open title: Allow spaces around section header in ConfigParser type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file20547/allow_spaces_around_section_header.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 15:45:08 2011 From: report at bugs.python.org (alain tty) Date: Thu, 27 Jan 2011 14:45:08 +0000 Subject: [New-bugs-announce] [issue11028] Implement the setup.py -> setup.cfg in mkcfg In-Reply-To: <1296139508.67.0.695480903327.issue11028@psf.upfronthosting.co.za> Message-ID: <1296139508.67.0.695480903327.issue11028@psf.upfronthosting.co.za> New submission from alain tty : It shall be interesting to simplify the building of the setup.cfg from an existing setup.py. A distutils2.mkcfg.load_existing_setup_script function already exists but it raises NotImplementedError. Since taking into account setuptools could be straightforward we propose to add a implementation that takes care of distutils arguments only. ---------- assignee: tarek components: Distutils2 messages: 127197 nosy: alaintty, eric.araujo, tarek, tarek-ziade priority: normal severity: normal status: open title: Implement the setup.py -> setup.cfg in mkcfg type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 18:01:04 2011 From: report at bugs.python.org (Scott M) Date: Thu, 27 Jan 2011 17:01:04 +0000 Subject: [New-bugs-announce] [issue11029] Crash, 2.7.1, Tkinter and threads and line drawing In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za> Message-ID: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za> New submission from Scott M : Running on dual core Windows XP. The function should draw a parabolicish shape for each click on launch. But if you click Launch over and over, very fast, you get bizarre crashes instead: Python.exe has encoutered a problem, yadda. tcl85.dll. It rarely takes many clicks. Apologies for the coding style; this has been hacked down from a larger app. In the console window: Exception in thread Thread-5: Traceback (most recent call last): File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner self.run() File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py" , line 47, in run self.app.arrival_122((self.target, y, z)) File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py" , line 100, in arrival_122 self.label.config(text= str(message[0])+ " " + str(message[1])) File "C:\Python27\lib\lib-tk\Tkinter.py", line 1202, in configure return self._configure('configure', cnf, kw) File "C:\Python27\lib\lib-tk\Tkinter.py", line 1193, in _configure self.tk.call(_flatten((self._w, cmd)) + self._options(cnf)) TclError: invalid command name "source C:/Python27/tcl/tk8.5/menu.tcl" Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner self.run() File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py" , line 47, in run self.app.arrival_122((self.target, y, z)) File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py" , line 125, in arrival_122 self.graph.create_line(self.trackCoordinates[tn], new_yz) File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line return self._create('line', args, kw) File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create *(args + self._options(cnf, kw)))) TclError: invalid command name "line" Also saw: File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line return self._create('line', args, kw) File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create *(args + self._options(cnf, kw)))) TclError: bad option "665.4400009999997": must be addtag, bbox, bind, canvasx, canvasy, cget, configure, coords, create, dchars, delete, dtag, find, focus, gettags, icursor, index, insert, itemcget, itemconfigure, lower, move, postscript, raise, scale, scan, select, type, xview, or yview ---------- components: Tkinter files: TkinterCrash.py messages: 127201 nosy: PythonInTheGrass priority: normal severity: normal status: open title: Crash, 2.7.1, Tkinter and threads and line drawing type: crash versions: Python 2.7 Added file: http://bugs.python.org/file20549/TkinterCrash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 19:48:57 2011 From: report at bugs.python.org (Sandro Tosi) Date: Thu, 27 Jan 2011 18:48:57 +0000 Subject: [New-bugs-announce] [issue11030] regrtest - allow for relative path with --coverdir In-Reply-To: <1296154137.39.0.416513090061.issue11030@psf.upfronthosting.co.za> Message-ID: <1296154137.39.0.416513090061.issue11030@psf.upfronthosting.co.za> New submission from Sandro Tosi : Hi, following up msg127157 here's a patch to allow for relative path when using --coverdir. The current solution uses getcwd() but since CWD is replaced by a temporary location before calling main(), then the resulting dir is in an unexpected location. using support.SAVECWD we use the saved CWD that's where the script is executed, so the relative path is created/used where expected. ---------- assignee: sandro.tosi components: Tests files: regrtest_coverdir_relative_path-py3k.patch keywords: patch messages: 127207 nosy: sandro.tosi priority: low severity: normal stage: patch review status: open title: regrtest - allow for relative path with --coverdir versions: Python 3.3 Added file: http://bugs.python.org/file20551/regrtest_coverdir_relative_path-py3k.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 27 22:49:36 2011 From: report at bugs.python.org (Sandro Tosi) Date: Thu, 27 Jan 2011 21:49:36 +0000 Subject: [New-bugs-announce] [issue11031] regrtest - --testdir, new command-line option to specify alternative test directory In-Reply-To: <1296164976.55.0.598223857745.issue11031@psf.upfronthosting.co.za> Message-ID: <1296164976.55.0.598223857745.issue11031@psf.upfronthosting.co.za> New submission from Sandro Tosi : from msg127153 + msg127157 + msg127172 I prepared this patch to introduce a new cli option to regrtest.py, --testdir DIR, that allows to specify a different location for the directory containing the test files. along the way, I added a description of what STDTESTS and NOTTESTS is and differentiate the call to findtests() if testdir is passed to not use those information. ---------- assignee: sandro.tosi components: Tests files: regrtest_add_testdir-py3k.patch keywords: patch messages: 127227 nosy: sandro.tosi priority: low severity: normal stage: patch review status: open title: regrtest - --testdir, new command-line option to specify alternative test directory versions: Python 3.3 Added file: http://bugs.python.org/file20559/regrtest_add_testdir-py3k.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 00:07:56 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 27 Jan 2011 23:07:56 +0000 Subject: [New-bugs-announce] [issue11032] _string: formatter_field_name_split() and formatter_parser doesn't check input type In-Reply-To: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za> Message-ID: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za> New submission from STINNER Victor : $ ./python Python 3.2rc1+ (unknown, Jan 18 2011, 00:55:20) >>> import _string >>> _string.formatter_field_name_split(1) python: Objects/stringlib/string_format.h:1347: formatter_field_name_split: Assertion `((((((PyObject*)(self))->ob_type))->tp_flags & ((1L<<28))) != 0)' failed. Abandon $ ./python Python 3.2rc1+ (unknown, Jan 18 2011, 00:55:20) >>> import _string >>> _string.formatter_parser(1) python: Objects/stringlib/string_format.h:1206: formatter_parser: Assertion `((((((PyObject*)(self))->ob_type))->tp_flags & ((1L<<28))) != 0)' failed. Abandon Attached patch fixes both crashes and add tests on the _string module (which has only these two functions). ---------- components: Library (Lib) files: _string.patch keywords: patch messages: 127236 nosy: haypo priority: normal severity: normal status: open title: _string: formatter_field_name_split() and formatter_parser doesn't check input type versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20562/_string.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 01:07:36 2011 From: report at bugs.python.org (Peter Cai) Date: Fri, 28 Jan 2011 00:07:36 +0000 Subject: [New-bugs-announce] [issue11033] ElementTree.fromstring doesn't work with Unicode In-Reply-To: <1296173256.62.0.363094614198.issue11033@psf.upfronthosting.co.za> Message-ID: <1296173256.62.0.363094614198.issue11033@psf.upfronthosting.co.za> New submission from Peter Cai : xml.etree.ElementTree.fromstring doesn't work with Unicode string. See the code below: >>> from xml.etree import ElementTree >>> t = ElementTree.fromstring(u'?') Traceback (most recent call last): File "", line 1, in File "D:\Python26\lib\xml\etree\ElementTree.py", line 963, in XML parser.feed(text) File "D:\Python26\lib\xml\etree\ElementTree.py", line 1245, in feed self._parser.Parse(data, 0) UnicodeEncodeError: 'ascii' codec can't encode character u'\u8bd7' in position 5 : ordinal not in range(128) ---------- components: XML messages: 127239 nosy: Peter.Cai priority: normal severity: normal status: open title: ElementTree.fromstring doesn't work with Unicode type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 08:37:36 2011 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 28 Jan 2011 07:37:36 +0000 Subject: [New-bugs-announce] [issue11034] Build problem on Windows with MSVC++ Express 2008 In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za> Message-ID: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za> New submission from Eli Bendersky : On a clean checkout of py3k, I try to open PCBuild/pcbuild.sln with my MSVC++ Express 2008. When opening, a message box pops saying: Solution folders are not supported in this version of the application. Solution folder "Solution Items" will be displayed as unavailable. I go on building following instructions (F7, leaving the default Debug win32 configuration). I get a bunch of LNK1181 errors: 27> LINK : fatal error LNK1181: cannot open input file '.\python32_d.lib' When I try to build the pythoncore project only, I get: 1>c1 : fatal error C1083: Cannot open source file: 'D:\eli\python-py3k-trunk\PCbuild\Win32-temp-Debug\pythoncore\\getbuildinfo2.c': No such file or directory Maybe there's some problem with the make_buildinfo call in the pre-build event? ---------- components: Build messages: 127249 nosy: eli.bendersky, loewis priority: normal severity: normal status: open title: Build problem on Windows with MSVC++ Express 2008 type: compile error versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 10:36:50 2011 From: report at bugs.python.org (Dmitry Groshev) Date: Fri, 28 Jan 2011 09:36:50 +0000 Subject: [New-bugs-announce] [issue11035] Segmentation fault In-Reply-To: <1296207410.47.0.601145412555.issue11035@psf.upfronthosting.co.za> Message-ID: <1296207410.47.0.601145412555.issue11035@psf.upfronthosting.co.za> New submission from Dmitry Groshev : Here is a console output: si14 at si14-work:~/repos/monitoring/root$ python2.7 server.py 127.0.0.1 - - [2011-01-28 12:29:30] "GET /update HTTP/1.1" 200 320 "-" "Python-urllib/2.7" {"seenby":[1],"received":1296207058.993983,"observer":1,"type":"ping","source":102,"time":1296207058.990101,"data":[[1296206970.543701,0.010154962539672852],[1296206980.383922,0.010203123092651367],[1296206990.222841,0.01015615463256836],[1296207000.050695,0.010264873504638672],[1296207009.876834,0.011881113052368164],[1296207019.698611,0.010120153427124023],[1296207029.519147,0.010251045227050781],[1296207039.342266,0.010113000869750977],[1296207049.167352,0.010238885879516602],[1296207058.990089,0.010174989700317383]],"class":"statistics"} 127.0.0.1 - - [2011-01-28 12:30:59] "POST / HTTP/1.1" 200 2 "-" "Python-urllib/2.7" Segmentation fault si14 at si14-work:~/repos/monitoring/root$ I'm not sure that this is a gevent issue, so I'm posting it here. server.py sources are attached. ---------- components: Interpreter Core files: server.py messages: 127266 nosy: Dmitry.Groshev priority: normal severity: normal status: open title: Segmentation fault type: crash versions: Python 2.7 Added file: http://bugs.python.org/file20570/server.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 11:30:52 2011 From: report at bugs.python.org (Gael Pasgrimaud) Date: Fri, 28 Jan 2011 10:30:52 +0000 Subject: [New-bugs-announce] [issue11036] Allow multiple files in the description-file metadata In-Reply-To: <1296210652.15.0.670840085537.issue11036@psf.upfronthosting.co.za> Message-ID: <1296210652.15.0.670840085537.issue11036@psf.upfronthosting.co.za> New submission from Gael Pasgrimaud : It can be usefull to allow more than one file in the description-file metadata so people can concatenate README and CHANGES file. ---------- assignee: tarek components: Distutils2 messages: 127272 nosy: eric.araujo, gawel, tarek priority: normal severity: normal status: open title: Allow multiple files in the description-file metadata type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 11:34:50 2011 From: report at bugs.python.org (Sebastien Douche) Date: Fri, 28 Jan 2011 10:34:50 +0000 Subject: [New-bugs-announce] [issue11037] How distutils2 handle namespaces In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za> Message-ID: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za> New submission from Sebastien Douche : Namespace is very useful. In my company, we use a root namespace (sact.*) and a sub-namespace for each big project (sact.nevrax.*, sact.storage.*). ---------- assignee: tarek components: Distutils2 messages: 127274 nosy: eric.araujo, sdouche, tarek priority: normal severity: normal status: open title: How distutils2 handle namespaces _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 11:39:15 2011 From: report at bugs.python.org (Gael Pasgrimaud) Date: Fri, 28 Jan 2011 10:39:15 +0000 Subject: [New-bugs-announce] [issue11038] Some commands should stop if Name and Version are missing In-Reply-To: <1296211155.96.0.0798615868084.issue11038@psf.upfronthosting.co.za> Message-ID: <1296211155.96.0.0798615868084.issue11038@psf.upfronthosting.co.za> New submission from Gael Pasgrimaud : distutils2 commands should stop if at least Name and Version metadatas are not provided in setup.cfg For now you'll get a UNKNOWN-UNKNOWN.tar.gz ---------- assignee: tarek components: Distutils2 messages: 127277 nosy: eric.araujo, gawel, tarek priority: normal severity: normal status: open title: Some commands should stop if Name and Version are missing type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 12:23:25 2011 From: report at bugs.python.org (Konstantin Osipov) Date: Fri, 28 Jan 2011 11:23:25 +0000 Subject: [New-bugs-announce] [issue11039] Use of 'L' specifier is inconsistent when printing long integers In-Reply-To: <1296213805.8.0.5306438252.issue11039@psf.upfronthosting.co.za> Message-ID: <1296213805.8.0.5306438252.issue11039@psf.upfronthosting.co.za> New submission from Konstantin Osipov : I'm using a 64 bit system, but the issue is as well repeatable on 32 bit systems: kostja at shmita:~$ python Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 0xffffffffffffffff 18446744073709551615L >>> [0xffffffffffffffff] [18446744073709551615L] >>> str(0xffffffffffffffff) '18446744073709551615' >>> str([0xffffffffffffffff]) '[18446744073709551615L]' Notice the 'L' specifier disappears when creating a string from an integer. I.e. depending on conversion order, 'L' specifier is present or absent in the resulting string representation. I don't know the reason why 'L' specifier is necessary at all when printing integers, rather, I'd say it's very harmful, because makes Python program platform-dependent (since int is mapped to C long, 32-bit systems print 'L' where 64-bit systems don't), but please at least make the output consistent! Thanks, -- kostja ---------- components: None messages: 127284 nosy: kostja priority: normal severity: normal status: open title: Use of 'L' specifier is inconsistent when printing long integers versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 12:31:29 2011 From: report at bugs.python.org (Julien Miotte) Date: Fri, 28 Jan 2011 11:31:29 +0000 Subject: [New-bugs-announce] [issue11040] After registering a project to PyPI, classifiers fields aren't displayed. In-Reply-To: <1296214289.89.0.718507704088.issue11040@psf.upfronthosting.co.za> Message-ID: <1296214289.89.0.718507704088.issue11040@psf.upfronthosting.co.za> New submission from Julien Miotte : When I register a project with a setup.cfg with the following classifiers: classifier = Development Status :: 3 - Alpha License :: OSI Approved :: GNU General Public License (GPL) Environment :: X11 Applications :: Qt And using the command: $ python -m distutils2.run register I can't find the classifiers on the PyPI project page, althought they can be found in the PKG-INFO generated by the 'sdist' command. ---------- assignee: tarek components: Distutils2 messages: 127285 nosy: Julien.Miotte, eric.araujo, tarek, tarek-ziade priority: normal severity: normal status: open title: After registering a project to PyPI, classifiers fields aren't displayed. versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 12:39:48 2011 From: report at bugs.python.org (Julien Miotte) Date: Fri, 28 Jan 2011 11:39:48 +0000 Subject: [New-bugs-announce] [issue11041] On the distutils2 documentation, 'requires-python' shouldn't be documented as *multi In-Reply-To: <1296214788.72.0.049703794101.issue11041@psf.upfronthosting.co.za> Message-ID: <1296214788.72.0.049703794101.issue11041@psf.upfronthosting.co.za> New submission from Julien Miotte : On the documentation page: http://distutils2.notmyidea.org/setupcfg.html, one can read : # requires-python: Specifies the Python version the distribution requires. The value is a version number, as described in PEP 345. *optional *multi *environ This is not consistant with the PEP 345 (http://www.python.org/dev/peps/pep-0345/#requires-python), which doesn't specify that this field is of multiple use. Distutils's behaviour on this matter is consistent with the PEP thought, so there's only need to remove the "*multi" in the documentation. ---------- assignee: tarek components: Distutils2 messages: 127287 nosy: Julien.Miotte, eric.araujo, tarek, tarek-ziade priority: normal severity: normal status: open title: On the distutils2 documentation, 'requires-python' shouldn't be documented as *multi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 12:46:18 2011 From: report at bugs.python.org (Julien Miotte) Date: Fri, 28 Jan 2011 11:46:18 +0000 Subject: [New-bugs-announce] [issue11042] [PyPI CSS] Adding project urls onto a project page using register, apparition of an overhead over the title In-Reply-To: <1296215178.29.0.349266521718.issue11042@psf.upfronthosting.co.za> Message-ID: <1296215178.29.0.349266521718.issue11042@psf.upfronthosting.co.za> New submission from Julien Miotte : When adding project urls onto a PyPI project page using the following setup.cfg extract: project_url = Source repository,https://github.com/mike-perdide/qGitFilterBranch And then registering the project with: python -m distutils2.run register Causes a not-so-nice overhead to appear just above the project title. Can be seen in http://pypi.python.org/pypi/qGitFilterBranch/0.9. ---------- assignee: tarek components: Distutils2 messages: 127288 nosy: Julien.Miotte, eric.araujo, tarek, tarek-ziade priority: normal severity: normal status: open title: [PyPI CSS] Adding project urls onto a project page using register, apparition of an overhead over the title _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 12:50:57 2011 From: report at bugs.python.org (Julien Miotte) Date: Fri, 28 Jan 2011 11:50:57 +0000 Subject: [New-bugs-announce] [issue11043] On GNU/Linux (Ubuntu) distutils2.mkcfg shouldn't create an executable setup.cfg In-Reply-To: <1296215457.79.0.848370821924.issue11043@psf.upfronthosting.co.za> Message-ID: <1296215457.79.0.848370821924.issue11043@psf.upfronthosting.co.za> New submission from Julien Miotte : When using the command: $ python -m distutils2.mkcfg To create a new setup.cfg, the resulting setup.cfg has the following permissions: -rwxr-xr-x 1 mike mike 151 2011-01-28 12:47 setup.cfg* I think the permissions should be 644 ---------- assignee: tarek components: Distutils2 messages: 127289 nosy: Julien.Miotte, eric.araujo, tarek, tarek-ziade priority: normal severity: normal status: open title: On GNU/Linux (Ubuntu) distutils2.mkcfg shouldn't create an executable setup.cfg versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 13:00:54 2011 From: report at bugs.python.org (Julien Miotte) Date: Fri, 28 Jan 2011 12:00:54 +0000 Subject: [New-bugs-announce] [issue11044] The description-file isn't handled by distutils2 In-Reply-To: <1296216054.85.0.726988451009.issue11044@psf.upfronthosting.co.za> Message-ID: <1296216054.85.0.726988451009.issue11044@psf.upfronthosting.co.za> New submission from Julien Miotte : When using the description-file field with a README.txt, and then using the 'sdist' command, the generated PKG-INFO file will contain: Description: UNKNOWN Note: when using the description field with a simple string, the generated PKG-INFO file will contain the correct string. ---------- assignee: tarek components: Distutils2 messages: 127291 nosy: Julien.Miotte, eric.araujo, tarek, tarek-ziade priority: normal severity: normal status: open title: The description-file isn't handled by distutils2 versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 14:48:10 2011 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Fri, 28 Jan 2011 13:48:10 +0000 Subject: [New-bugs-announce] [issue11045] shutil._make_tarball In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za> Message-ID: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za> New submission from Tarek Ziad? : This line : logger.info("creating %s" % archive_dir) should check that logger is not None before being called.. ---------- assignee: tarek components: Library (Lib) messages: 127300 nosy: tarek priority: high severity: normal status: open title: shutil._make_tarball type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 15:26:24 2011 From: report at bugs.python.org (Steffen Daode Nurpmeso) Date: Fri, 28 Jan 2011 14:26:24 +0000 Subject: [New-bugs-announce] [issue11046] darwin/MacOS X setup.py hack In-Reply-To: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za> Message-ID: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za> New submission from Steffen Daode Nurpmeso : I always hated GNU Autoconf and M4. After cloning branches/py3k today i needed two and a half hour to build and compile a Python which includes the readline module. I'll attach a primitive setup.py patch which should better not make it into a release version ... Some more notes on the compilation: Snow Leopard here has SDK's 10.5 and 10.6. I did not understand what was going on, configure does everything to explain me it is using (nonexistent) 10.4. The configure script is checking for OSX 10.5 SDK or later... yes but that doesn't seem to matter. I gave up on hacking (the anyway generated) configure (around line 5532), no matter what i do, i still get CONFIGURE_MACOSX_DEPLOYMENT_TARGET='10.4' Damn! Ooh, Ooh, how nice are plain Makefiles and small-team projects. ---------- components: Build files: DIFF messages: 127304 nosy: sdaoden priority: normal severity: normal status: open title: darwin/MacOS X setup.py hack versions: Python 3.2 Added file: http://bugs.python.org/file20575/DIFF _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 17:53:28 2011 From: report at bugs.python.org (Oren Held) Date: Fri, 28 Jan 2011 16:53:28 +0000 Subject: [New-bugs-announce] [issue11047] Bad description for a change In-Reply-To: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za> Message-ID: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za> New submission from Oren Held : In the "what's new in 2.7", there is some mistake in the description of issue 7902. 7902, afaik, disables the fallback to absolute import, when requesting a relative import fails. If I got it right, the description states the opposite. ---------- assignee: docs at python components: Documentation files: whatsnew_issue_7902_fix.patch keywords: patch messages: 127317 nosy: Oren_Held, docs at python priority: normal severity: normal status: open title: Bad description for a change versions: Python 2.7 Added file: http://bugs.python.org/file20577/whatsnew_issue_7902_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 18:05:09 2011 From: report at bugs.python.org (Pavel Labushev) Date: Fri, 28 Jan 2011 17:05:09 +0000 Subject: [New-bugs-announce] [issue11048] "import ctypes" causes segfault on read-only filesystem In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za> Message-ID: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za> New submission from Pavel Labushev : "import ctypes" causes segfault on read-only filesystem This regression was introduced in python-2.6.6 and exists in all the later versions. To reproduce run python -c "import ctypes" on read-only filesystem: (gdb) file python3.2 Reading symbols from /usr/bin/python3.2...done. (gdb) run -c "import ctypes" Starting program: /usr/bin/python3.2 -c "import ctypes" [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0xb7af605c in CThunkObject_dealloc (_self=0xb7b35344) at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c:18 18 /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c: No such file or directory. in /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c (gdb) bt #0 0xb7af605c in CThunkObject_dealloc (_self=0xb7b35344) at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c:18 #1 0xb7af63b4 in _ctypes_alloc_callback (callable=0xb7b10bec, converters=0xb7c4e02c, restype=0xb810c544, flags=257) at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c:439 #2 0xb7af1f57 in PyCFuncPtr_new (type=0xb810b0bc, args=0xb7b3618c, kwds=0x0) at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/_ctypes.c:3339 #3 0xb7ea2355 in type_call (type=0xb810b0bc, args=0xb7b3618c, kwds=0x0) at Objects/typeobject.c:676 #4 0xb7e4f34e in PyObject_Call (func=0xb810b0bc, arg=0xb7b3618c, kw=0x0) at Objects/abstract.c:2149 #5 0xb7eedee3 in do_call (f=0xb80fdb44, throwflag=0) at Python/ceval.c:4095 #6 call_function (f=0xb80fdb44, throwflag=0) at Python/ceval.c:3898 #7 PyEval_EvalFrameEx (f=0xb80fdb44, throwflag=0) at Python/ceval.c:2673 #8 0xb7ef0639 in PyEval_EvalCodeEx (_co=0xb7b159d0, globals=0xb7bf40b4, locals=0xb7bf40b4, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3311 #9 0xb7ef08b6 in PyEval_EvalCode (co=0xb7b159d0, globals=0xb7bf40b4, locals=0xb7bf40b4) at Python/ceval.c:761 #10 0xb7f0121c in PyImport_ExecCodeModuleWithPathnames (name=0xbfffd9fb "ctypes", co=0xb7b159d0, pathname=0xbfffa89b "/usr/lib/python3.2/ctypes/__pycache__/__init__.cpython-32.pyc", cpathname=0xbfffa89b "/usr/lib/python3.2/ctypes/__pycache__/__init__.cpython-32.pyc") at Python/import.c:809 #11 0xb7f03ce8 in load_source_module (name=, pathname=, fp=0xb8020b28) at Python/import.c:1339 #12 0xb7f044f8 in load_package (name=, pathname=) at Python/import.c:1435 #13 0xb7f04da7 in import_submodule (mod=, subname=, fullname=0xbfffd9fb "ctypes") at Python/import.c:2894 #14 0xb7f050b4 in load_next (mod=, altmod=, p_name=0xbfffd9ec, buf=0xbfffd9fb "ctypes", p_buflen=0xbfffd9f4) at Python/import.c:2706 #15 0xb7f05774 in import_module_level (name=0x0, globals=, locals=0xb7c2035c, fromlist=0xb7f98ca0, level=0) at Python/import.c:2422 #16 0xb7f05d14 in PyImport_ImportModuleLevel (name=0xb7c0f8e8 "ctypes", globals=0xb7c2035c, locals=0xb7c2035c, fromlist=0xb7f98ca0, level=0) at Python/import.c:2474 #17 0xb7ee73c1 in builtin___import__ (self=0xb7c6726c, args=0xb7c7b9bc, kwds=0x0) at Python/bltinmodule.c:168 #18 0xb7e907fe in PyCFunction_Call (func=0xb7c6730c, arg=0xb7c7b9bc, kw=0xb7b35344) at Objects/methodobject.c:84 #19 0xb7e4f34e in PyObject_Call (func=0xb7c6730c, arg=0xb7c7b9bc, kw=0x0) at Objects/abstract.c:2149 #20 0xb7ee802f in PyEval_CallObjectWithKeywords (func=0xb7c6730c, arg=0xb7c7b9bc, kw=0x0) at Python/ceval.c:3755 #21 0xb7eec962 in PyEval_EvalFrameEx (f=0xb8072564, throwflag=0) at Python/ceval.c:2332 #22 0xb7ef0639 in PyEval_EvalCodeEx (_co=0xb7bdb7f0, globals=0xb7c2035c, locals=0xb7c2035c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3311 #23 0xb7ef08b6 in PyEval_EvalCode (co=0xb7bdb7f0, globals=0xb7c2035c, locals=0xb7c2035c) at Python/ceval.c:761 #24 0xb7f0eabc in run_mod (mod=, filename=, globals=0xb7c2035c, locals=0xb7c2035c, flags=0xbfffefa8, arena=0xb8071030) at Python/pythonrun.c:1760 #25 0xb7f0edf9 in PyRun_StringFlags (str=0xb7bf5330 "import ctypes\n", start=257, globals=0xb7c2035c, locals=0xb7c2035c, flags=0xbfffefa8) at Python/pythonrun.c:1694 #26 0xb7f11006 in PyRun_SimpleStringFlags (command=0xb7bf5330 "import ctypes\n", flags=0xbfffefa8) at Python/pythonrun.c:1267 #27 0xb7f2477c in run_command (argc=3, argv=0xb8001018) at Modules/main.c:258 #28 Py_Main (argc=3, argv=0xb8001018) at Modules/main.c:647 #29 0xb7fffc4f in main (argc=3, argv=0xbffff0d4) at ./Modules/python.c:82 (gdb) quit ---------- assignee: theller components: ctypes messages: 127318 nosy: Arach, Arfrever, theller priority: normal severity: normal status: open title: "import ctypes" causes segfault on read-only filesystem versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 20:05:31 2011 From: report at bugs.python.org (Brett Cannon) Date: Fri, 28 Jan 2011 19:05:31 +0000 Subject: [New-bugs-announce] [issue11049] add tests for test.support In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za> Message-ID: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za> New submission from Brett Cannon : It seems a little negligent that test.support has no tests. The test.test_support name is available in py3k and backporting issues to 2.7 shouldn't be a problem (rare chance something does happen it can be handling manually). There doesn't seem to be any reason not to make sure that proper unit testing is being done short of just laziness on our parts. And if this does occur it should probably be listed as an essential test in regrtest. ---------- components: Tests keywords: easy messages: 127322 nosy: brett.cannon, r.david.murray priority: normal severity: normal stage: needs patch status: open title: add tests for test.support versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 23:30:02 2011 From: report at bugs.python.org (Ivan Egorov) Date: Fri, 28 Jan 2011 22:30:02 +0000 Subject: [New-bugs-announce] [issue11050] email.utils.getaddresses behavior contradicts RFC2822 In-Reply-To: <1296253802.55.0.925837101087.issue11050@psf.upfronthosting.co.za> Message-ID: <1296253802.55.0.925837101087.issue11050@psf.upfronthosting.co.za> New submission from Ivan Egorov : email.utils.getaddresses behaves wrong in following folding cases (outer single quote is not a part of value): '"A\r\n (B)" ' '(A\r\n C) ' The misbehavior occurs in at least 2.6, 2.7 and branches/py3k. Both these strings are RFC 2822 compliant, but current getaddresses() implementation misbehaves on 'quoted-string' and 'comment' containing CRLF. Following references the related RFC sections: http://tools.ietf.org/html/rfc2822#section-3.4 http://tools.ietf.org/html/rfc2822#section-3.2.5 Attachment contains tests and patch for the case. ---------- components: Library (Lib) files: email.utils.getaddresses.patch keywords: patch messages: 127357 nosy: Ivan.Egorov priority: normal severity: normal status: open title: email.utils.getaddresses behavior contradicts RFC2822 type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file20590/email.utils.getaddresses.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 28 23:49:33 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 28 Jan 2011 22:49:33 +0000 Subject: [New-bugs-announce] [issue11051] system calls per import In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za> Message-ID: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Here are the system calls when importing a single pure Python module: stat("/home/antoine/py3k/py3k/Lib/copyreg", 0x7fff1ed1f740) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/copyreg.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/copyregmodule.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/copyreg.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/copyregmodule.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/copyreg.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/copyregmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/copyreg.py", O_RDONLY) = 5 fstat(5, {st_mode=S_IFREG|0664, st_size=6633, ...}) = 0 open("/home/antoine/py3k/py3k/Lib/__pycache__/copyreg.cpython-32.pyc", O_RDONLY) = 6 fstat(6, {st_mode=S_IFREG|0664, st_size=5595, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f28e6381000 read(6, "l\f\r\n\0\24\212Hc\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0@\0\0\0s\307\0"..., 4096) = 4096 fstat(6, {st_mode=S_IFREG|0664, st_size=5595, ...}) = 0 This is per possible directory, which means that it can be repeated for each dir on sys.path: stat("readline", 0x7fff1ed28760) = -1 ENOENT (No such file or directory) open("readline.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("readlinemodule.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("readline.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("readlinemodule.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("readline.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("readlinemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("readline.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("readline.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/home/antoine/py3k/py3k/Lib/readline", 0x7fff1ed28760) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/readline.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/readlinemodule.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/readline.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/readlinemodule.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/readline.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/readlinemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/readline.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/readline.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/home/antoine/py3k/py3k/Lib/plat-linux2", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 stat("/home/antoine/py3k/py3k/Lib/plat-linux2", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 stat("/home/antoine/py3k/py3k/Lib/plat-linux2/readline", 0x7fff1ed28760) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/plat-linux2/readline.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/plat-linux2/readlinemodule.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/plat-linux2/readline.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/plat-linux2/readlinemodule.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/plat-linux2/readline.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/plat-linux2/readlinemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/plat-linux2/readline.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/Lib/plat-linux2/readline.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/home/antoine/py3k/py3k/build/lib.linux-x86_64-3.2", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 stat("/home/antoine/py3k/py3k/build/lib.linux-x86_64-3.2", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 stat("/home/antoine/py3k/py3k/build/lib.linux-x86_64-3.2/readline", 0x7fff1ed28760) = -1 ENOENT (No such file or directory) open("/home/antoine/py3k/py3k/build/lib.linux-x86_64-3.2/readline.cpython-32m.so", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0775, st_size=59970, ...}) = 0 futex(0x7f28e605e0ec, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/home/antoine/py3k/py3k/build/lib.linux-x86_64-3.2/readline.cpython-32m.so", O_RDONLY) = 4 Something has gone out of control here. Why do we need to check so many alternative locations? ---------- components: Interpreter Core messages: 127359 nosy: barry, loewis, pitrou priority: normal severity: normal status: open title: system calls per import type: performance versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 03:52:58 2011 From: report at bugs.python.org (Ned Deily) Date: Sat, 29 Jan 2011 02:52:58 +0000 Subject: [New-bugs-announce] [issue11052] Fix OS X IDLE menu accelerators for Save As and Save Copy In-Reply-To: <1296269578.92.0.1087041883.issue11052@psf.upfronthosting.co.za> Message-ID: <1296269578.92.0.1087041883.issue11052@psf.upfronthosting.co.za> New submission from Ned Deily : On OS X, the menu accelerators for the Save As and Save Copy As commands are incorrect: Are Should Be Save Cmd-S Cmd-S Save As.. Cmd-S Shift-Cmd-S Save Copy As.. Shift-Cmd-S Option-Cmd-S The attached patch fixes that. It would be good to get into 3.2rc2 as part of the OS X IDLE clean up. ---------- assignee: ned.deily components: IDLE, Macintosh files: issue_osx_menu_accelerators.patch keywords: patch messages: 127371 nosy: georg.brandl, ned.deily priority: high severity: normal stage: commit review status: open title: Fix OS X IDLE menu accelerators for Save As and Save Copy type: behavior versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20593/issue_osx_menu_accelerators.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 04:17:33 2011 From: report at bugs.python.org (Ned Deily) Date: Sat, 29 Jan 2011 03:17:33 +0000 Subject: [New-bugs-announce] [issue11053] OS X IDLE 3 with Tk 8.4 appears to hang with syntax error In-Reply-To: <1296271053.35.0.843403013415.issue11053@psf.upfronthosting.co.za> Message-ID: <1296271053.35.0.843403013415.issue11053@psf.upfronthosting.co.za> New submission from Ned Deily : When IDLE 3 is used with Aqua Tk 8.4 on OS X (as is the case with the 32-bit-only installer for Python 3.1.x or 3.2rc1), if the user tries to run a Python program with a syntax error from an editor window, the Run command causes the IDLE shell window to move to the front, generally obscuring the editor window. For some unknown reason, a slight change between IDLE 2.x and IDLE 3.x causes the resulting modal Syntax Error message window to drop down from and be attached to the menu bar of the Editor Window. With Aqua Tk 8.4, the modal error only responds to a mouse click on the obscured Editor window's menu bar. To an unsuspecting user, it appears that IDLE is hung. In IDLE 2.x, the resulting modal error message is a top-level one, so it appears in a separate, unobscured window, the same as all other error messages in IDLE 2.x and 3.x. From the svn checkin early in the Python 3 development cycle, it is not at all clear why this minor change was made but it causes a major usability problem for OS X users. The attached patch reverts the change in this case restoring the behavior of IDLE 2.x. This fix should be applied to 3.2rc2. ---------- assignee: ned.deily files: issue_syntax_error_message.patch keywords: patch messages: 127375 nosy: benjamin.peterson, georg.brandl, ned.deily priority: release blocker severity: normal stage: commit review status: open title: OS X IDLE 3 with Tk 8.4 appears to hang with syntax error type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20594/issue_syntax_error_message.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 04:47:07 2011 From: report at bugs.python.org (Ned Deily) Date: Sat, 29 Jan 2011 03:47:07 +0000 Subject: [New-bugs-announce] [issue11054] OS X installer build script for 3.2 can no longer build with system Python on OS X 10.5 In-Reply-To: <1296272827.91.0.103223659215.issue11054@psf.upfronthosting.co.za> Message-ID: <1296272827.91.0.103223659215.issue11054@psf.upfronthosting.co.za> New submission from Ned Deily : During the 3.2rc1 release cycle, it was discovered that it was no longer possible to build the 32-bit installer on OS X 10.5 as customary with the system Python 2.5 due to an inadvertent 2.6 feature ("with") added to the OS X installer build script. This unnecessarily complicates the installer build process and violates past attempts to keep the installer script buildable with the system Python and compatible across current Python 2.x and 3.x releases. The attached patch to the installer script removes the "with", properly guards a new Python 3 only build step, and updates the comments and README file. The patched build script has been tested on both OS X 10.5 and 10.6. This patch should be included in 3.2rc2. ---------- assignee: ned.deily components: Build, Macintosh files: issue_synch_installer_py3k.patch keywords: patch messages: 127377 nosy: georg.brandl, ned.deily, ronaldoussoren priority: release blocker severity: normal stage: patch review status: open title: OS X installer build script for 3.2 can no longer build with system Python on OS X 10.5 versions: Python 3.2 Added file: http://bugs.python.org/file20595/issue_synch_installer_py3k.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 05:03:38 2011 From: report at bugs.python.org (Ned Deily) Date: Sat, 29 Jan 2011 04:03:38 +0000 Subject: [New-bugs-announce] [issue11055] OS X IDLE 3.2 Save As menu accelerator opens two Save windows In-Reply-To: <1296273818.82.0.517737090521.issue11055@psf.upfronthosting.co.za> Message-ID: <1296273818.82.0.517737090521.issue11055@psf.upfronthosting.co.za> New submission from Ned Deily : With the menu accelerators corrected (as patched in Issue10940), IDLE 3.2 with Cocoa Tk 8.5 opens two Save As dialog windows instead of one. This doesn't happen when the Save As item is selected with the mouse nor does it happen with Carbon Tk 8.4. The simple workaround is to dismiss the second dialog window. This can be investigated and fixed post 3.2 release. ---------- assignee: ned.deily components: IDLE, Macintosh messages: 127378 nosy: ned.deily priority: normal severity: normal stage: needs patch status: open title: OS X IDLE 3.2 Save As menu accelerator opens two Save windows versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 11:07:26 2011 From: report at bugs.python.org (nw) Date: Sat, 29 Jan 2011 10:07:26 +0000 Subject: [New-bugs-announce] [issue11056] 2to3 fails for inner __metaclass__ class definition In-Reply-To: <1296295646.41.0.555218890155.issue11056@psf.upfronthosting.co.za> Message-ID: <1296295646.41.0.555218890155.issue11056@psf.upfronthosting.co.za> New submission from nw : The attached code is not converted properly. No warning either. Eventually it may be a good idea to reintroduce the old more versatile method. ---------- components: 2to3 (2.x to 3.0 conversion tool) files: test.py messages: 127394 nosy: Nils.Winter priority: normal severity: normal status: open title: 2to3 fails for inner __metaclass__ class definition Added file: http://bugs.python.org/file20598/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 11:38:21 2011 From: report at bugs.python.org (Kelsey) Date: Sat, 29 Jan 2011 10:38:21 +0000 Subject: [New-bugs-announce] [issue11057] Missing DistutilsOptionError In-Reply-To: <1296297501.69.0.98662936413.issue11057@psf.upfronthosting.co.za> Message-ID: <1296297501.69.0.98662936413.issue11057@psf.upfronthosting.co.za> New submission from Kelsey : Missing DistutilsOptionError import in distutil2.config causes the following error: Traceback (most recent call last): File "/opt/OpenPython-2.7.1/lib/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/opt/OpenPython-2.7.1/lib/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/run.py", line 181, in main() File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/run.py", line 176, in main return commands_main() File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/run.py", line 90, in commands_main dist.parse_config_files() File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/dist.py", line 307, in parse_config_files return self.config.parse_config_files(filenames) File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/config.py", line 193, in parse_config_files self._read_setup_cfg(parser) File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/config.py", line 113, in _read_setup_cfg raise DistutilsOptionError(msg) NameError: global name 'DistutilsOptionError' is not defined ---------- assignee: tarek components: Distutils2 messages: 127396 nosy: eric.araujo, kelseyhightower, tarek priority: normal severity: normal status: open title: Missing DistutilsOptionError type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 12:27:01 2011 From: report at bugs.python.org (Kelsey) Date: Sat, 29 Jan 2011 11:27:01 +0000 Subject: [New-bugs-announce] [issue11058] dist directory not created when running sdist command In-Reply-To: <1296300421.59.0.468968378526.issue11058@psf.upfronthosting.co.za> Message-ID: <1296300421.59.0.468968378526.issue11058@psf.upfronthosting.co.za> New submission from Kelsey : When trying to create a source distribution, I get the following error and no stack trace: [openpython:yamlconfig]$ /opt/OpenPython-2.7.1/bin/python -m distutils2.run sdist WARNING:root:warning: no files found matching 's' WARNING:root:warning: no files found matching 'e' WARNING:root:warning: no files found matching 't' WARNING:root:warning: no files found matching 'u' WARNING:root:warning: no files found matching 'p' WARNING:root:warning: no files found matching '.' WARNING:root:warning: no files found matching 'p' WARNING:root:warning: no files found matching 'y' error: dist/yamlconfig-0.3.1.tar.gz: No such file or directory Not sure what all the WARNINGs are for, will file a separate issue for those. ---------- assignee: tarek components: Distutils2 messages: 127401 nosy: eric.araujo, kelseyhightower, tarek priority: normal severity: normal status: open title: dist directory not created when running sdist command type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 13:42:41 2011 From: report at bugs.python.org (Steffen Daode Nurpmeso) Date: Sat, 29 Jan 2011 12:42:41 +0000 Subject: [New-bugs-announce] [issue11059] code.python.org repo failures introduced! In-Reply-To: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za> Message-ID: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za> New submission from Steffen Daode Nurpmeso : ... because i don't know where to place this message, i do place it here. Whatever has happened in the last 90 minutes, cloning from code.python.org/hg results in mercurial panics! Please see http://mercurial.selenic.com/bts/issue2239 for more on that. Have a nice weekend. ---------- messages: 127408 nosy: sdaoden priority: normal severity: normal status: open title: code.python.org repo failures introduced! type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 15:55:44 2011 From: report at bugs.python.org (Godefroid Chapelle) Date: Sat, 29 Jan 2011 14:55:44 +0000 Subject: [New-bugs-announce] [issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za> Message-ID: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za> New submission from Godefroid Chapelle : sdist does not complain about version = 0.4.5dev which is not PEP 386 compliant ---------- assignee: tarek components: Distutils2 messages: 127425 nosy: eric.araujo, gotcha, tarek priority: normal severity: normal status: open title: distutils2 sdist does not complain about version that is not PEP 386 compliant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 16:20:55 2011 From: report at bugs.python.org (Sebastien Douche) Date: Sat, 29 Jan 2011 15:20:55 +0000 Subject: [New-bugs-announce] [issue11061] Verify command option before parsing config file In-Reply-To: <1296314455.37.0.770288704329.issue11061@psf.upfronthosting.co.za> Message-ID: <1296314455.37.0.770288704329.issue11061@psf.upfronthosting.co.za> New submission from Sebastien Douche : Distutils2 verify command (like sdist) when he use it. A small optimization is add the verification step at launch. ---------- assignee: tarek components: Distutils2 messages: 127432 nosy: eric.araujo, sdouche, tarek priority: normal severity: normal status: open title: Verify command option before parsing config file type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 17:19:36 2011 From: report at bugs.python.org (R. David Murray) Date: Sat, 29 Jan 2011 16:19:36 +0000 Subject: [New-bugs-announce] [issue11062] mailbox fails to round-trip a file to a Babyl mailbox In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> Message-ID: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za> New submission from R. David Murray : One of the new tests introduced for #9124 fails for the Bably mailbox format. The failing tests pass a file to the add method (test_add_binary_file, test_add_nonascii_binary_file, test_add_text_file_warns). The failing part of the tests have been temporarily disabled for the Bably mailbox format since it is a pre-existing, unreported bug. ---------- components: Library (Lib) keywords: easy messages: 127434 nosy: r.david.murray priority: normal severity: normal stage: needs patch status: open title: mailbox fails to round-trip a file to a Babyl mailbox type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 18:11:00 2011 From: report at bugs.python.org (Keith Dart) Date: Sat, 29 Jan 2011 17:11:00 +0000 Subject: [New-bugs-announce] [issue11063] uuid.py module import has heavy side effects In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za> Message-ID: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za> New submission from Keith Dart : When the uuid.py module is simply imported it has the side effect of forking a subprocess (/sbin/ldconfig) and doing a lot of stuff find a uuid implementation by ctypes. This is undesirable in many contexts. It would be better to perform those tasks on demand, when the first UUID is actually requested. In general, imports should avoid unnecessary system call side effects. This also makes testing easier. ---------- components: Library (Lib) messages: 127442 nosy: Keith.Dart priority: normal severity: normal status: open title: uuid.py module import has heavy side effects type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 19:08:52 2011 From: report at bugs.python.org (Dustin Farris) Date: Sat, 29 Jan 2011 18:08:52 +0000 Subject: [New-bugs-announce] [issue11064] abc documentation version conflict In-Reply-To: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za> Message-ID: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za> New submission from Dustin Farris : Running help(abc) in Python 2.6.1 displays syntax for Py3k. ---------- assignee: docs at python components: Documentation messages: 127453 nosy: docs at python, dustin.farris priority: normal severity: normal status: open title: abc documentation version conflict type: behavior versions: Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 20:12:30 2011 From: report at bugs.python.org (Ned Batchelder) Date: Sat, 29 Jan 2011 19:12:30 +0000 Subject: [New-bugs-announce] [issue11065] Fatal "can't locate locale" errors when zip file with directories is on the PYTHONPATH. In-Reply-To: <1296328350.27.0.0987051728598.issue11065@psf.upfronthosting.co.za> Message-ID: <1296328350.27.0.0987051728598.issue11065@psf.upfronthosting.co.za> New submission from Ned Batchelder : Run this shell script against 3.2, and it will fail. Against 3.1, it succeeds. I've been running tests on Ubuntu 10.10. mkdir -p sub cat >sub/modzip.py < _______________________________________ From report at bugs.python.org Sat Jan 29 22:15:41 2011 From: report at bugs.python.org (Pierre Quentel) Date: Sat, 29 Jan 2011 21:15:41 +0000 Subject: [New-bugs-announce] [issue11066] cgi.py proposals : sys.stdout encoding + rewriting of parsing functions In-Reply-To: <1296335741.52.0.506773731017.issue11066@psf.upfronthosting.co.za> Message-ID: <1296335741.52.0.506773731017.issue11066@psf.upfronthosting.co.za> New submission from Pierre Quentel : Python 3.2rc1 introduced a new version of cgi.py that handles correctly file uploads In this version, the FieldStorage constructor receives an argument "encoding" which is the encoding used by the document holding the submitted form On the CGI script side, there is currently no easy way to print the received form fields with another encoding than sys.stdout.encoding. The proposed version introduces a function, set_stdout_encoding(charset), which can be used in the CGI script to set sys.stdout to an instance of a class that uses the charset encoding. This way, print() will use this encoding. "charset" must be the encoding defined in the content-type header sent by the CGI scrpt This class (IOMix) was written by Glen Linderman and proposed in the 3.2rc1 version, but no consensus could be reached on time for the release Another proposed change is a rewriting of the module-level functions parse() and parse_multipart() : they now use the FieldStorage methods instead ---------- components: Library (Lib) files: cgi_20110129.diff keywords: patch messages: 127487 nosy: quentel priority: normal severity: normal status: open title: cgi.py proposals : sys.stdout encoding + rewriting of parsing functions type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file20612/cgi_20110129.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 22:34:47 2011 From: report at bugs.python.org (Peter Eisentraut) Date: Sat, 29 Jan 2011 21:34:47 +0000 Subject: [New-bugs-announce] [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za> Message-ID: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za> New submission from Peter Eisentraut : When setting Py_LIMITED_API, functions such as PyUnicode_Check() can no longer be used. Example: #define Py_LIMITED_API #include void foo() { PyObject *o; PyUnicode_Check(o); } test.c: In function ?foo?: test.c:9: error: dereferencing pointer to incomplete type PEP 384 contains some nested language that suggests that the _Check macros should be available under the limited API. And it seems to me that they easily could be, if Py_TYPE were implemented as a function instead of a macro. ---------- components: None messages: 127488 nosy: petere priority: normal severity: normal status: open title: Py_LIMITED_API breaks most PySomething_Check() functions versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 29 23:21:42 2011 From: report at bugs.python.org (David Meier) Date: Sat, 29 Jan 2011 22:21:42 +0000 Subject: [New-bugs-announce] [issue11068] Python 2.7.1 Idle Segmentation Fault OS X (10.6.6) In-Reply-To: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za> Message-ID: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za> New submission from David Meier : After IDLE launches I select 'File->Open' browse to a blank .py file, when I select the particular file I get the segfault below... silverbox:~ user$ (idle&) silverbox:~ user$ Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/run.py", line 93, in main seq, request = rpc.request_queue.get(block=True, timeout=0.05) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Queue.py", line 177, in get self.not_empty.wait(remaining) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 257, in wait _sleep(delay) TypeError: 'int' object is not callable ---------- components: IDLE messages: 127492 nosy: David.Meier priority: normal severity: normal status: open title: Python 2.7.1 Idle Segmentation Fault OS X (10.6.6) type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 30 03:36:17 2011 From: report at bugs.python.org (Yakov Blum) Date: Sun, 30 Jan 2011 02:36:17 +0000 Subject: [New-bugs-announce] [issue11069] IDLE crashes when Stack Viewer opened In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za> Message-ID: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za> New submission from Yakov Blum : This problem was asked about on Stack Overflow, where there's some more information on it: http://stackoverflow.com/questions/4046021/python-idle-windows-pressing-stack-viewer-exits-all-idle-windows But I didn't see it listed as a bug here. I've also experienced it in Python 3.1.3 ---------- components: IDLE messages: 127509 nosy: Yakov.Blum priority: normal severity: normal status: open title: IDLE crashes when Stack Viewer opened type: crash versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 30 03:56:04 2011 From: report at bugs.python.org (rmtew) Date: Sun, 30 Jan 2011 02:56:04 +0000 Subject: [New-bugs-announce] [issue11070] test_capi crashes and fails In-Reply-To: <1296356164.16.0.546388773568.issue11070@psf.upfronthosting.co.za> Message-ID: <1296356164.16.0.546388773568.issue11070@psf.upfronthosting.co.za> New submission from rmtew : OS: Windows 7 Compiler: Visual Studio 2008 Build: Win32 (Debug and Release) The main problem is observed in both debug and release builds, and even though the test effectively passes in both it also fails in release build. ** In a debug build I see the following: test_instancemethod (__main__.CAPITest) ... ok test_no_FatalError_infinite_loop (__main__.CAPITest) ... Then a dialog pops up telling me that Python has crashed. The unit test execution pauses until this dialog is dealt with. This then becomes: test_no_FatalError_infinite_loop (__main__.CAPITest) ... ok And the unit tests proceed to pass. ** In a release build I see the following: test_instancemethod (__main__.CAPITest) ... ok test_no_FatalError_infinite_loop (__main__.CAPITest) ... Then the crash dialog also pops up. Dismissing it results in the test failing however. test_no_FatalError_infinite_loop (__main__.CAPITest) ... FAIL ====================================================================== FAIL: test_no_FatalError_infinite_loop (__main__.CAPITest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_capi.py", line 50, in test_no_FatalError_infinite_loop b'Fatal Python error:' AssertionError: b"Fatal Python error: PyThreadState_Get: no current thread\n\r\nThis application has requested the Runtime to terminate it in an unusual way.\nPlease contact the application's support team for more information." != b'Fatal Python error: PyThreadState_Get: no current thread' Is there some information I am missing somewhere (that I have not found via googling) or is this part of the gauntlet of unit test execution on Python now? ---------- components: Tests, Windows messages: 127512 nosy: rmtew priority: normal severity: normal status: open title: test_capi crashes and fails type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 30 14:29:45 2011 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 30 Jan 2011 13:29:45 +0000 Subject: [New-bugs-announce] [issue11071] What's New review comments In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za> Message-ID: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za> New submission from Nick Coghlan : Reviewing the What's New docs, this seemed like the easiest way to give Raymond a list of things I noticed: - first sentence in the "ast" module section needs rewording (currently includes fragments from a couple of different phrasings) - in the "dis" module section, dis.dis has also acquired the ability to disassemble source string directly, avoiding the need to compile them manually first (see issue 6507). - in the "dbm" module section, there is another case of a sentence containing fragments from two different phrasings - the new "handler of last resort" functionality in the logging module deserves a mention (see issue 10626 and the explanation at http://docs.python.org/dev/howto/logging.html#what-happens-if-no-configuration-is-provided) - Vinay's rewrite of the logging module docs to be significantly more approachable (by splitting them into the raw logging API docs and the "read-as-much-as-you-need-to" logging HOWTO) is also a notable and welcome change. ---------- assignee: rhettinger components: Documentation messages: 127529 nosy: ncoghlan, rhettinger priority: normal severity: normal status: open title: What's New review comments versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 00:37:31 2011 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 30 Jan 2011 23:37:31 +0000 Subject: [New-bugs-announce] [issue11072] Add MLSD command support to ftplib In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za> Message-ID: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za> New submission from Giampaolo Rodola' : >From RFC-3659: The MLST and MLSD commands are intended to standardize the file and directory information returned by the server-FTP process. These commands differ from the LIST command in that the format of the replies is strictly defined although extensible. The patch in attachment adds support for MLSD command. This should ease the development of ftp clients which are forced to parse un-standardized LIST responses via dir() or retrlines() methods to obtain meaningful data for the directory listing. Example: >>> import ftplib >>> from pprint import pprint as pp >>> f = ftplib.FTP() >>> f.connect("localhost") >>> f.login("anonymous") >>> ls = f.mlsd() >>> pp(ls) {'modify': 20100814164724, 'name': 'svnmerge.py', 'perm': 'r', 'size': 90850, 'type': 'file', 'unique': '80718b568'}, {'modify': 20101207185033, 'name': 'README', 'perm': 'r', 'size': 53731, 'type': 'file', 'unique': '80718aafe'}, {'modify': 20100417183215, 'name': 'install-sh', 'perm': 'r', 'size': 7122, 'type': 'file', 'unique': '80718b2d2'}, {'modify': 20110129210053, 'name': 'Include', 'perm': 'el', 'size': 4096, 'type': 'dir', 'unique': '8071a2bc4'}] >>> ---------- files: ftplib_mlsd.patch keywords: patch messages: 127562 nosy: giampaolo.rodola, pitrou priority: normal severity: normal status: open title: Add MLSD command support to ftplib versions: Python 3.3 Added file: http://bugs.python.org/file20623/ftplib_mlsd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 02:42:52 2011 From: report at bugs.python.org (Roy Smith) Date: Mon, 31 Jan 2011 01:42:52 +0000 Subject: [New-bugs-announce] [issue11073] threading.Thread documentation can be improved In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za> Message-ID: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za> New submission from Roy Smith : The documentation for the threading.Thread constructor says: "target is the callable object to be invoked by the run() method. Defaults to None, meaning nothing is called." This could be improved by explicitly stating that target is called in a static context. As written, it takes a bit of thought (and experimentation) to be sure of that. ---------- assignee: docs at python components: Documentation messages: 127566 nosy: docs at python, roysmith priority: normal severity: normal status: open title: threading.Thread documentation can be improved versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 05:04:11 2011 From: report at bugs.python.org (Brett Cannon) Date: Mon, 31 Jan 2011 04:04:11 +0000 Subject: [New-bugs-announce] [issue11074] fix tokenize so it can be reloaded In-Reply-To: <1296446651.43.0.796363573653.issue11074@psf.upfronthosting.co.za> Message-ID: <1296446651.43.0.796363573653.issue11074@psf.upfronthosting.co.za> New submission from Brett Cannon : The tokenize module stores the built-in open() module in a global assignment statement. Problem is that if you reload the module, that global assignment picks up the module's own open() that came into existence during the initial import. The attached patch fixes this by having tokenize.open() use builtins.open() instead of its own cached global version. ---------- assignee: georg.brandl components: Library (Lib) files: tokenize_reload.diff keywords: easy, patch messages: 127570 nosy: brett.cannon, georg.brandl, haypo priority: normal severity: normal stage: commit review status: open title: fix tokenize so it can be reloaded type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file20624/tokenize_reload.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 06:26:32 2011 From: report at bugs.python.org (Alex McNerney) Date: Mon, 31 Jan 2011 05:26:32 +0000 Subject: [New-bugs-announce] [issue11075] Turtle crash with IDLE on Mac OS X 10.6 In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za> Message-ID: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za> New submission from Alex McNerney : Info: I have Python 2.7.1:86832 (32-bit) installed using ActiveState Tcl/Tk 8.5.9 on Mac OS X 10.6 Problem: Whenever I try to run (from the IDLE) a Python script using the turtle module, the window that shows up will draw anything passed to it, but it will not come to the front using the listen() function, nor will clicking on the window do anything more than cause the spinning beach ball to appear. Because it does not come the the foreground, functions like onkey() and onclick() are completely unusable. However, when said Python script is run from the Terminal, the window is completely responsive. I believe this to be some sort of problem with the IDLE.app Things that I have tried: Tried different versions of tcl/tk: 8.4.19, 8.4.7, 8.5.9 Tried different versions of Python 2.7.1: 32-bit, 32/64-bit, 32-bit compiled from source. Other things that may be useful: This probably has no relevancy, but just in case: In the .mpkg installed Python 2.7.1 (32-bit), the IDLE says the GCC version is 4.0.1 In the source compiled version, it says 4.2.1 It is quite annoying to not be able to use the IDLE to create and test programs using the turtle module. Please help. ---------- assignee: ronaldoussoren components: IDLE, Macintosh, Tkinter messages: 127577 nosy: amcnerney13, ronaldoussoren priority: normal severity: normal status: open title: Turtle crash with IDLE on Mac OS X 10.6 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 09:05:03 2011 From: report at bugs.python.org (Virgil Dupras) Date: Mon, 31 Jan 2011 08:05:03 +0000 Subject: [New-bugs-announce] [issue11076] Iterable argparse Namespace In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za> Message-ID: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za> New submission from Virgil Dupras : Currently, there is no (documented) way to easily extract arguments in an argparse Namespace as a dictionary. This way, it would me easy to interface a function taking a lot of kwargs like this: >>> args = parser.parse_args() >>> my_function(**dict(args)) There's "_get_kwargs()" but it's a private undocumented method. I guess that making it public would be problematic because of the namespace pollution that would occur. That's why I'm proposing to make it iterable. If it isn't rejected, I'd gladly work on the required patch. ---------- components: Library (Lib) keywords: easy messages: 127582 nosy: vdupras priority: normal severity: normal status: open title: Iterable argparse Namespace type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 16:40:32 2011 From: report at bugs.python.org (Scott M) Date: Mon, 31 Jan 2011 15:40:32 +0000 Subject: [New-bugs-announce] [issue11077] Tkinter is not thread safe. This is a bug. In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za> Message-ID: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za> New submission from Scott M : The more I look at GUI support in Python, the more I realize that the lack of basic thread safety in GUI support is simply a bug. I know Java's Swing has the same thread limitation, but that doesn't make it right. Xlib is thread safe. The Windows SDK is thread safe. Python is supposed to be the language that's easy to use, and there is nothing easy about teaching new programmers that they have to mess with queues and timers just to get a basic set of displays running, just because when threads are in use. I'm in the position of teaching folk with little-to-no programming experience, how to script simple applications in Python. The modules they have to use are inherently threaded, and delivery hunks of data from multiple sources to them. The most natural instinct is to put up some graphs and other widgits to display the data, and all of it is completely trivial right up until I have to explain that drawing a line isn't canvas.line(from, to), but becomes an exercise in Queue.Queue and theRoot.after(n, myself), before you even get to learn about widgits. Threading is supposed to simplify problems, not add to them. Having to hack around with special timers and polling, just to get some simple graphs up, is plain unpythonic. Please consider this a bug, a glaring misfeature, in a language that is otherwise a very reasonable choice to get technical but non-programmerish people into toolmaking self-sufficiency. ---------- components: Tkinter messages: 127604 nosy: PythonInTheGrass priority: normal severity: normal status: open title: Tkinter is not thread safe. This is a bug. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 16:55:33 2011 From: report at bugs.python.org (R. David Murray) Date: Mon, 31 Jan 2011 15:55:33 +0000 Subject: [New-bugs-announce] [issue11078] Have test___all__ check for duplicates In-Reply-To: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za> Message-ID: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za> New submission from R. David Murray : Inspired by what happened in issue 8973, I offer the attached patch for test__all__ to have it check the __all__ list for duplicates. Interestingly, the first failure is not in struct, but in os. Obviously the patch can't be applied until the test succeeds, so I'll be coming back to this later. Figured I'd post the test patch in case anyone else wants to play with fixing things before I get to it. ---------- components: Tests files: check_all_for_duplicates.patch keywords: patch messages: 127608 nosy: SilentGhost, pitrou, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Have test___all__ check for duplicates type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file20627/check_all_for_duplicates.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 17:19:03 2011 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 31 Jan 2011 16:19:03 +0000 Subject: [New-bugs-announce] [issue11079] Make OS X entry in Applications like that in Windows In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za> Message-ID: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za> New submission from Raymond Hettinger : In Applications, the 3.2 entry includes: * Python Launcher * IDLE * Update Shell.Profile Command * Extras directory The latter should be dropped (most of the tools only make sense from the command-line) and should be replaced by a link to the docs: file:///Library/Frameworks/Python.framework/Versions/3.2/Resources/English.lproj/Documentation/index.html This setup better matches what we offer in Windows and it makes the docs more accessible. The Windows setup also includes an uninstall option. It would be nice if OS X did the same, but I don't know if that is the way of the Mac. ---------- assignee: ned.deily components: Build messages: 127612 nosy: ned.deily, rhettinger, ronaldoussoren priority: normal severity: normal status: open title: Make OS X entry in Applications like that in Windows versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 17:58:55 2011 From: report at bugs.python.org (Terry M. Topka) Date: Mon, 31 Jan 2011 16:58:55 +0000 Subject: [New-bugs-announce] [issue11080] Win32Serial.read coding error for non-blocking read In-Reply-To: <1296493135.79.0.311076655892.issue11080@psf.upfronthosting.co.za> Message-ID: <1296493135.79.0.311076655892.issue11080@psf.upfronthosting.co.za> New submission from Terry M. Topka : Attempting to read a fixed amount of data when the serial port is configured for non-blocking reads (i.e. self.timeout == 0) will occasionally throw an invalid memory access exception, due to an error in the following code: ### pyserial-2.5-rc2 serialWin32.py Line 219 if self.timeout == 0: n = min(comstat.cbInQue, size) if n > 0: buf = ctypes.create_string_buffer(n) rc = win32.DWORD() err = win32.ReadFile(self.hComPort, buf, size, ctypes.byref(rc), ctypes.byref(self._overlappedRead)) The buffer length passed to win32.ReadFile should be 'n', not 'size'. This may not have been noticed since it is timing dependent: only if additional input is enqueued inbetween accessing the input queue length and the ReadFile call will the inappropriate invalid memory access exception be raised when 'size' is greater than 'n'. ---------- components: Extension Modules, Windows files: serialwin32.py messages: 127619 nosy: tmtopka priority: normal severity: normal status: open title: Win32Serial.read coding error for non-blocking read type: crash versions: 3rd party, Python 2.6 Added file: http://bugs.python.org/file20628/serialwin32.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 18:21:59 2011 From: report at bugs.python.org (SilentGhost) Date: Mon, 31 Jan 2011 17:21:59 +0000 Subject: [New-bugs-announce] [issue11081] from struct import * misses pack_into In-Reply-To: <1296494519.33.0.0318665786587.issue11081@psf.upfronthosting.co.za> Message-ID: <1296494519.33.0.0318665786587.issue11081@psf.upfronthosting.co.za> New submission from SilentGhost : the following issue was introduced in r81947: >>> from struct import * >>> pack_into Traceback (most recent call last): File "", line 1, in pack_into NameError: name 'pack_into' is not defined struct.__all__ has a duplicate entry for "unpack" and misses "pack_into". Patch is attached, test passes. Seems quite innocent to me, could it make into 3.2, George? Related: #8973 and #11078 ---------- components: Library (Lib) files: struct.py.diff keywords: easy, patch messages: 127625 nosy: SilentGhost, belopolsky, georg.brandl, mark.dickinson priority: normal severity: normal status: open title: from struct import * misses pack_into type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file20629/struct.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 20:18:12 2011 From: report at bugs.python.org (William Wu) Date: Mon, 31 Jan 2011 19:18:12 +0000 Subject: [New-bugs-announce] [issue11082] ValueError: Content-Length should be specified In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za> Message-ID: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za> New submission from William Wu : I found this bug when I started to trying Python 3.2 release candidate 1. When using urllib.request.urlopen to handle HTTP POST, I got the error message: ValueError: Content-Length should be specified for iterable data of type 'foo=bar' I'll attach the patch and test case. ---------- components: Library (Lib) messages: 127646 nosy: William.Wu priority: normal severity: normal status: open title: ValueError: Content-Length should be specified type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 20:22:23 2011 From: report at bugs.python.org (Federico Culloca) Date: Mon, 31 Jan 2011 19:22:23 +0000 Subject: [New-bugs-announce] [issue11083] threading.Thread - start() rises RuntimeException? In-Reply-To: <1296501743.29.0.748896290236.issue11083@psf.upfronthosting.co.za> Message-ID: <1296501743.29.0.748896290236.issue11083@psf.upfronthosting.co.za> New submission from Federico Culloca : In the threading module documentation, about the start() method of the threading.Thread class, it says that, upon calling start() more then once, a RuntimeException is raised. I couldn't find in the whole documentation other references to this "RuntimeException". Maybe it's RuntimeError? ---------- assignee: docs at python components: Documentation messages: 127647 nosy: Federico.Culloca, docs at python priority: normal severity: normal status: open title: threading.Thread - start() rises RuntimeException? type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 20:37:31 2011 From: report at bugs.python.org (GDR!) Date: Mon, 31 Jan 2011 19:37:31 +0000 Subject: [New-bugs-announce] [issue11084] Serialization of decimal.Decimal to XML-RPC In-Reply-To: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za> Message-ID: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za> New submission from GDR! : xmlrpc.client (and xmlrpclib in 2.x) can't serialize instances of Decimal, throwing TypeError instead. Because XML is a textual format, converting from decimal to float may cause loss of data. According to http://www.xmlrpc.com/spec, encoding Decimal as XML-RPC is allowed: "The range of allowable values is implementation-dependent, is not specified." Therefore, including decimal numbers that can not be represented by IEEE double is allowed by the spec. Also, in my opinion, making a numeric type available in standard library unsupported by another part of standard library, is counterintuitive, but it's just my personal point of view. I can provide a patch if this bug report is considered proper. ---------- components: Library (Lib) messages: 127651 nosy: gdr priority: normal severity: normal status: open title: Serialization of decimal.Decimal to XML-RPC type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 20:44:26 2011 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 31 Jan 2011 19:44:26 +0000 Subject: [New-bugs-announce] [issue11085] expose _abcoll as collections.abc In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za> Message-ID: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za> New submission from Raymond Hettinger : For the 3.3, make _abcoll (which is full of the collections abstract base classes) visible as a module called collections.abc and document that as the preferred way to access them. For backwards compatibility, continue to import the names directly into the collections.py namespace so that no one has to change existing code. Background: Experience with teaching ABCs and dealing with bug reports has shown that it is creating some confusion having the long list of abstract APIs commingled with the concrete APIs (for example, seeing collections.Mapping and thinking it is one of the various concrete types in the collections module). If it were to become a practice to write collections.abc.Mapping, it would be immediately clear that an ABC was being used rather than a concrete class like OrderedDict. The other reason to separate them is that the use cases tend to be different. People look to the abstract APIs either for a specification (reference purposes), for mixin methods (aid in building their own classes), or for registration (to control isinstance and issubclass). In contrast, people use concrete APIs directly for managing data. Accordingly, it makes senses to group the two different types of tools into separate toolboxes. ---------- components: Library (Lib) messages: 127652 nosy: rhettinger priority: low severity: normal status: open title: expose _abcoll as collections.abc type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 31 21:52:47 2011 From: report at bugs.python.org (Brett Cannon) Date: Mon, 31 Jan 2011 20:52:47 +0000 Subject: [New-bugs-announce] [issue11086] add lib2to3/__main__.py In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za> Message-ID: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za> New submission from Brett Cannon : There is no reason why the 2to3 script can't be gutted and turned into just a stub that uses runpy to call lib2to3.__main__. Also has the nice benefit that one can use ``-m lib2to3`` instead of having to use the 2to3 script. ---------- components: Library (Lib) keywords: easy messages: 127659 nosy: brett.cannon priority: low severity: normal stage: needs patch status: open title: add lib2to3/__main__.py versions: Python 3.3 _______________________________________ Python tracker _______________________________________