From report at bugs.python.org Wed Dec 1 01:20:26 2010 From: report at bugs.python.org (Elias Zamaria) Date: Wed, 01 Dec 2010 00:20:26 +0000 Subject: [New-bugs-announce] [issue10592] pprint module doesn't work well with OrderedDicts In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za> Message-ID: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za> New submission from Elias Zamaria : If I try to pretty-print an ordered dictionary, it doesn't show nicely. Instead of having each key-value pair on its own line, the whole thing shows up on one long line, which wraps many times and is hard to read. I can provide an example if you want. Is there a way to make it print nicely, like the old unordered dictionaries? ---------- components: Library (Lib) messages: 122963 nosy: mikez302 priority: normal severity: normal status: open title: pprint module doesn't work well with OrderedDicts type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 1 02:01:59 2010 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 01 Dec 2010 01:01:59 +0000 Subject: [New-bugs-announce] [issue10593] LRU Cache with maxsize=None In-Reply-To: <1291165319.63.0.0975088318832.issue10593@psf.upfronthosting.co.za> Message-ID: <1291165319.63.0.0975088318832.issue10593@psf.upfronthosting.co.za> New submission from Raymond Hettinger : Nick, I may have found a straight-forward way to incorporate your idea for the cache to support maxsize=None. Let me know what you think. ---------- assignee: ncoghlan components: Library (Lib) files: cache.diff keywords: patch messages: 122967 nosy: ncoghlan, rhettinger priority: low severity: normal status: open title: LRU Cache with maxsize=None type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file19886/cache.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 1 04:31:22 2010 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Dec 2010 03:31:22 +0000 Subject: [New-bugs-announce] [issue10594] Typo in PyList_New doc. In-Reply-To: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za> Message-ID: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za> New submission from INADA Naoki : http://docs.python.org/c-api/list.html#PyList_New > Note: If length is greater than zero, ... s/length/len/ ---------- assignee: docs at python components: Documentation messages: 122974 nosy: docs at python, naoki priority: normal severity: normal status: open title: Typo in PyList_New doc. versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 1 12:32:41 2010 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Wed, 01 Dec 2010 11:32:41 +0000 Subject: [New-bugs-announce] [issue10595] Adding a syslog.conf reader in syslog In-Reply-To: <1291203161.89.0.870759954789.issue10595@psf.upfronthosting.co.za> Message-ID: <1291203161.89.0.870759954789.issue10595@psf.upfronthosting.co.za> New submission from Tarek Ziad? : The syslog module allows to configure via openlog() the facility. There's one missing feature though, I'd love to have in a new API: a way to read the syslog configuration, and in particular to know where each facility file is located on the system. e.g.: >>> from syslog import get_config, LOG_AUTH >>> get_config(LOG_AUTH) {'filename': '/var/log/auth.log', some other stuff} I am not sure how easy it would be, looking at the syslog C API... ---------- components: Library (Lib) messages: 122990 nosy: jafo, tarek priority: normal severity: normal status: open title: Adding a syslog.conf reader in syslog type: feature request versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 1 12:53:19 2010 From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCl0LvRg9GC0YfQuNC9?=) Date: Wed, 01 Dec 2010 11:53:19 +0000 Subject: [New-bugs-announce] [issue10596] modulo operator bug In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za> Message-ID: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za> New submission from ?????? ??????? : Result of the modulo operator is wrong: >>> (-2.22044604925e-16)%4 4.0 >>> (-4.0)%4 -0.0 ---------- messages: 122991 nosy: Sergio.?lut?in priority: normal severity: normal status: open title: modulo operator bug type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 1 17:07:31 2010 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Dec 2010 16:07:31 +0000 Subject: [New-bugs-announce] [issue10597] Py_SetPythonHome document shows same url twice. In-Reply-To: <1291219651.16.0.0325545268519.issue10597@psf.upfronthosting.co.za> Message-ID: <1291219651.16.0.0325545268519.issue10597@psf.upfronthosting.co.za> New submission from INADA Naoki : http://docs.python.org/c-api/init.html#Py_SetPythonHome > The libraries are searched in home/lib/pythonversion and home/lib/pythonversion. Is the second "{home}/lib/python{version}" wrong? ---------- assignee: docs at python components: Documentation messages: 123000 nosy: docs at python, naoki priority: normal severity: normal status: open title: Py_SetPythonHome document shows same url twice. versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 1 21:12:58 2010 From: report at bugs.python.org (River Tarnell) Date: Wed, 01 Dec 2010 20:12:58 +0000 Subject: [New-bugs-announce] [issue10598] curses fails to import on Solaris In-Reply-To: <1291234378.99.0.641306252968.issue10598@psf.upfronthosting.co.za> Message-ID: <1291234378.99.0.641306252968.issue10598@psf.upfronthosting.co.za> New submission from River Tarnell : On Solaris 10 using system libcurses, curses fails to import: hemlock% python3.1 Python 3.1.3 (r313:86834, Dec 1 2010, 19:51:26) [GCC 4.5.1] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "/opt/ts/python/3.1/lib/python3.1/curses/__init__.py", line 57, in has_key NameError: name 'has_key' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/opt/ts/python/3.1/lib/python3.1/curses/__init__.py", line 59, in from has_key import has_key ImportError: No module named has_key >>> ---------- components: Extension Modules messages: 123007 nosy: rtarnell priority: normal severity: normal status: open title: curses fails to import on Solaris versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 1 22:21:49 2010 From: report at bugs.python.org (Michael Brooks) Date: Wed, 01 Dec 2010 21:21:49 +0000 Subject: [New-bugs-announce] [issue10599] sgmllib.parse_endtag() is not respecting quoted text In-Reply-To: <1291238509.2.0.989759336682.issue10599@psf.upfronthosting.co.za> Message-ID: <1291238509.2.0.989759336682.issue10599@psf.upfronthosting.co.za> New submission from Michael Brooks : In the attached example is a very simple usage of sgmllib that is trying to parse: The bug is that sgmllib is parsing this href. Browsers on the other hand see this as the input's value. Also keep in mind that escaping of quote marks in HTML is not like python. \" is not a character literal " thus link"> is still quoted text and the href should not be parsed. Thank you ---------- components: None files: sgmllib_bug.py messages: 123016 nosy: Michael.Brooks priority: normal severity: normal status: open title: sgmllib.parse_endtag() is not respecting quoted text type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file19895/sgmllib_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 00:24:56 2010 From: report at bugs.python.org (Campbell Barton) Date: Wed, 01 Dec 2010 23:24:56 +0000 Subject: [New-bugs-announce] [issue10600] surrogateescape'd paths not readable on Windows XP. In-Reply-To: <1291245896.91.0.824091264043.issue10600@psf.upfronthosting.co.za> Message-ID: <1291245896.91.0.824091264043.issue10600@psf.upfronthosting.co.za> New submission from Campbell Barton : Attached is a script which works in linux but not windows XP 32bit with Python 3.1.3. The problem is that the path can be written to when specified as bytes but when escaped it fails. ---------- components: IO files: utf8_surrogateescape.py messages: 123022 nosy: ideasman42 priority: normal severity: normal status: open title: surrogateescape'd paths not readable on Windows XP. versions: Python 3.1 Added file: http://bugs.python.org/file19896/utf8_surrogateescape.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 02:43:27 2010 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Dec 2010 01:43:27 +0000 Subject: [New-bugs-announce] [issue10601] sys.displayhook: use backslashreplace error handler if repr(value) is not encodable to sys.stdout In-Reply-To: <1291254207.25.0.743173639978.issue10601@psf.upfronthosting.co.za> Message-ID: <1291254207.25.0.743173639978.issue10601@psf.upfronthosting.co.za> New submission from STINNER Victor : On Windows, the Python interpreter fails to display a result if stdout encoding is unable to encode it. This problem exists since Python 3.0. Eg. see issue #1602. This problem is not specific to Windows. Even if stdout encoding is UTF-8 (which is the default encoding of Mac OS X and most Linux distributions), it fails on surrogate characters (because the UTF-8 encoder refuses surrogate characters in Python 3). Eg. see issue #5110. Even if a Python (core? :-)) developer can see this behaviour as expected, it looks like different users (including me) don't like it and would prefer to see the result instead of an unicode exception. The problem is that we don't know directly (except for simple commands) if the error comes from the command or if printing the result failed. This issue is specific to sys.displayhook, the callback used by the Python interpreter to display the result of a command. It doesn't concern print() or sys.stdout.write(). -- The best solution would be to check if the terminal is able to render a character, but this is not possible for technical reasons. The best that we can do is to catch the UnicodeEncodeError and use another error handler (than sys.stdout.errors) which doesn't fail. 'backslashreplace' is a good candidate. Ezio Melotti implemented this solution and attached a patch to issue #9198. I wrote a new version of his patch, changes: - Create a subfunction (for better readability) - Clear the UnicodeEncodeError before calling sys_displayhook_unencodable() (anyway, the exception will be lost on next error, eg. if PyObject_GetAttrString() fails) - Clear the (AttributeError) exception if PyObject_GetAttrString(outf, "buffer") fails - Add an unit test: test ASCII, ISO-8859-1 and UTF-8 with non-ASCII, surrogate and non-BMP (printable or not) characters - Complete and update sys.displayhook documentation - Fix a refleak if stdout_encoding_str == NULL - Use PyObject_CallMethod() instead of PyTuple_Pack() + PyEval_CallObject() for a shorter (and more readable) code -- I don't know how to test the case: sys.stdout.write(repr(value)) fails and sys.stdout has no buffer attribute. A mockup should maybe be used in the unit test? ---------- components: Unicode files: displayhook_unencodable.patch keywords: patch messages: 123031 nosy: belopolsky, ezio.melotti, haypo priority: normal severity: normal status: open title: sys.displayhook: use backslashreplace error handler if repr(value) is not encodable to sys.stdout versions: Python 3.2 Added file: http://bugs.python.org/file19897/displayhook_unencodable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 05:38:57 2010 From: report at bugs.python.org (Alex Earl) Date: Thu, 02 Dec 2010 04:38:57 +0000 Subject: [New-bugs-announce] [issue10602] csv test_register_kwargs has invalid message parameters In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za> Message-ID: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za> New submission from Alex Earl : in test_csv.py, the follow test is declared. def test_register_kwargs(self): name = 'fedcba' csv.register_dialect(name, delimiter=';') try: self.assertTrue(csv.get_dialect(name).delimiter, '\t') self.assertTrue(list(csv.reader('X;Y;Z', name)), ['X', 'Y', 'Z']) finally: csv.unregister_dialect(name) The assertTrue method take an expression to test for "true" and a message to display if that expression is false. If the test's goal is to test that delimiter is set so it's not None, then it will output a tab if the test fails. On the second line, the list would be displayed if the list returned from the reader is an empty list. The result of the reader operation is not the list on the right side anyway. >>> list(csv.reader('X;Y;Z', name)) [['X'], ['', ''], ['Y'], ['', ''], ['Z']] ---------- messages: 123055 nosy: Alex.Earl priority: normal severity: normal status: open title: csv test_register_kwargs has invalid message parameters type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 12:16:41 2010 From: report at bugs.python.org (Campbell Barton) Date: Thu, 02 Dec 2010 11:16:41 +0000 Subject: [New-bugs-announce] [issue10603] __file__ not usable, with certain paths on windows XP. In-Reply-To: <1291288601.2.0.284782000328.issue10603@psf.upfronthosting.co.za> Message-ID: <1291288601.2.0.284782000328.issue10603@psf.upfronthosting.co.za> New submission from Campbell Barton : # create this path. # it could be made by any application but including this line # so encoding is not confused. # c:\??? __import__("os").mkdir(b'c:\\\xe4\xf6\xfc') # Now create a new script and save in the newly created dir c:\???\test.py # In c:\???\test.py add the following line __import__("os").listdir(os.path.dirname(__file__)) # Now run the script from the command line using its absolute path. c:\Python31\python.exe c:\???\test.py --- This gives an error. Traceback (most recent call last): File "m:\\xc3\xa4\xc3\xb6\xc3?\test.py", line 2, in WindowsError: [Error 3] The system cannot find the path specified: 'm:\\\xc3\xa4\xc3\xb6\xc3?\\*.*' This is a bug because a script should be able to inspect the path where it is located. ---------- components: Interpreter Core messages: 123063 nosy: ideasman42 priority: normal severity: normal status: open title: __file__ not usable, with certain paths on windows XP. type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 13:32:35 2010 From: report at bugs.python.org (Daniel Molkentin) Date: Thu, 02 Dec 2010 12:32:35 +0000 Subject: [New-bugs-announce] [issue10604] Allocating too much memory for pathes In-Reply-To: <1291293155.82.0.689283650387.issue10604@psf.upfronthosting.co.za> Message-ID: <1291293155.82.0.689283650387.issue10604@psf.upfronthosting.co.za> New submission from Daniel Molkentin : from PC/getpathp.c:538 if (pythonhome != NULL) { char *p; bufsz = 1; for (p = PYTHONPATH; *p; p++) { if (*p == DELIM) bufsz++; /* number of DELIM plus one */ } bufsz *= strlen(pythonhome); } The second last line should probably read bufsz += strlen(pythonhome); ---------- components: Windows messages: 123067 nosy: danimo priority: normal severity: normal status: open title: Allocating too much memory for pathes versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 15:51:17 2010 From: report at bugs.python.org (Adrian Nye) Date: Thu, 02 Dec 2010 14:51:17 +0000 Subject: [New-bugs-announce] [issue10605] ElementTree documentation In-Reply-To: <1291301477.25.0.932243074052.issue10605@psf.upfronthosting.co.za> Message-ID: <1291301477.25.0.932243074052.issue10605@psf.upfronthosting.co.za> New submission from Adrian Nye : TreeBuilder doc does not mention its "entity" argument which is the main way to deal with html entity encodings which are unfortunately a common problem in XML. Also the doc needs a discussion of the relationship of TreeBuilder and XMLParser. The former has "entity", and the latter has "encoding", but what happens is you need both? Needs examples of using these two classes. ---------- components: XML messages: 123076 nosy: adrian_nye priority: normal severity: normal status: open title: ElementTree documentation type: feature request versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 17:17:02 2010 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 02 Dec 2010 16:17:02 +0000 Subject: [New-bugs-announce] [issue10606] Misspelling of Jamie Zawinski's surname in urllib.parse docstring In-Reply-To: <1291306622.05.0.84644269608.issue10606@psf.upfronthosting.co.za> Message-ID: <1291306622.05.0.84644269608.issue10606@psf.upfronthosting.co.za> New submission from Dave Malcolm : (was misspelled when issue 5650 was fixed, FWIW) ---------- assignee: orsenthil components: Library (Lib) files: py3k-fix-jwz-surname.patch keywords: patch messages: 123079 nosy: dmalcolm, orsenthil priority: low severity: normal status: open title: Misspelling of Jamie Zawinski's surname in urllib.parse docstring versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file19906/py3k-fix-jwz-surname.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 17:24:20 2010 From: report at bugs.python.org (INADA Naoki) Date: Thu, 02 Dec 2010 16:24:20 +0000 Subject: [New-bugs-announce] [issue10607] Document of PyOS_(v)snprintf is wrong. In-Reply-To: <1291307060.85.0.577085491194.issue10607@psf.upfronthosting.co.za> Message-ID: <1291307060.85.0.577085491194.issue10607@psf.upfronthosting.co.za> New submission from INADA Naoki : http://docs.python.org/c-api/conversion.html#PyOS_vsnprintf "the buffer size needed to avoid truncation exceeds size by more than 512 bytes, Python aborts with a Py_FatalError." I think ":cfunc:`vsprintf`'s output exeeds the buffer need to truncation that have *size* + 512byte length," is correct. ---------- assignee: docs at python components: Documentation messages: 123080 nosy: docs at python, naoki priority: normal severity: normal status: open title: Document of PyOS_(v)snprintf is wrong. versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 19:42:13 2010 From: report at bugs.python.org (Brian Curtin) Date: Thu, 02 Dec 2010 18:42:13 +0000 Subject: [New-bugs-announce] [issue10608] Add a section to Windows FAQ explaining os.symlink In-Reply-To: <1291315333.59.0.493313738075.issue10608@psf.upfronthosting.co.za> Message-ID: <1291315333.59.0.493313738075.issue10608@psf.upfronthosting.co.za> New submission from Brian Curtin : A section in the Windows FAQ should better explain the recent addition of os.symlink and how it can be used, along with examples. If a user just sits down and hits Start>Run>python, os.symlink will almost positively not be available. I'll need to briefly explain privileges, which one is needed, how it can be obtained, and how to properly write code on Windows to make use of os.symlink. There is documentation of os.symlink itself, but it's more of a developer reference to match the rest of the os module documentation. A beginner would likely need more information, but that information isn't right for Doc/library/os.rst. ---------- assignee: brian.curtin components: Documentation, Windows messages: 123099 nosy: brian.curtin priority: normal severity: normal stage: needs patch status: open title: Add a section to Windows FAQ explaining os.symlink type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 21:52:06 2010 From: report at bugs.python.org (Sandro Tosi) Date: Thu, 02 Dec 2010 20:52:06 +0000 Subject: [New-bugs-announce] [issue10609] dbm documentation example doesn't work (iteritems()) In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za> Message-ID: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za> New submission from Sandro Tosi : Following http://mail.python.org/pipermail/docs/2010-December/002356.html a possible solution is: diff -r 3b07f7bb0289 Doc/library/dbm.rst --- a/Doc/library/dbm.rst Thu Dec 02 19:29:18 2010 +0100 +++ b/Doc/library/dbm.rst Thu Dec 02 21:51:06 2010 +0100 @@ -88,7 +88,7 @@ # Loop through contents. Other dictionary methods # such as .keys(), .values() also work. - for k, v in db.iteritems(): + for k, v in dict(db).items(): print(k, '\t', v) # Storing a non-string key or value will raise an exception (most How much ugly is this? alternatively, we can: >>> for k in db.keys(): ... print(k, '\t', db.get(k)) What would be the best solution? (anyhow the comments above the for loop has to be changed). Regards, Sandro ---------- messages: 123113 nosy: sandro.tosi priority: normal severity: normal status: open title: dbm documentation example doesn't work (iteritems()) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 2 23:31:22 2010 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 02 Dec 2010 22:31:22 +0000 Subject: [New-bugs-announce] [issue10610] Correct the float(), int() and complex() documentation In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za> Message-ID: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg : The Python3 documentation for these numeric constructors is wrong. Python has supported Unicode numerals specified as code points from the Unicode category "Nd" (decimal digit) since Python 1.6.0 when Unicode was first introduced in Python. http://www.unicode.org/versions/Unicode5.2.0/ch04.pdf (see Section 4.5: General Category) The Python3 documentation adds a reference to the language spec which is not really ideal, since the language spec has different requirements than a number object constructor which has to deal with data input rather than program text: http://docs.python.org/dev/py3k/library/functions.html#float The Python2 documentation does not have such an implication: http://docs.python.org/library/functions.html#float The Python3 documentation needs to be extended to either mention that all Unicode code points from the Unicode category "Nd" (decimal digit) are accepted as digits and used with their corresponding decimal digit value, or include a copy of the referenced language spec section with this definition of ''digit'': digit := ::= "0"..."9" and any Unicode code point with property "Nd" Here's a complete list of the code point ranges that have this property: http://www.unicode.org/Public/5.2.0/ucd/extracted/DerivedNumericType.txt (scroll to the end of the file) It would also be worthwhile to add a note to the Python2 documentation. ---------- assignee: docs at python components: Documentation, Unicode messages: 123136 nosy: docs at python, lemburg priority: normal severity: normal status: open title: Correct the float(), int() and complex() documentation versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 3 02:25:19 2010 From: report at bugs.python.org (Michael Foord) Date: Fri, 03 Dec 2010 01:25:19 +0000 Subject: [New-bugs-announce] [issue10611] sys.exit() in a test causes the run to stp In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za> Message-ID: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za> New submission from Michael Foord : Reported by a unittest2 user. A SystemExit (or GeneratorExit) will cause a test run to stop in 2.7 / 3.2. This would just be reported as an error in 2.6. >>> from unittest import TestCase >>> def test(s): ... raise GeneratorExit ... >>> class T(TestCase): ... test = test ... >>> t = T('test') >>> t.run() Above code works in Python 2.6 (the exception is caught by TestCase.run) but dies in 2.7 / 3.2 ---------- assignee: michael.foord keywords: easy messages: 123153 nosy: michael.foord priority: normal severity: normal stage: unit test needed status: open title: sys.exit() in a test causes the run to stp type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 3 03:09:29 2010 From: report at bugs.python.org (Michael Foord) Date: Fri, 03 Dec 2010 02:09:29 +0000 Subject: [New-bugs-announce] [issue10612] StopTestRun exception to halt test run In-Reply-To: <1291342169.36.0.09336436937.issue10612@psf.upfronthosting.co.za> Message-ID: <1291342169.36.0.09336436937.issue10612@psf.upfronthosting.co.za> New submission from Michael Foord : It is hard for test infrastructure to halt a test run unless it has access to the result object. A StopTestRun exception could be provided. This could be caught in TestCase.run and call TestResult.stop(). It could be parameterized so that StopTestRun(report=False) bombs out and stops the test run completely. ---------- assignee: michael.foord components: Library (Lib) messages: 123158 nosy: michael.foord priority: normal severity: normal status: open title: StopTestRun exception to halt test run type: performance versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 3 04:09:18 2010 From: report at bugs.python.org (Charles Harris) Date: Fri, 03 Dec 2010 03:09:18 +0000 Subject: [New-bugs-announce] [issue10613] gzip._PaddedFile calls getattr with arguments in reversed order In-Reply-To: <1291345758.68.0.319851259177.issue10613@psf.upfronthosting.co.za> Message-ID: <1291345758.68.0.319851259177.issue10613@psf.upfronthosting.co.za> New submission from Charles Harris : The attached patch fixes the problem. ---------- components: Library (Lib) files: gzip.patch keywords: patch messages: 123171 nosy: charris44 priority: normal severity: normal status: open title: gzip._PaddedFile calls getattr with arguments in reversed order versions: Python 3.2 Added file: http://bugs.python.org/file19919/gzip.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 3 08:42:01 2010 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 03 Dec 2010 07:42:01 +0000 Subject: [New-bugs-announce] [issue10614] ZipFile and CP932 encoding In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za> Message-ID: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : Currently, ZipFile only accepts ascii or utf8 as file name encodings. On Windows (Japanese), usually CP932 is used for it. So currently, when we melt ZipFile via py3k, non-ascii file name becomes strange. Can we handle this issue? (ie: adding encoding option for ZipFile#__init__) ---------- components: Extension Modules messages: 123197 nosy: ocean-city priority: normal severity: normal status: open title: ZipFile and CP932 encoding type: feature request versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 3 13:46:02 2010 From: report at bugs.python.org (Johann Hanne) Date: Fri, 03 Dec 2010 12:46:02 +0000 Subject: [New-bugs-announce] [issue10615] Trivial mingw compile fixes In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za> Message-ID: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za> New submission from Johann Hanne : Some C files fail to compile with mingw, mostly due to missing preprocessor statements: - Modules/_ctypes/callproc.c When using the bundled non-msvc libffi, ffi_call has no return value, so only use it when compiled with msvc. - Modules/_pickle.c There are Windows data types FLOAT, INT, LONG which the pickle code conflicts with. - Modules/posixmodule.c Some "#ifdef _MSC_VER" paragraphs apply for __MINGW32__ as well; for MinGW, wincrypt.h must be explicitely included (the "original" Windows headers include them in windows.h) - Modules/signalmodule.c On case-sensitive filesystems, windows.h must be all-lowercase - Modules/socketmodule.h MinGW does not define SIO_KEEPALIVE_VALS, so do it here if required - PC/msvcrtmodule.c MinGW does not have crtdbg.h - PC/winreg.c MinGW does not define REG_LEGAL_CHANGE_FILTER, so do it here if required - Python/dynload_win.c strcasecmp is already defined with MinGW, so use a private name - Python/pythonrun.c MinGW has locale.h, but not langinfo.h This patch fixes all the mentioned problems. ---------- components: Build files: Python-3.1.3.fix_mingw_compile.diff keywords: patch messages: 123236 nosy: jonny priority: normal severity: normal status: open title: Trivial mingw compile fixes type: compile error versions: Python 3.1 Added file: http://bugs.python.org/file19924/Python-3.1.3.fix_mingw_compile.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 3 17:43:35 2010 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Dec 2010 16:43:35 +0000 Subject: [New-bugs-announce] [issue10616] Change PyObject_AsCharBuffer() error message In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za> Message-ID: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za> New submission from STINNER Victor : b'abc'.partition(':') raises a confusing TypeError('expected an object with the buffer interface'): what is a buffer? what is the buffer interface? The error comes from PyObject_AsCharBuffer() which is used by: - bytes methods: partition, rpartition, find, index, rfind, rindex, count, translate, replace, startswith, endswith - complex(): raise a better but incomplete error message on error ("complex() arg is not a string"), incomplete because number is not mentionned - float(): raise a better error message on error ("float() argument must be a string or a number") - PyArg_Parse*() with the "e" format -> posix.spawnvpe(), imp.load_compiled(), imp.load_source(), imp.load_package() The error message should be changed to something mentioning classic Python terms. Eg. TypeError("expected bytes, bytearray or buffer compatible object"). ---------- components: Interpreter Core messages: 123263 nosy: haypo priority: normal severity: normal status: open title: Change PyObject_AsCharBuffer() error message versions: Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 3 19:06:23 2010 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 03 Dec 2010 18:06:23 +0000 Subject: [New-bugs-announce] =?utf-8?q?=5Bissue10617=5D_Collections_ABCs_c?= =?utf-8?q?an=E2=80=99t_be_linked_to?= In-Reply-To: <1291399583.54.0.437580491631.issue10617@psf.upfronthosting.co.za> Message-ID: <1291399583.54.0.437580491631.issue10617@psf.upfronthosting.co.za> New submission from ?ric Araujo : ABCs in collections.rst are marked up with a class role, not a class directive, which means that constructs using the class role do not generate a link. ---------- assignee: docs at python components: Documentation messages: 123277 nosy: docs at python, eric.araujo priority: normal severity: normal stage: needs patch status: open title: Collections ABCs can?t be linked to versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 3 21:21:47 2010 From: report at bugs.python.org (Dirkjan Ochtman) Date: Fri, 03 Dec 2010 20:21:47 +0000 Subject: [New-bugs-announce] [issue10618] regression in subprocess.call() command quoting In-Reply-To: <1291407707.04.0.982354776271.issue10618@psf.upfronthosting.co.za> Message-ID: <1291407707.04.0.982354776271.issue10618@psf.upfronthosting.co.za> New submission from Dirkjan Ochtman : http://mercurial.selenic.com/bts/issue2534 is a regression in 2.7.1 relative to 2.7, around the way commands are called (it seems to concern subprocess.call()). The error seems to be raised from mercurial's util.system() call, which uses subprocess.call() or subprocess.Popen() depending on the circumstances. ---------- components: Library (Lib) messages: 123291 nosy: asksol, djc, jnoller priority: normal severity: normal status: open title: regression in subprocess.call() command quoting versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 4 01:14:24 2010 From: report at bugs.python.org (Michael Foord) Date: Sat, 04 Dec 2010 00:14:24 +0000 Subject: [New-bugs-announce] [issue10619] Failed module loading in test discovery loses traceback In-Reply-To: <1291421664.92.0.199127782586.issue10619@psf.upfronthosting.co.za> Message-ID: <1291421664.92.0.199127782586.issue10619@psf.upfronthosting.co.za> New submission from Michael Foord : If a test module fails to load during unittest test discovery (SyntaxError or other exception) then the error is reported during the test run. Due to the way the exception is re-raised the traceback is lost. Originally reported as unittest2 issue 29: https://code.google.com/p/unittest-ext/issues/detail?id=29 ---------- assignee: michael.foord components: Library (Lib) messages: 123308 nosy: michael.foord priority: normal severity: normal stage: needs patch status: open title: Failed module loading in test discovery loses traceback type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 4 01:20:07 2010 From: report at bugs.python.org (Michael Foord) Date: Sat, 04 Dec 2010 00:20:07 +0000 Subject: [New-bugs-announce] [issue10620] `python -m uniittest` should work with file paths as well as test module names In-Reply-To: <1291422007.54.0.147727211127.issue10620@psf.upfronthosting.co.za> Message-ID: <1291422007.54.0.147727211127.issue10620@psf.upfronthosting.co.za> New submission from Michael Foord : Feature request against unittest2. Issue 18: https://code.google.com/p/unittest-ext/issues/detail?id=18 As providing a file path instead of module name to the unittest command line runner currently fails there is no backwards compatibility issue with making this work. The only potential issue is if a test suite or module is genuinely 'foo.py' then we could end up attempting to load the file instead of the specified suite / module. To get round this we should only attempt to load tests from a file by checking the file exists first. The specified still needs to be *imported* to load tests from it, so the file path will be converted to a module name by replacing path separators with '.'. The way to execute test files that aren't importable as modules is to execute them directly not using `python -m unittest`. ---------- assignee: michael.foord components: Library (Lib) messages: 123309 nosy: michael.foord priority: normal severity: normal status: open title: `python -m uniittest` should work with file paths as well as test module names type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 4 10:21:49 2010 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Sat, 04 Dec 2010 09:21:49 +0000 Subject: [New-bugs-announce] [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j) In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za> Message-ID: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za> New submission from Bo?tjan Mejak : Python interpreter should put spaces around operators in return values of complex numbers. If you give it >>> 1 + 2j it should return (1 + 2j) and not the current (1+2j) My argument is that complex numbers are written like this, with spaces surrounding operators. Wikipedia has multiple instances of the complex number writren, and it's x + yi (in our world it's x + yj but you get the point and you can see that there are spaces around the operator). Please fix the tokenizer to do the right thing. ---------- components: IO messages: 123324 nosy: Retro priority: normal severity: normal status: open title: >>> 1 + 2j --> (1 + 2j) and not (1+2j) versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 4 12:32:34 2010 From: report at bugs.python.org (Davide Rizzo) Date: Sat, 04 Dec 2010 11:32:34 +0000 Subject: [New-bugs-announce] [issue10622] WebKit browsers show superfluous scrollbars in html docs In-Reply-To: <1291462354.78.0.0263278148003.issue10622@psf.upfronthosting.co.za> Message-ID: <1291462354.78.0.0263278148003.issue10622@psf.upfronthosting.co.za> New submission from Davide Rizzo : Some WebKit browsers show a superflous scrollbar on the right side of the 
 boxes in the Sphinx generated html docs.

For example:
http://666kb.com/i/boxys2zktxky17vsh.png
taken on Chrome 7 on Windows.

I believe that the cause of the behaviour is a bug in the WebKit engine. If that's the case, adding "overflow-y: hidden" to the 
 css style would fix the issue.
"overflow-y" is not standard css, but it is understood by the affected browsers, looks ok on other modern browsers and is just ignored on older releases.

The provided patch has been tested on all major Windows browsers.

----------
assignee: docs at python
components: Documentation
files: webkit.patch
keywords: patch
messages: 123338
nosy: davide.rizzo, docs at python
priority: normal
severity: normal
status: open
title: WebKit browsers show superfluous scrollbars in html docs
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19936/webkit.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec  4 14:08:14 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 04 Dec 2010 13:08:14 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue10623=5D_What=E2=80=99s_New?=
 =?utf-8?q?_In_Python_3=2E2_document_refers_to_PEP_382=3A_Defining_a_Stabl?=
 =?utf-8?q?e_ABI?=
In-Reply-To: <1291468094.37.0.919975926538.issue10623@psf.upfronthosting.co.za>
Message-ID: <1291468094.37.0.919975926538.issue10623@psf.upfronthosting.co.za>


New submission from Daniel Urban :

But "Defining a Stable ABI" is PEP 384: http://www.python.org/dev/peps/pep-0384/
(PEP 382 is "Namespace Packages")

----------
assignee: docs at python
components: Documentation
messages: 123345
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: What?s New In Python 3.2 document refers to PEP 382: Defining a Stable ABI
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec  4 14:19:31 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 13:19:31 +0000
Subject: [New-bugs-announce] [issue10624] Move requires_IEEE_754 decorator
	from test_complex into	test.support
In-Reply-To: <1291468771.13.0.732059095868.issue10624@psf.upfronthosting.co.za>
Message-ID: <1291468771.13.0.732059095868.issue10624@psf.upfronthosting.co.za>


New submission from Eric Smith :

The decorator could be shared in at least datetimetester, test_cmath, test_complex, test_decimal, test_fractions, test_long, and test_math.

----------
assignee: eric.smith
components: Tests
keywords: easy
messages: 123346
nosy: eric.smith, mark.dickinson
priority: low
severity: normal
status: open
title: Move requires_IEEE_754 decorator from test_complex into test.support
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec  4 14:24:32 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 13:24:32 +0000
Subject: [New-bugs-announce] [issue10625] There is no test for
	repr(complex(-0., 1.)) special handling
In-Reply-To: <1291469072.67.0.197064597975.issue10625@psf.upfronthosting.co.za>
Message-ID: <1291469072.67.0.197064597975.issue10625@psf.upfronthosting.co.za>


New submission from Eric Smith :

There's a special test in the C code for this, but there no test for it in test_complex. Note that this needs to be a IEEE 754 specific test.

----------
assignee: eric.smith
components: Tests
keywords: easy
messages: 123348
nosy: eric.smith
priority: normal
severity: normal
status: open
title: There is no test for repr(complex(-0.,1.)) special handling
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec  4 14:51:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Dec 2010 13:51:15 +0000
Subject: [New-bugs-announce] [issue10626] test_concurrent_futures failure
	under Windows Server 2008
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

See this buildbot log:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/198/steps/test/logs/stdio

======================================================================
FAIL: test_done_callback_raises (test.test_concurrent_futures.FutureTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_concurrent_futures.py", line 646, in test_done_callback_raises
    self.assertIn('Exception: doh!', logging_stream.getvalue())
AssertionError: 'Exception: doh!' not found in ''

----------------------------------------------------------------------

----------
assignee: bquinlan
components: Library (Lib), Tests
messages: 123352
nosy: bquinlan, brian.curtin, pitrou
priority: normal
severity: normal
status: open
title: test_concurrent_futures failure under Windows Server 2008
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec  4 17:11:06 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 04 Dec 2010 16:11:06 +0000
Subject: [New-bugs-announce] [issue10627] Remove usage of deprecated
	configparser.ConfigParser	class in the stdlib
In-Reply-To: <1291479066.31.0.42348750803.issue10627@psf.upfronthosting.co.za>
Message-ID: <1291479066.31.0.42348750803.issue10627@psf.upfronthosting.co.za>


New submission from ?ukasz Langa :

configparser.ConfigParser is deprecated as of 3.2 and thus standard library modules should not use that.

The migration path is trivial and should not introduce any compatibility problems whatsoever. All it needs is to switch usage of ConfigParser to SafeConfigParser.

Please find attached a patch that makes the necessary renames.

For the curious, rationale for the deprecation:
- ConfigParser forces interpolation on users, providing no way of escaping interpolation if necessary
- ConfigParser does not check types given on set() and add*() methods, which may lead to invalid internal state (which will raise exceptions when trying to write() configuration or get() values from it)
- until recently configparser's unit tests assumed no instance customization. ConfigParser's error handling is broken when optionxform is overriden

----------
assignee: tarek
components: Distutils, IDLE, Library (Lib)
keywords: needs review, patch
messages: 123367
nosy: eric.araujo, lukasz.langa, tarek
priority: high
severity: normal
stage: patch review
status: open
title: Remove usage of deprecated configparser.ConfigParser class in the stdlib
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec  4 20:10:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 19:10:55 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue10628=5D_Typos_in_3=2E2_wha?=
	=?utf-8?b?dOKAmXMgbmV3?=
In-Reply-To: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>
Message-ID: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

See patch.

----------
assignee: rhettinger
components: Documentation
files: whatsnew-3.2-typos.diff
keywords: patch
messages: 123383
nosy: eric.araujo, rhettinger
priority: normal
severity: normal
status: open
title: Typos in 3.2 what?s new
versions: Python 3.2
Added file: http://bugs.python.org/file19942/whatsnew-3.2-typos.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec  5 09:43:16 2010
From: report at bugs.python.org (Bill McEachen)
Date: Sun, 05 Dec 2010 08:43:16 +0000
Subject: [New-bugs-announce] [issue10629] Arbitrary precision
In-Reply-To: <1291538596.71.0.765304275074.issue10629@psf.upfronthosting.co.za>
Message-ID: <1291538596.71.0.765304275074.issue10629@psf.upfronthosting.co.za>


New submission from Bill McEachen :

from this link [http://en.wikipedia.org/wiki/PARI/GP#Usage_examples], I wanted to contrast arbitrary precision with the other pgm I use, Pari/GP.  I tried the xample there which was:
123456! + 0.
Now, behavior seems the same without the "+0." for both.  However, while Pari returns the answer shown on link quickly, Python after a delay returned an error, related to float conversion.  Here is the progression from a smaller number to the problem:
>>> math.factorial(12) +0.
479001600.0
>>> math.factorial(123) +0.
1.214630436702533e+205
>>> math.factorial(1234) +0.
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: long int too large to convert to float
>>>

----------
components: Regular Expressions
messages: 123414
nosy: billymac00
priority: normal
severity: normal
status: open
title: Arbitrary precision
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec  5 17:19:06 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 05 Dec 2010 16:19:06 +0000
Subject: [New-bugs-announce] [issue10630] dict_proxy.keys() / values() /
	items() are lists
In-Reply-To: <1291565946.17.0.111097012254.issue10630@psf.upfronthosting.co.za>
Message-ID: <1291565946.17.0.111097012254.issue10630@psf.upfronthosting.co.za>


New submission from Daniel Urban :

The keys, values and items methods of dict_proxy return a list, while dict.keys, etc. return dictionary views (dict_keys, etc.). dict_proxy is used as the __dict__ attribute of classes. This is documented at http://docs.python.org/dev/py3k/reference/datamodel.html under "Custom classes" as "Special attributes: ... __dict__ is the dictionary containing the class?s namespace ..." While __dict__ is not actually dict, it probably should behave like a dict as close as possible. For example set operations work for dict.keys(), but not for dict_proxy.keys().

----------
components: Interpreter Core
messages: 123427
nosy: durban
priority: normal
severity: normal
status: open
title: dict_proxy.keys() / values() / items() are lists
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec  5 17:49:21 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 05 Dec 2010 16:49:21 +0000
Subject: [New-bugs-announce] [issue10631] ZipFile and current directory
	change
In-Reply-To: <1291567761.41.0.659026181219.issue10631@psf.upfronthosting.co.za>
Message-ID: <1291567761.41.0.659026181219.issue10631@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto :

Is this intended behavior? Creating zipfile.ZipFile with
relative path and changing current directory, relative path
is resolved from new directory not from the directory object
was created.

F:\>py3k
Python 3.2a4+ (py3k, Dec  3 2010, 22:11:05) [MSC v.1200 32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
[67577 refs]
>>> zip = zipfile.ZipFile("non-ascii-cp932.zip", "r")
[68999 refs]
>>> import os
[69001 refs]
>>> os.mkdir("temp")
[69001 refs]
>>> os.chdir("temp")
[69001 refs]
>>> zip.extractall()
Traceback (most recent call last):
  File "", line 1, in 
  File "e:\python-dev\py3k\lib\zipfile.py", line 992, in extractall
    self.extract(zipinfo, path, pwd)
  File "e:\python-dev\py3k\lib\zipfile.py", line 980, in extract
    return self._extract_member(member, path, pwd)
  File "e:\python-dev\py3k\lib\zipfile.py", line 1023, in _extract_member
    source = self.open(member, pwd=pwd)
  File "e:\python-dev\py3k\lib\zipfile.py", line 901, in open
    zef_file = io.open(self.filename, 'rb')
IOError: [Errno 2] No such file or directory: 'non-ascii-cp932.zip'
[69128 refs]

----------
messages: 123428
nosy: ocean-city
priority: normal
severity: normal
status: open
title: ZipFile and current directory change
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec  5 19:53:51 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sun, 05 Dec 2010 18:53:51 +0000
Subject: [New-bugs-announce] [issue10632] multiprocessing gene
In-Reply-To: <1291575231.48.0.0739915325097.issue10632@psf.upfronthosting.co.za>
Message-ID: <1291575231.48.0.0739915325097.issue10632@psf.upfronthosting.co.za>


New submission from Brian Quinlan :

multiprocessing generates fatal error "Invalid thread state for this thread" in PyThreadState_Swap

This seems to happen on RHEL 5 and Centos 5.5

Here is the minimal repro:
>>> import multiprocessing.managers
>>> mpp = multiprocessing.Pool(4)
>>> sm = multiprocessing.managers.SyncManager()
>>> sm.start()

See http://bugs.python.org/issue10517 for more details

----------
assignee: jnoller
components: Library (Lib)
messages: 123433
nosy: bquinlan, jnoller
priority: high
severity: normal
status: open
title: multiprocessing gene
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec  6 00:40:51 2010
From: report at bugs.python.org (Alex Leone)
Date: Sun, 05 Dec 2010 23:40:51 +0000
Subject: [New-bugs-announce] [issue10633] string.format() Unexpected output
	with numeric '#'	prefix and 0 width
In-Reply-To: <1291592451.76.0.667940420778.issue10633@psf.upfronthosting.co.za>
Message-ID: <1291592451.76.0.667940420778.issue10633@psf.upfronthosting.co.za>


New submission from Alex Leone :

When using the '#' to prefix a numeric argument in format() with a '0x' or others, the 0-width padding takes into account the '0x' characters.  This is unexpected - the 0-width should NOT take into account the prefix.

Current Behavior:
> "{0:#02x}".format(10)
'0xa'

Expected Output:
> "{0:#02x}".format(10)
'0x0a'

(note that the '0a' is two characters long, as it should be)

----------
components: Library (Lib)
messages: 123441
nosy: Alex.Leone
priority: normal
severity: normal
status: open
title: string.format() Unexpected output with numeric '#' prefix and 0 width
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec  6 00:57:24 2010
From: report at bugs.python.org (Eric Pruitt)
Date: Sun, 05 Dec 2010 23:57:24 +0000
Subject: [New-bugs-announce] [issue10634] Windows timezone changes not
	reflected by time.localtime
In-Reply-To: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>
Message-ID: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>


New submission from Eric Pruitt :

If the current time zone changes on Windows, time.localtime will continue to return results that reflect the time zone the system used when the module was imported. My current work around is to use GetLocalTime from kernel32 with ctypes. Windows does not have a tzset() equivalent as it does in Linux, but it seems like modifying time.localtime to use GetLocalTime on Windows systems could make up for this shortcoming.

----------
components: Windows
messages: 123442
nosy: eric.pruitt
priority: normal
severity: normal
status: open
title: Windows timezone changes not reflected by time.localtime
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec  6 01:05:25 2010
From: report at bugs.python.org (joseph.h.garvin)
Date: Mon, 06 Dec 2010 00:05:25 +0000
Subject: [New-bugs-announce] [issue10635] Calling subprocess.Popen with
	preexec_fn=signal.pause	blocks forever
In-Reply-To: <1291593925.84.0.564814760891.issue10635@psf.upfronthosting.co.za>
Message-ID: <1291593925.84.0.564814760891.issue10635@psf.upfronthosting.co.za>


New submission from joseph.h.garvin :

The following code will cause the interpreter to hang:

import subprocess
import signal
subprocess.Popen("/bin/echo", preexec_fn=signal.pause)

Replace "/bin/echo" with any valid program on your box, it's just the simplest Linux example. It's expected for signal.pause to block, but the documentation for Popen says that preexec_fn will be run in the /child/ process, so it shouldn't cause the interpreter running this code to block.

I'm going to guess Popen is using signals for some reason internally and signal.pause interferes with it. It's probably worth making sure that signals related functions work with preexec_fn in general.

----------
components: Library (Lib)
messages: 123444
nosy: joseph.h.garvin
priority: normal
severity: normal
status: open
title: Calling subprocess.Popen with preexec_fn=signal.pause blocks forever
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec  6 01:19:56 2010
From: report at bugs.python.org (joseph.h.garvin)
Date: Mon, 06 Dec 2010 00:19:56 +0000
Subject: [New-bugs-announce] [issue10636] subprocess module has race
	condition with SIGCHLD	handlers
In-Reply-To: <1291594796.46.0.99547851622.issue10636@psf.upfronthosting.co.za>
Message-ID: <1291594796.46.0.99547851622.issue10636@psf.upfronthosting.co.za>


New submission from joseph.h.garvin :

The following code will result in a traceback 99% of the time, though it may take two runs (sometimes the first run won't trigger it, I think due to the changing in timing from genrating the .pyc file). It spawns an instance of /bin/echo, chosen because it's a very quick to finish program. Any program that executes faster than subprocess.Popen can return will work as a substitute though:

import signal
import subprocess

to_launch = None

def sig_chld_handler(signum, frame):
    global to_launch
    # Crashes here.
    # 'NoneType' object has no attribute 'poll'
    to_launch.poll()

    print to_launch.returncode

signal.signal(signal.SIGCHLD, sig_chld_handler)

to_launch = subprocess.Popen("/bin/echo")


And the traceback:


Traceback (most recent call last):
  File "/tmp/sigchld.py", line 15, in 
    to_launch = subprocess.Popen("/bin/echo")
  File "/usr/lib/python2.6/subprocess.py", line 623, in __init__
    errread, errwrite)
  File "/usr/lib/python2.6/subprocess.py", line 1130, in _execute_child
    data = _eintr_retry_call(os.read, errpipe_read, 1048576)
  File "/usr/lib/python2.6/subprocess.py", line 455, in _eintr_retry_call
    return func(*args)
  File "/tmp/sigchld.py", line 9, in sig_chld_handler
    to_launch.poll()
AttributeError: 'NoneType' object has no attribute 'poll'


I believe the problem is that the process completes before Popen can return, which means the assignment of to_launch hasn't happened yet, so it's not defined when we get into sig_chld_handler.

I tried to work around this issue by setting preexec_fn to signal.pause and sending the child process a signal after the assignment, but then ran into another bug: http://bugs.python.org/issue10635

If when it caught SIGCHLD python pushed an event onto its internal event loop to execute the handler, I think that would make sure it's deferred until after the assignment. There might be other consequences of that, but I'm not familiar with the interpreter internals. Alternatively it could be fixed with an API change -- let Popen return an object before it actually launches the process, and have a separate start() method.

----------
components: Library (Lib)
messages: 123445
nosy: joseph.h.garvin
priority: normal
severity: normal
status: open
title: subprocess module has race condition with SIGCHLD handlers
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec  6 05:08:58 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 06 Dec 2010 04:08:58 +0000
Subject: [New-bugs-announce] [issue10637] Calling CloseHandle twice
	(Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto :

Very sorry, I created the bug calling CloseHandle twice
in Modules/posixmodule.c. I think this should be fixed
before beta1 released. Can I commit it?

----------
components: None
files: posixmodule.diff
keywords: needs review, patch
messages: 123452
nosy: georg.brandl, ocean-city
priority: release blocker
severity: normal
stage: commit review
status: open
title: Calling CloseHandle twice (Modules/posixmodule.c)
versions: Python 3.2
Added file: http://bugs.python.org/file19951/posixmodule.diff

_______________________________________
Python tracker 

_______________________________________

From martin at v.loewis.de  Mon Dec  6 08:18:20 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 06 Dec 2010 08:18:20 +0100
Subject: [New-bugs-announce] [issue10637] Calling CloseHandle
	twice	(Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
References: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <4CFC8E3C.8080007@v.loewis.de>

> Very sorry, I created the bug calling CloseHandle twice
> in Modules/posixmodule.c. I think this should be fixed
> before beta1 released. Can I commit it?

Even if you commit it now, it won't get into beta1: the
Windows binaries for that are already built.

From report at bugs.python.org  Mon Dec  6 14:43:19 2010
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 06 Dec 2010 13:43:19 +0000
Subject: [New-bugs-announce] [issue10638] PyArg_ParseTuple: refcount in
	nested tuples
In-Reply-To: <1291642999.53.0.225447944395.issue10638@psf.upfronthosting.co.za>
Message-ID: <1291642999.53.0.225447944395.issue10638@psf.upfronthosting.co.za>


New submission from Armin Rigo :

There is an issue in PyArg_ParseTuple() when using nested tuple arguments: it accepts a pure Python tuple-like argument, but it cannot work properly because PyArg_ParseTuple() is supposed to return borrowed references to the objects.  For example, here is an attack on functools.partial().__setstate__(), which is written using

    PyArg_ParseTuple(args, "(OOOO)", ...)

Running crasher.py crashes a debug build of Python, for me with Fatal Python error: _functoolsmodule.c:158 object at 0x9011748 has negative ref count -606348322.

The only way I can see to fix the crasher is to restrict the kind of argument that can be passed to mean a nested tuple.  To be paranoid, it should only allow real tuples; a bit more flexibly, lists probably work ok too.

----------
components: Interpreter Core
files: crasher.py
messages: 123466
nosy: arigo
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple: refcount in nested tuples
Added file: http://bugs.python.org/file19953/crasher.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec  6 17:36:53 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Dec 2010 16:36:53 +0000
Subject: [New-bugs-announce] [issue10639] reindent.py converts newlines to
	platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>


New submission from Jason R. Coombs :

When reindent.py runs, it will convert the line endings for each file it converts to the default line ending for the platform on which reindent.py runs. It would be better if reindent.py would retain line endings of the source file. Attached is a patch that addresses this issue.

----------
components: Demos and Tools
files: reindent-autonewline.patch
keywords: patch
messages: 123476
nosy: jaraco
priority: normal
severity: normal
status: open
title: reindent.py converts newlines to platform default
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19955/reindent-autonewline.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec  6 20:33:09 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 06 Dec 2010 19:33:09 +0000
Subject: [New-bugs-announce] [issue10640] SystemError on pickling bytes >=
	4GB
In-Reply-To: <1291663989.87.0.429691501814.issue10640@psf.upfronthosting.co.za>
Message-ID: <1291663989.87.0.429691501814.issue10640@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau :

Pickling a bytes object of length >= 2**32 results in a "SystemError: error return without exception set".

If pickling large bytes objects isn't supported, this should be documented and a helpful exception be raised.

----------
components: Library (Lib)
messages: 123499
nosy: hagen
priority: normal
severity: normal
status: open
title: SystemError on pickling bytes >= 4GB
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec  7 01:15:41 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 07 Dec 2010 00:15:41 +0000
Subject: [New-bugs-announce] [issue10641] kill_python sometimes fails to
	kill processes on	buildbots
In-Reply-To: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za>
Message-ID: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za>


New submission from David Bolen :

On the XP and Win7 buildbots, kill_python sometimes fails to kill hung processes.  I caught one instance recently and gathered some information though not yet enough to identify the issue.  I can say that no processes are killed and no error messages displayed.  I think that implies either a process ownership-related snapshot failure (which can exit without error) or a failure to identify the processes.

I noticed issue10136 and considered it might be related, but in testing I found cases where the exact same usage of kill_python as this failing case worked fine, whereas if it was a path mismatch problem I would expect it to fail consistently. 

I have attached a log showing the hung processes, attempt to use kill_python, and final successful operation with the pskill utility.

In this case it was important to restore the buildbot quickly, but if I can catch it again I'll try to add some debugging code to kill_python first.

One thing that confused me along the way is that kill_python is only run at the beginning of a build and not as part of the clean process.  So there are cases where I have hung processes around, but they turn out to be killable when the next build starts.  I'm wondering if kill_python shouldn't perhaps be used on every clean operation too.

-- David

----------
components: Build
files: kill_python.log
messages: 123510
nosy: db3l
priority: normal
severity: normal
status: open
title: kill_python sometimes fails to kill processes on buildbots
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19964/kill_python.log

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec  7 04:35:20 2010
From: report at bugs.python.org (Donald Wallace Rouse II)
Date: Tue, 07 Dec 2010 03:35:20 +0000
Subject: [New-bugs-announce] [issue10642] site.py crashes on python startup
	due to defective .pth	file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>


New submission from Donald Wallace Rouse II :

Python 2.7 programs crash on startup due to a defective third-party package installed in site-packages.

starting python 2.7 yields the following error message:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site.py", line 554, in 
    main()
  File "/usr/lib64/python2.7/site.py", line 537, in main
    known_paths = addsitepackages(known_paths)
  File "/usr/lib64/python2.7/site.py", line 316, in addsitepackages
    addsitedir(sitedir, known_paths)
  File "/usr/lib64/python2.7/site.py", line 192, in addsitedir
    addpackage(sitedir, name, known_paths)
  File "/usr/lib64/python2.7/site.py", line 162, in addpackage
    exec line
  File "", line 1, in 
KeyError: 'zope'

A similar message appears when starting python2.7 interactively, but it then proceeds to the prompt (doesn't crash).

In the file .../python2.7/site.py, at about line 162, in the function "addpackage", you have an
unprotected "exec" line:
    if line.startswith(("import ", "import\t")):
        exec line

If the execution of the line fails, python generates an uncaught exception.
This places python at the mercy of bugs in third-party software.

The "exec" line should be bracketed by "try/except" to catch such errors:
    if line.startswith(("import ", "import\t")):
        try:
            exec line
        except:
            pass
        continue

Note 1: I am not sure whether this is a Distutils bug or Distutils2 bug (or even something else like "Extension Modules"), so I'm filing it under Distutils2. If this is incorrect, please forward to the proper place. Thanks.

Note 2: Here is where I initially reported this problem: http://bugs.gentoo.org/show_bug.cgi?id=347565

----------
assignee: tarek
components: Distutils2
messages: 123519
nosy: dwr2, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: site.py crashes on python startup due to defective .pth file
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec  7 08:02:44 2010
From: report at bugs.python.org (wojas)
Date: Tue, 07 Dec 2010 07:02:44 +0000
Subject: [New-bugs-announce] [issue10643] OSX proxy exceptions parse bug in
	urllib (crash)
In-Reply-To: <1291705364.23.0.312464028826.issue10643@psf.upfronthosting.co.za>
Message-ID: <1291705364.23.0.312464028826.issue10643@psf.upfronthosting.co.za>


New submission from wojas :

On OSX (tested with 10.6), urllib will fail to parse the proxy exceptions configuration if no netmask is specified.

On my system the following entries have been added to the proxy exception list: '127.0.0.1' and 'localhost'. The traceback in included below.

The problem:
 * In 'm = re.match(r"(\d+(?:\.\d+)*)(/\d+)?", value)' the netmask is optional
 * But 'mask = int(m.group(2)[1:])' implicitly assumes it exists.

This can be fixed by using 32 as a default netmask if none is specified, see attached patch: 'mask = int(m.group(2)[1:]) if m.group(2) else 32'

TRACEBACK:

  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py", line 203, in open
    return self._mech_open(url, data, timeout=timeout)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py", line 230, in _mech_open
    response = UserAgentBase.open(self, request, data)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_opener.py", line 188, in open
    req = meth(req)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_http.py", line 316, in http_request
    self.rfp.read()
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_http.py", line 242, in read
    f = self._opener.open(req)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py", line 203, in open
    return self._mech_open(url, data, timeout=timeout)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py", line 230, in _mech_open
    response = UserAgentBase.open(self, request, data)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_opener.py", line 193, in open
    response = urlopen(self, req, data)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py", line 344, in _open
    '_open', req)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py", line 332, in _call_chain
    result = func(*args)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py", line 666, in 
    meth(r, proxy, type))
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py", line 678, in proxy_open
    if req.get_host() and self._proxy_bypass(req.get_host()):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.py", line 1407, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.py", line 1379, in proxy_bypass_macosx_sysconf
    mask = int(m.group(2)[1:])
TypeError: 'NoneType' object is unsubscriptable

----------
components: Extension Modules
files: urllib-osx-proxy-patch.diff
keywords: patch
messages: 123524
nosy: wojas
priority: normal
severity: normal
status: open
title: OSX proxy exceptions parse bug in urllib (crash)
versions: Python 2.6
Added file: http://bugs.python.org/file19967/urllib-osx-proxy-patch.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec  7 10:01:26 2010
From: report at bugs.python.org (diekmann)
Date: Tue, 07 Dec 2010 09:01:26 +0000
Subject: [New-bugs-announce] [issue10644] socket loses data,
	calling send()/sendall() on invalid socket does not report error
	and	returns all bytes as written
In-Reply-To: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>
Message-ID: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>


New submission from diekmann :

Calling send()/sendall() on an invalid socket does not report an error and returns all bytes as written. Thus, all bytes written to the socket are lost and the application is not informed about that and treats the bytes as successfully sent. The bytes given to the socket are silently lost, this cannot be recovered.

The attached file includes an example to reproduce this problem. I defined an invalid socket, when the other side of the connection has closed the connection.

Steps to reproduce (see attached file for python implementation):
1) Create listening socket
2) let client connect to it
2.1) send something to the client (optional step)
3) Client terminates connection (now the socket on the server side is invalid)
4) Server calls send/sendall <--- No Error here, but everything is lost
5) Server calls send/sendall again (Now we get the required error)

----------
components: Library (Lib)
files: socketbug.py
messages: 123534
nosy: diekmann
priority: normal
severity: normal
status: open
title: socket loses data, calling send()/sendall() on invalid socket does not report error and returns all bytes as written
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file19969/socketbug.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec  7 10:06:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Dec 2010 09:06:54 +0000
Subject: [New-bugs-announce] [issue10645] egg-info file in lib-dynload
In-Reply-To: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>
Message-ID: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>


New submission from Ronald Oussoren :

I just noticed that distutils creates an egg-info for the stdlib while installing Python.

This definitely happens for Python 2.7 and Python 3.2 (both framework builds on OSX).

In lib-dynload there is and egg-info file: "Python-2.7.1-py2.7.egg-info" 

Is this intentional? 

If it is: the OSX installer does not remove older versions when installing an upgrade (that is, I also have egg-info files for Python-2.7 and several pre-releases)

----------
assignee: tarek
components: Distutils
messages: 123536
nosy: eric.araujo, ronaldoussoren, tarek
priority: low
severity: normal
status: open
title: egg-info file in lib-dynload
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec  7 17:59:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Dec 2010 16:59:39 +0000
Subject: [New-bugs-announce] [issue10646] ntpath.samefile doesn't work for
	hard links
In-Reply-To: <1291741179.93.0.790815222225.issue10646@psf.upfronthosting.co.za>
Message-ID: <1291741179.93.0.790815222225.issue10646@psf.upfronthosting.co.za>


New submission from Brian Curtin :

ntpath.samefile is currently implemented using GetFinalPathNameByHandle, which doesn't work for hard links.

Since I introduced values for os.stat().st_ino in #8879 (which implemented os.link), I suspect we can possibly change ntpath.samefile to be the same as posixfile.samefile and leave st_ino.


Hirokazu questioned whether or not that st_ino change was correct, but I think it will be fine on NTFS. As FAT does not support links anyways, there would be no issue with potential st_ino issues there as we wouldn't be comparing them for any reason.


(part of the reason I created this is that we have discussion on st_ino and samefile in a few different places and I'm losing track of where we're at)

----------
assignee: brian.curtin
components: Library (Lib), Windows
messages: 123564
nosy: brian.curtin, ocean-city
priority: normal
severity: normal
stage: unit test needed
status: open
title: ntpath.samefile doesn't work for hard links
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec  7 21:55:34 2010
From: report at bugs.python.org (Herm Fischer)
Date: Tue, 07 Dec 2010 20:55:34 +0000
Subject: [New-bugs-announce] [issue10647] scrollbar crash in non-US locale
	format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>


New submission from Herm Fischer :

My app has a tkinter messages listbox with a scrollbar which works fine in US setting, but not when locale is a European setting (with comma for decimal point).  It's a highly interactive app with a lot of number formattings in the local locale, and mostly used in Europe and Asia.

This instruction: self.logListBox.insert(END, message)

causes this crash in non-US locale when scrolling down:

Class: class Scrollbar(Widget):

    def set(self, *args):
        """Set the fractional values of the slider position (upper and
        lower ends as value between 0 and 1)."""
        self.tk.call((self._w, 'set') + args)   <<<<===== this line causes exception in European settings

the arg is in European decimal point format, when run on European settings, the error trace is:

  File "C:\Python31\lib\tkinter\__init__.py", line 1399, in __call__
    return self.func(*args)
  File "C:\Python31\lib\tkinter\__init__.py", line 2797, in set
    self.tk.call((self._w, 'set') + args)
_tkinter.TclError: expected floating-point number but got "0,145833"

using python 3.1.3 (r313:86834)

----------
components: Tkinter
messages: 123580
nosy: hfischer
priority: normal
severity: normal
status: open
title: scrollbar crash in non-US locale format settings
type: crash
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 02:25:51 2010
From: report at bugs.python.org (Demur Rumed)
Date: Wed, 08 Dec 2010 01:25:51 +0000
Subject: [New-bugs-announce] [issue10648] Extend peepholer to reverse loads
	or stores instead of	build/unpack
In-Reply-To: <1291771551.8.0.926490370256.issue10648@psf.upfronthosting.co.za>
Message-ID: <1291771551.8.0.926490370256.issue10648@psf.upfronthosting.co.za>


New submission from Demur Rumed :

This modifies the peepholer's BUILD/UNPACK_SEQUENCE for the case when all stores are simple, or all loads are simple

It first scans to see if the pushing is done with simple LOADs. If so, it reverses the loads and removes the build unpack. If not, it scans ahead to see if it is followed by simple STOREs. If so, it reverses the stores and removes the build unpack

----------
components: Interpreter Core
files: peep.diff
keywords: patch
messages: 123588
nosy: serprex
priority: normal
severity: normal
status: open
title: Extend peepholer to reverse loads or stores instead of build/unpack
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file19974/peep.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 02:30:35 2010
From: report at bugs.python.org (Chinmay Kanchi)
Date: Wed, 08 Dec 2010 01:30:35 +0000
Subject: [New-bugs-announce] [issue10649] Attempting to override special
	methods of a function	object does not cause an error
In-Reply-To: <1291771835.4.0.575373997099.issue10649@psf.upfronthosting.co.za>
Message-ID: <1291771835.4.0.575373997099.issue10649@psf.upfronthosting.co.za>


New submission from Chinmay Kanchi :

Attempting to override a special method of an object of a builtin (like list) raises an AttributeError. This is obviously by design. However, doing the same to a user-defined function object seemingly replaces the function, but does not have the expected effect. In the interests of consistency, attempting to change a special method of a function object should raise an AttributeError stating that the property/method is read-only.

>>> a_list = list()
>>> a_list.__repr__ = lambda: '[]'
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'list' object attribute '__repr__' is read-only

>>> def f(): pass
>>> f.__repr__ = lambda: 'f'
>>> f.__repr__
 at 0x6482b0>
>>> repr(f) #would expect it to return 'f' since no error was raised
''
>>> f.__repr__() #so the change is half-way made, inconsistent and possibly problematic
'f'
>>>

----------
components: Interpreter Core
messages: 123589
nosy: Chinmay.Kanchi
priority: normal
severity: normal
status: open
title: Attempting to override special methods of a function object does not cause an error
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 14:56:15 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 08 Dec 2010 13:56:15 +0000
Subject: [New-bugs-announce] [issue10650] decimal.py: quantize(): excess
	digits with watchexp=0
In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za>
Message-ID: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za>


New submission from Stefan Krah :

I'm not sure if this is a documentation issue or a bug. If watchexp=0,
quantize() also allows any number of digits:


>>> x = Decimal("6885998238912213556789006667970467609814")
>>> y = Decimal("1e2")
>>> x.quantize(y)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.2/decimal.py", line 2488, in quantize
    'quantize result has too many digits for current context')
  File "/usr/local/lib/python3.2/decimal.py", line 3925, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: quantize result has too many digits for current context
>>> 
>>> x.quantize(y, watchexp=0)
Decimal('6.8859982389122135567890066679704676098E+39')

----------
components: Library (Lib)
messages: 123603
nosy: mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: decimal.py: quantize(): excess digits with watchexp=0
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 15:39:36 2010
From: report at bugs.python.org (Vladimir K)
Date: Wed, 08 Dec 2010 14:39:36 +0000
Subject: [New-bugs-announce] [issue10651] chr(13) is added before chr(10)
	when issuing ".write"	under windows
In-Reply-To: <1291819176.76.0.271161010974.issue10651@psf.upfronthosting.co.za>
Message-ID: <1291819176.76.0.271161010974.issue10651@psf.upfronthosting.co.za>


New submission from Vladimir K :

The following code (see attached file) was intended to remove chr(13) from end-of-lines under Windows to make the file Unix-compliant but it always appends chr(13) before chr(10).

I'm under Windows XP.

----------
components: IO, Windows
files: chr13remove.py
messages: 123608
nosy: KZM
priority: normal
severity: normal
status: open
title: chr(13) is added before chr(10) when issuing ".write" under windows
versions: Python 2.7
Added file: http://bugs.python.org/file19976/chr13remove.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 15:39:58 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 14:39:58 +0000
Subject: [New-bugs-announce] [issue10652] test___all_ + test_tcl fails
	(Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto :

On official Python3.2 beta1 windows binary, I noticed following
command fails. (test_tcl alone won't fail)

I couldn't reproduce this on binary built from source without
installation.

//////////////////////////////////////////////////////////////

C:\Python32>.\python.exe -m test.regrtest -v test___all__ test_tcl

(snip)

[2/2] test_tcl
testCall (test.test_tcl.TclTest) ... ERROR
testCallException (test.test_tcl.TclTest) ... ERROR
testCallException2 (test.test_tcl.TclTest) ... ERROR
testEval (test.test_tcl.TclTest) ... ERROR
testEvalException (test.test_tcl.TclTest) ... ERROR
testEvalException2 (test.test_tcl.TclTest) ... ERROR
testEvalFile (test.test_tcl.TclTest) ... ERROR
testEvalFileException (test.test_tcl.TclTest) ... ERROR
testGetVar (test.test_tcl.TclTest) ... ERROR
testGetVarArray (test.test_tcl.TclTest) ... ERROR
testGetVarArrayException (test.test_tcl.TclTest) ... ERROR
testGetVarException (test.test_tcl.TclTest) ... ERROR
testLoadWithUNC (test.test_tcl.TclTest) ... ERROR
testPackageRequireException (test.test_tcl.TclTest) ... ERROR
testSetVar (test.test_tcl.TclTest) ... ERROR
testSetVarArray (test.test_tcl.TclTest) ... ERROR
testUnsetVar (test.test_tcl.TclTest) ... ERROR
testUnsetVarArray (test.test_tcl.TclTest) ... ERROR
testUnsetVarException (test.test_tcl.TclTest) ... ERROR
testFlattenLen (test.test_tcl.TkinterTest) ... ok

======================================================================
ERROR: testCall (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python32\lib\test\test_tcl.py", line 25, in setUp
    self.interp = Tcl()
  File "C:\Python32\lib\tkinter\__init__.py", line 1768, in Tcl
    return Tk(screenName, baseName, className, useTk)
  File "C:\Python32\lib\tkinter\__init__.py", line 1674, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, want
objects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories:
    C:/Python32/lib/tcl8.5 C:/lib/tcl8.5 C:/lib/tcl8.5 C:/library C:/library C:/
tcl8.5.2/library C:/tcl8.5.2/library



This probably means that Tcl wasn't installed properly.


(snip)

----------------------------------------------------------------------
Ran 20 tests in 1.752s

FAILED (errors=19)
test test_tcl failed -- multiple errors occurred
1 test failed:
    test_tcl
1 test altered the execution environment:
    test___all__

----------
components: Tests, Windows
messages: 123609
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test___all_ + test_tcl fails (Windows installed binary)
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 16:01:31 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 15:01:31 +0000
Subject: [New-bugs-announce] [issue10653] test_time test_strptime fails on
	windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto :

Following tests fails on official Python3.2 Windows binary.

I cannot reproduce this on VC6.

/////////////////////////////////////////////////////

C:\Python32>.\python -m test.regrtest -v test_time test_strptime

[1/2] test_time
test_asctime (test.test_time.TimeTestCase) ... ok
test_asctime_bounding_check (test.test_time.TimeTestCase) ... ok
test_clock (test.test_time.TimeTestCase) ... ok
test_conversions (test.test_time.TimeTestCase) ... ok
test_ctime_without_arg (test.test_time.TimeTestCase) ... ok
test_data_attributes (test.test_time.TimeTestCase) ... ok
test_default_values_for_zero (test.test_time.TimeTestCase) ... ok
test_gmtime_without_arg (test.test_time.TimeTestCase) ... ok
test_insane_timestamps (test.test_time.TimeTestCase) ... ok
test_localtime_without_arg (test.test_time.TimeTestCase) ... ok
test_sleep (test.test_time.TimeTestCase) ... ok
test_strftime (test.test_time.TimeTestCase) ... ok
test_strftime_bounding_check (test.test_time.TimeTestCase) ... ok
test_strptime (test.test_time.TimeTestCase) ... FAIL
test_strptime_bytes (test.test_time.TimeTestCase) ... ok
test_tzset (test.test_time.TimeTestCase) ... ok
test_bug_3061 (test.test_time.TestLocale) ... ok

======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
test test_time crashed -- : 'cp932' codec can't enco
de character '\x93' in position 495: illegal multibyte sequence
Traceback (most recent call last):
  File "C:\Python32\lib\test\regrtest.py", line 960, in runtest_inner
    indirect_test()
  File "C:\Python32\lib\test\test_time.py", line 244, in test_main
    support.run_unittest(TimeTestCase, TestLocale)
  File "C:\Python32\lib\test\support.py", line 1146, in run_unittest
    _run_suite(suite)
  File "C:\Python32\lib\test\support.py", line 1120, in _run_suite
    result = runner.run(suite)
  File "C:\Python32\lib\unittest\runner.py", line 173, in run
    result.printErrors()
  File "C:\Python32\lib\unittest\runner.py", line 110, in printErrors
    self.printErrorList('FAIL', self.failures)
  File "C:\Python32\lib\unittest\runner.py", line 117, in printErrorList
    self.stream.writeln("%s" % err)
  File "C:\Python32\lib\unittest\runner.py", line 25, in writeln
    self.write(arg)
UnicodeEncodeError: 'cp932' codec can't encode character '\x93' in position 495:
 illegal multibyte sequence
[2/2] test_strptime
test_basic (test.test_strptime.getlang_Tests) ... ok
test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok
test_date_time (test.test_strptime.LocaleTime_Tests) ... ok
test_lang (test.test_strptime.LocaleTime_Tests) ... ok
test_month (test.test_strptime.LocaleTime_Tests) ... ok
test_timezone (test.test_strptime.LocaleTime_Tests) ... FAIL
test_weekday (test.test_strptime.LocaleTime_Tests) ... ok
test_blankpattern (test.test_strptime.TimeRETests) ... ok
test_compile (test.test_strptime.TimeRETests) ... FAIL
test_locale_data_w_regex_metacharacters (test.test_strptime.TimeRETests) ... ok
test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok
test_pattern (test.test_strptime.TimeRETests) ... ok
test_pattern_escaping (test.test_strptime.TimeRETests) ... ok
test_whitespace_substitution (test.test_strptime.TimeRETests) ... ok
test_ValueError (test.test_strptime.StrptimeTests) ... ok
test_bad_timezone (test.test_strptime.StrptimeTests) ... ok
test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok
test_date (test.test_strptime.StrptimeTests) ... ok
test_date_time (test.test_strptime.StrptimeTests) ... ok
test_day (test.test_strptime.StrptimeTests) ... ok
test_defaults (test.test_strptime.StrptimeTests) ... ok
test_escaping (test.test_strptime.StrptimeTests) ... ok
test_fraction (test.test_strptime.StrptimeTests) ... ok
test_hour (test.test_strptime.StrptimeTests) ... ok
test_julian (test.test_strptime.StrptimeTests) ... ok
test_minute (test.test_strptime.StrptimeTests) ... ok
test_month (test.test_strptime.StrptimeTests) ... ok
test_percent (test.test_strptime.StrptimeTests) ... ok
test_second (test.test_strptime.StrptimeTests) ... ok
test_time (test.test_strptime.StrptimeTests) ... ok
test_timezone (test.test_strptime.StrptimeTests) ... ERROR
test_unconverteddata (test.test_strptime.StrptimeTests) ... ok
test_weekday (test.test_strptime.StrptimeTests) ... ok
test_year (test.test_strptime.StrptimeTests) ... ok
test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok
test_all_julian_days (test.test_strptime.JulianTests) ... ok
test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ERROR
test_gregorian_calculation (test.test_strptime.CalculationTests) ... ERROR
test_julian_calculation (test.test_strptime.CalculationTests) ... ERROR
test_week_of_year_and_day_of_week_calculation (test.test_strptime.CalculationTes
ts) ... ok
test_TimeRE_recreation (test.test_strptime.CacheTests) ... ok
test_new_localetime (test.test_strptime.CacheTests) ... ok
test_regex_cleanup (test.test_strptime.CacheTests) ... ok
test_time_re_recreation (test.test_strptime.CacheTests) ... ok

======================================================================
ERROR: test_timezone (test.test_strptime.StrptimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python32\lib\test\test_strptime.py", line 303, in test_timezone
    strp_output = _strptime._strptime_time(strf_output, "%Z")
  File "C:\Python32\lib\_strptime.py", line 482, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "C:\Python32\lib\_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)' does not match
format '%Z'

======================================================================
ERROR: test_day_of_week_calculation (test.test_strptime.CalculationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python32\lib\test\test_strptime.py", line 437, in test_day_of_week_ca
lculation
    format_string)
  File "C:\Python32\lib\_strptime.py", line 482, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "C:\Python32\lib\_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '2010 12 08 14 00 342 \x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\
x9e)' does not match format '%Y %m %d %H %S %j %Z'

======================================================================
ERROR: test_gregorian_calculation (test.test_strptime.CalculationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python32\lib\test\test_strptime.py", line 423, in test_gregorian_calc
ulation
    format_string)
  File "C:\Python32\lib\_strptime.py", line 482, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "C:\Python32\lib\_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '2010 14 58 01 3 342 \x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x
9e)' does not match format '%Y %H %M %S %w %j %Z'

======================================================================
ERROR: test_julian_calculation (test.test_strptime.CalculationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python32\lib\test\test_strptime.py", line 414, in test_julian_calcula
tion
    format_string)
  File "C:\Python32\lib\_strptime.py", line 482, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "C:\Python32\lib\_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '2010 12 08 14 58 01 3 \x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e
\x9e)' does not match format '%Y %m %d %H %M %S %w %Z'

======================================================================
FAIL: test_timezone (test.test_strptime.LocaleTime_Tests)
----------------------------------------------------------------------
test test_strptime crashed -- : 'cp932' codec can't
encode character '\x93' in position 192: illegal multibyte sequence
Traceback (most recent call last):
  File "C:\Python32\lib\test\regrtest.py", line 960, in runtest_inner
    indirect_test()
  File "C:\Python32\lib\test\test_strptime.py", line 557, in test_main
    CacheTests
  File "C:\Python32\lib\test\support.py", line 1146, in run_unittest
    _run_suite(suite)
  File "C:\Python32\lib\test\support.py", line 1120, in _run_suite
    result = runner.run(suite)
  File "C:\Python32\lib\unittest\runner.py", line 173, in run
    result.printErrors()
  File "C:\Python32\lib\unittest\runner.py", line 110, in printErrors
    self.printErrorList('FAIL', self.failures)
  File "C:\Python32\lib\unittest\runner.py", line 117, in printErrorList
    self.stream.writeln("%s" % err)
  File "C:\Python32\lib\unittest\runner.py", line 25, in writeln
    self.write(arg)
UnicodeEncodeError: 'cp932' codec can't encode character '\x93' in position 192:
 illegal multibyte sequence
2 tests failed:
    test_strptime test_time

----------
components: Windows
messages: 123612
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_time test_strptime fails on windows
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 16:37:32 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 15:37:32 +0000
Subject: [New-bugs-announce] [issue10654] test_datetime fails on Python3.2
	windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto :

I'm not sure why this happens, I can see this on
official python3.2 beta1 windows binary.

C:\Python32>.\python -m test.regrtest test_datetime
[1/1] test_datetime
test test_datetime failed -- Traceback (most recent call last):
  File "c:\Python32\lib\test\datetimetester.py", line 1628, in test_computations

    self.assertRaises(TypeError, lambda: a+i)
AssertionError: TypeError not raised by 

1 test failed:
    test_datetime

----------
components: Library (Lib), Windows
messages: 123617
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_datetime fails on Python3.2 windows binary
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 22:50:27 2010
From: report at bugs.python.org (adrian)
Date: Wed, 08 Dec 2010 21:50:27 +0000
Subject: [New-bugs-announce] [issue10655] Wrong powerpc define in
	Python/ceval.c
In-Reply-To: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>
Message-ID: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>


New submission from adrian :

In Python/ceval.c is following line:

#if defined(__ppc__) /* <- Don't know if this is the correct symbol; this
                           section should work for GCC on any PowerPC
                           platform, irrespective of OS.
                           POWER?  Who knows :-) */

which seems wrong and aborts the build on powerpc. Changing it to __powerpc__ fixes it for me.

The following output of gcc confirms it:

$ gcc -dM -E -x c /tmp/foo.c  | grep powerpc
#define __powerpc__ 1
#define __powerpc 1
#define powerpc 1

Whereas there are no defines containing "ppc"

----------
components: Build
messages: 123652
nosy: adrian
priority: normal
severity: normal
status: open
title: Wrong powerpc define in Python/ceval.c
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 04:35:04 2010
From: report at bugs.python.org (Perry Smith)
Date: Thu, 09 Dec 2010 03:35:04 +0000
Subject: [New-bugs-announce] [issue10656] "Out of tree" build fails on AIX
	5.3
In-Reply-To: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za>
Message-ID: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za>


New submission from Perry Smith :

I do "out of tree" builds (I think that is the right term).  I make an
empty directory, cd into it, and then do: 

/configure

followed by make.  This works on most open source pages.  It appears to
be very close to working with Python 2.7.1 but the problem is that it assumes ld_so_aix is in the source tree but it is in the build tree.

I did an "in tree" build using basically just ./configure && make and so far (I'm still testing) that has worked fine.

----------
components: Build
messages: 123668
nosy: pedz
priority: normal
severity: normal
status: open
title: "Out of tree" build fails on AIX 5.3
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 09:28:34 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 09 Dec 2010 08:28:34 +0000
Subject: [New-bugs-announce] [issue10657] os.lstat/os.stat/os.fstat don't
	set st_dev (st_rdev) on	Windows
In-Reply-To: <1291883314.59.0.723924565761.issue10657@psf.upfronthosting.co.za>
Message-ID: <1291883314.59.0.723924565761.issue10657@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto :

I noticed st_dev is not set yet. Attached patch
fill this value, but sometimes it becomes negative
value because dwVolumeSerialNumber is large enough.
Maybe st_dev should be declared as unsigned int.

# I think this is not new feature. Just bug. So I think
# this can go into python3.2.

----------
components: Windows
files: py3k_add_st_dev_and_st_rdev.patch
keywords: patch
messages: 123673
nosy: ocean-city
priority: normal
severity: normal
status: open
title: os.lstat/os.stat/os.fstat don't set st_dev (st_rdev) on Windows
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19984/py3k_add_st_dev_and_st_rdev.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 13:11:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 09 Dec 2010 12:11:29 +0000
Subject: [New-bugs-announce] [issue10658] Link to source code is broken
In-Reply-To: <1291896689.57.0.983903414359.issue10658@psf.upfronthosting.co.za>
Message-ID: <1291896689.57.0.983903414359.issue10658@psf.upfronthosting.co.za>


New submission from anatoly techtonik :

http://docs.python.org/library/queue.html

----------
assignee: docs at python
components: Documentation
messages: 123677
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Link to source code is broken
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 14:20:33 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 09 Dec 2010 13:20:33 +0000
Subject: [New-bugs-announce] [issue10659] Hook scripts for immediate doc
	build system
In-Reply-To: <1291900833.32.0.658396193822.issue10659@psf.upfronthosting.co.za>
Message-ID: <1291900833.32.0.658396193822.issue10659@psf.upfronthosting.co.za>


New submission from anatoly techtonik :

When a new revision is committed to documentation, it will be nice to have hook scripts that start documentation build process on development server. 

Another hook script may also analyze commit message, extract ticket number, branch and revision from it. Then post a comment with a link to development version of documentation and close the ticket.

See how it works on Google Code http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control

----------
assignee: docs at python
components: Documentation
messages: 123680
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Hook scripts for immediate doc build system

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 16:33:42 2010
From: report at bugs.python.org (=?utf-8?q?Herv=C3=A9_Cauwelier?=)
Date: Thu, 09 Dec 2010 15:33:42 +0000
Subject: [New-bugs-announce] [issue10660] format() to lower and uppercase
In-Reply-To: <1291908822.96.0.536076178004.issue10660@psf.upfronthosting.co.za>
Message-ID: <1291908822.96.0.536076178004.issue10660@psf.upfronthosting.co.za>


New submission from Herv? Cauwelier :

Hexadecimals can be formatted to lower and uppercase:

>>> '{0:x}'.format(123)
'7b'
>>> '{0:X}'.format(123)
'7B'

I would like the same thing for strings:

>>> '{0.lastname:u} {0.firstname}'.format(user)
'DOE John'

I first thought using "S" for uppercase, but "s" is not available for lowercase. So I thought about "u" and "l".

The alternative is to write:

>>> '{0} {1}'.format(user.lastname.upper(), user.firstname)
'DOE John'

But I find it less compact and elegant.

----------
components: Interpreter Core
messages: 123684
nosy: Herv? Cauwelier
priority: normal
severity: normal
status: open
title: format() to lower and uppercase
type: feature request
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 17:54:10 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 09 Dec 2010 16:54:10 +0000
Subject: [New-bugs-announce] [issue10661] ElementTree QName has a very
	uninformative repr()
In-Reply-To: <1291913650.88.0.227621889863.issue10661@psf.upfronthosting.co.za>
Message-ID: <1291913650.88.0.227621889863.issue10661@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone :

This is somewhat unfortunate behavior:

>>> from xml.etree.ElementTree import QName
>>> QName('foo')

>>> 

It becomes even more apparent when encountered in a situation like this:

>>> print {QName('foo'): 'bar', QName('baz'): 'quux'}
{: 'bar', : 'quux'}
>>> 

I would like to see QName.__repr__ return something like '' % (text,)

----------
messages: 123687
nosy: exarkun
priority: normal
severity: normal
status: open
title: ElementTree QName has a very uninformative repr()
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 18:53:56 2010
From: report at bugs.python.org (Christian Oudard)
Date: Thu, 09 Dec 2010 17:53:56 +0000
Subject: [New-bugs-announce] [issue10662] Typo in concurrent.futures,
	"seperate"
In-Reply-To: <1291917236.85.0.349427254238.issue10662@psf.upfronthosting.co.za>
Message-ID: <1291917236.85.0.349427254238.issue10662@psf.upfronthosting.co.za>


New submission from Christian Oudard :

Found the misspelling "seperate" in two places in the concurrent.futures library module.

Patch attached, correcting the spelling to "separate".

----------
files: seperate.patch
keywords: patch
messages: 123688
nosy: Christian.Oudard
priority: normal
severity: normal
status: open
title: Typo in concurrent.futures, "seperate"
versions: Python 3.2
Added file: http://bugs.python.org/file19988/seperate.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 20:25:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Dec 2010 19:25:31 +0000
Subject: [New-bugs-announce] [issue10663] configure shouldn't set a default
	OPT
In-Reply-To: <1291922731.34.0.0931517118305.issue10663@psf.upfronthosting.co.za>
Message-ID: <1291922731.34.0.0931517118305.issue10663@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

The configure.in sets a default OPT of "-O" if none was set by the user, but I think that's wrong. The user could simply pass optimization flags as part of CFLAGS instead, and then the contents of OPT could conflict with that of CFLAGS (which is annoying to debug when you don't know what is happening exactly).

Besides, "-O" is hardly an useful default value for any compiler. I would advocate trimming down the magic and letting OPT empty/undefined if that's what the user asks for (and expects). What do you think?

----------
components: Build
messages: 123695
nosy: barry, dmalcolm, laca, pitrou
priority: normal
severity: normal
status: open
title: configure shouldn't set a default OPT
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 22:11:02 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 09 Dec 2010 21:11:02 +0000
Subject: [New-bugs-announce] [issue10664] xml.sax.expatreader should support
	namespace prefixes
In-Reply-To: <1291929062.2.0.554979073686.issue10664@psf.upfronthosting.co.za>
Message-ID: <1291929062.2.0.554979073686.issue10664@psf.upfronthosting.co.za>


New submission from Fred L. Drake, Jr. :

The xml.sax.expatreader module pre-dates prefix reporting from Expat, and should be modified to support the feature_namespace_prefixes feature instead of complaining that Expat doesn't support prefixes.

----------
assignee: fdrake
components: XML
messages: 123699
nosy: fdrake
priority: normal
severity: normal
stage: needs patch
status: open
title: xml.sax.expatreader should support namespace prefixes
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 22:31:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 21:31:16 +0000
Subject: [New-bugs-announce] [issue10665] Update and expand unicodedata
	module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky :

unicodedata module documentation has not been updated to reflect transition to 6.0.  Attached patch fixes the version and unicode.org links and starts making the documentation rely less on the unicode.org pages for basic understanding of the provided functionality.

I am posting work in progress to solicit feedback on how much of the Unicode Standard information we would want to present here.

On of the goals of this patch is to provide a standard reference that can be used throughout the library manual for basic Unicode concepts without sending the reader over to unicode.org.

----------
assignee: docs at python
components: Documentation
files: unicodedata-doc.diff
keywords: patch
messages: 123700
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Update and expand unicodedata module documentation
versions: Python 3.2
Added file: http://bugs.python.org/file19990/unicodedata-doc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 22:44:26 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 09 Dec 2010 21:44:26 +0000
Subject: [New-bugs-announce] [issue10666] OS X installer variants have
	confusing readline	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>


New submission from Ned Deily :

32-bit-only OS X installers build and link to a copy of the GNU readline library for use by the readline module in the standard library.  But, the newer 64-bit/32-bit installer variants for 2.7 and 3.2 link to the OS X supplied BSD editline (libedit) library using its GNU readline compatibility interface.  This creates a confusing situation for users: depending on which installer variant is used for 2.7 or 3.2, the commands needed to enable things like tab completion.

Here's a snippet of what I have in my startup file:

    import readline
    import rlcompleter
    if 'libedit' in readline.__doc__:
        readline.parse_and_bind("bind ^I rl_complete")
    else:
        readline.parse_and_bind("tab: complete")

While obviously this can be handled, it seems like an unnecessary burden on users.  I think the primary reason for adding the editline support was to make it simpler for developers building their own Pythons.  That's not a concern for the installer build.  Another concern may have been to avoid shipping a copy of GNU readline which is GPL-licensed.  (The installer currently, to the best of my knowledge, does not document in a README or elsewhere that GNU readline is included.)  That seems a problem.  This disparity also could cause problems elsewhere (see Issue5845).

I see two solutions:

1. (trivial) Change the installer to always build and include GNU readline regardless of SDK (today, editline is used with builds using SDK 10.5 or higher).  

2. (TBD) Build and link with the open-source version of editline for all installers.

In either case, the installer should include license info on included 3rd-party libraries somewhere in the installer README and/or installed files.

----------
assignee: ronaldoussoren
components: Build, Macintosh
messages: 123701
nosy: ned.deily, ronaldoussoren
priority: high
severity: normal
stage: needs patch
status: open
title: OS X installer variants have confusing readline differences
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 23:59:00 2010
From: report at bugs.python.org (Justin Peel)
Date: Thu, 09 Dec 2010 22:59:00 +0000
Subject: [New-bugs-announce] [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>


New submission from Justin Peel :

I put the Counter's update and __missing__ methods into C code. The rest of the existing methods remain the same. The new Counter is at least 2x-10x (or more) faster for updating depending on the input. I also added a new method, update_fromsubs, which is documented below the timings for updating a Counter.

Here are a few examples to demonstrate the speed of the new update function:

Counting list(range(100))*100 - 
    Old Counter: 18.6 msec
    New Counter: 1.43
13x speed-up

Counting range(10000) - 
    Old Counter: 21.5 msec
    New Counter: 3.84 msec
5.6x speed-up

Counter generator  i % 100 for i in range(10000) - 
    Old Counter: 36.7 msec
    New Counter: 17.5 msec
2.1x speed-up

and the __missing__ method being in C makes getting missing keys about twice as fast.

Also, I added a new method, update_fromsubs, which counts subarrays/substrings of a sequence. This method only works with immutable sequences like tuples, bytes, and unicode objects. The method is of the form

update_fromsubs(seq, frame[, step[, lo[, hi]]])

where frame is the size of the subarrays, step is how far to move forward after each subarray, and lo and hi are the respective starting and ending indices to count subarrays within the sequence.

For instance,

    c = Counter()
    c.update_fromsubs('abcd', 2)

yields

    Counter({'cd': 1, 'ab': 1, 'bc': 1})

and

    d = Counter()
    d.update_fromsubs('abcd', 2, 2)

yields

    Counter({'ab': 1, 'cd: 1})

These sorts of operations could be done with generators in a manner like

    Counter(s[i:i+2] for i in range(0, len(s)-1))

but it can be about twice as fast by using update_fromsubs. Here's an example

Counting subarrays of length 2 of "ab"*10000:
    update_fromsubs:            30.8 ms
    New Counter w/ generator:   54.3 ms
    Old Counter w/ generator:   98.8 ms

This method would probably be most useful in processing strings, but there may be other uses. If it is accepted, please feel to change the method name and parameters. I especially wasn't sure what to call this method (update_fromsubsequences seemed rather long).

----------
components: Extension Modules, Library (Lib)
files: counterpatch.diff
keywords: patch
messages: 123706
nosy: jpeel, rhettinger
priority: normal
severity: normal
status: open
title: collections.Counter object in C
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file19992/counterpatch.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 02:54:24 2010
From: report at bugs.python.org (Alex)
Date: Fri, 10 Dec 2010 01:54:24 +0000
Subject: [New-bugs-announce] [issue10668] Array tests have nonsense in them
In-Reply-To: <1291946064.7.0.737728042114.issue10668@psf.upfronthosting.co.za>
Message-ID: <1291946064.7.0.737728042114.issue10668@psf.upfronthosting.co.za>


New submission from Alex :

In ArraySubclassWithKwargs, when __init__ is called it doesn't actually pass self to `array.array.__init__`, this doesn't actually cause errors because the contents of the array isn't tested anywhere.

----------
components: Library (Lib)
messages: 123714
nosy: alex
priority: normal
severity: normal
status: open
title: Array tests have nonsense in them
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 06:40:47 2010
From: report at bugs.python.org (Rusi)
Date: Fri, 10 Dec 2010 05:40:47 +0000
Subject: [New-bugs-announce] [issue10669] Remove Deprecation Warnings
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>


New submission from Rusi :

I am trying to port some app from 2.x to 3.x
Terry Reedy suggested using 2.7
I get deprecation warnings (with -3 flag)

I would be good to have a place to check all such and have suggested solutions

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 123716
nosy: RusiMody
priority: normal
severity: normal
status: open
title: Remove Deprecation Warnings
type: feature request
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 09:16:54 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 10 Dec 2010 08:16:54 +0000
Subject: [New-bugs-announce] [issue10670] Provide search scope limits
In-Reply-To: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>
Message-ID: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>


New submission from anatoly techtonik :

When searching docs (e.g. for http://docs.python.org/dev/search.html?q=unicode&check_keywords=yes&area=default) I'd like to filter out C API.

----------
assignee: docs at python
components: Documentation
messages: 123719
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Provide search scope limits

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 13:16:47 2010
From: report at bugs.python.org (Kirill Subbotin)
Date: Fri, 10 Dec 2010 12:16:47 +0000
Subject: [New-bugs-announce] [issue10671] urllib2 redirect to another host
	doesn't work
In-Reply-To: <1291983407.25.0.106124609797.issue10671@psf.upfronthosting.co.za>
Message-ID: <1291983407.25.0.106124609797.issue10671@psf.upfronthosting.co.za>


New submission from Kirill Subbotin :

When you open url which redirects to another host (either with 301 or 302), HTTPRedirectHandler keeps "Host" header from the previous request, which leads to a error. Instead a host should be taken from a new location url.

Attached patch is tested with Python 2.6.5.

----------
components: Library (Lib)
files: urllib2.diff
keywords: patch
messages: 123729
nosy: Kirax
priority: normal
severity: normal
status: open
title: urllib2 redirect to another host doesn't work
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19997/urllib2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 13:48:27 2010
From: report at bugs.python.org (Mayweed)
Date: Fri, 10 Dec 2010 12:48:27 +0000
Subject: [New-bugs-announce] [issue10672] ["with"] new in version 2.6
	instead of 2.5
In-Reply-To: <1291985307.04.0.397255362186.issue10672@psf.upfronthosting.co.za>
Message-ID: <1291985307.04.0.397255362186.issue10672@psf.upfronthosting.co.za>


New submission from Mayweed :

In the documentation, the statement "with" is marked as:
"New in version 2.5."
(http://docs.python.org/reference/compound_stmts.html#the-with-statement)

This new statement is new in version 2.6 !

----------
assignee: docs at python
components: Documentation
messages: 123731
nosy: docs at python, karmaguedon
priority: normal
severity: normal
status: open
title: ["with"] new in version 2.6 instead of 2.5
versions: Python 2.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 15:36:18 2010
From: report at bugs.python.org (Brian Cain)
Date: Fri, 10 Dec 2010 14:36:18 +0000
Subject: [New-bugs-announce] [issue10673] multiprocess.Process join method -
	timeout	indistinguishable from success
In-Reply-To: <1291991778.63.0.145134143934.issue10673@psf.upfronthosting.co.za>
Message-ID: <1291991778.63.0.145134143934.issue10673@psf.upfronthosting.co.za>


New submission from Brian Cain :

When calling Process' join([timeout]) method, the timeout expiration case is indistinguishable from the successful join.  I suppose the 'exitcode' attribute can deliver the necessary information, but perhaps join could stand on its own.

If join() shouldn't be changed, could we make explicit reference to the exitcode attribute in the documentation?

----------
components: Library (Lib)
files: Process_join.patch
keywords: patch
messages: 123733
nosy: Brian.Cain
priority: normal
severity: normal
status: open
title: multiprocess.Process join method - timeout indistinguishable from success
type: feature request
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19998/Process_join.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 17:58:03 2010
From: report at bugs.python.org (Ori Avtalion)
Date: Fri, 10 Dec 2010 16:58:03 +0000
Subject: [New-bugs-announce] [issue10674] Unused dictmaker symbol in 2.*
	grammar
In-Reply-To: <1292000283.53.0.266717030869.issue10674@psf.upfronthosting.co.za>
Message-ID: <1292000283.53.0.266717030869.issue10674@psf.upfronthosting.co.za>


New submission from Ori Avtalion :

Using trunk r87157

The Grammar/Grammar file defines a "dictmaker" symbol that is no longer referenced in any other symbol. It should be removed.

----------
components: Interpreter Core
messages: 123738
nosy: salty-horse
priority: normal
severity: normal
status: open
title: Unused dictmaker symbol in 2.* grammar
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 20:58:36 2010
From: report at bugs.python.org (Jay Moorthi)
Date: Fri, 10 Dec 2010 19:58:36 +0000
Subject: [New-bugs-announce] [issue10675] unittest should have an
	assertChanges context manager
In-Reply-To: <1292011116.36.0.95630190465.issue10675@psf.upfronthosting.co.za>
Message-ID: <1292011116.36.0.95630190465.issue10675@psf.upfronthosting.co.za>


New submission from Jay Moorthi :

It would be useful to have a new assert method in the unittest.TestCase class that checks to see if a value has changed.  I wrote a quick and dirty version like so:

class MySpecialTestCase(unittest.TestCase):
    @contextmanager
    def assertChanges(self, thing, attr=None, by=None):
        def get_value(thing, attr):
            if callable(thing):
                value = thing()
            else:
                value = getattr(thing, attr)
            return value

        old_value = get_value(thing, attr)
        yield
        new_value = get_value(thing, attr)

        if by is None:
            self.assertNotEqual(new_value, old_value)
        else:
            self.assertEqual(new_value - old_value, by)

I'm sure something better can be done to take better advantage of the unittest module's diffing tools, etc.

----------
messages: 123745
nosy: Jay.Moorthi
priority: normal
severity: normal
status: open
title: unittest should have an assertChanges context manager
type: feature request
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 21:25:46 2010
From: report at bugs.python.org (Philip Bober)
Date: Fri, 10 Dec 2010 20:25:46 +0000
Subject: [New-bugs-announce] [issue10676] Confusing note in Numeric Types
In-Reply-To: <1292012746.16.0.939598765846.issue10676@psf.upfronthosting.co.za>
Message-ID: <1292012746.16.0.939598765846.issue10676@psf.upfronthosting.co.za>


New submission from Philip Bober :

In the Python Standard Library reference, section 5.4: Numeric Types, the table of operators/functions has the following unclear note:

(4)Complex floor division operator, modulo operator, and divmod().
   Deprecated since version 2.3: Instead convert to float using abs() if appropriate.

The intention of this note is to indicate that //,%, and divmod shouldn't be used with complex numbers, but the phrasing is bad and the note being on generic operators makes it sound like the operators themselves are deprecated, not just for complex numbers. 

There was an earlier bugfix (621708, on the previous tracker. Archive: http://mail.python.org/pipermail/python-bugs-list/2002-October/013913.html) which fixed this bad wording elsewhere in the docs (Section 5.6 Binary arithmetic operations in the Python Reference Manual) but it seems the same wording was in both documents and it was only patched in one of them. 

It was replaced with:
"Deprecated since version 2.3: The floor division operator, the modulo operator, and the divmod() function are no longer defined for complex numbers. Instead, convert to a floating point number using the abs() function if appropriate."

----------
assignee: docs at python
components: Documentation
messages: 123750
nosy: Philip.Bober, docs at python
priority: normal
severity: normal
status: open
title: Confusing note in Numeric Types
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 12:39:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Dec 2010 11:39:10 +0000
Subject: [New-bugs-announce] [issue10677] "make altinstall" includes ABI
	codes in versioned	executable name
In-Reply-To: <1292067550.81.0.896632970481.issue10677@psf.upfronthosting.co.za>
Message-ID: <1292067550.81.0.896632970481.issue10677@psf.upfronthosting.co.za>


New submission from Nick Coghlan :

"make altinstall" is currently installing python3.2m rather than python3.2.

Since PEP 3149 makes no mention of changing the executable name, this should be fixed to correctly install the executable as python3.2.

I suspect this will also affect a "make install", but will be obscured in that case since the python3 symlink will still do the right thing. (I haven't tried it, since I don't want to clobber the Canonical provided 3.1 installation)

----------
assignee: barry
messages: 123782
nosy: barry, georg.brandl, ncoghlan
priority: release blocker
severity: normal
status: open
title: "make altinstall" includes ABI codes in versioned executable name
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 12:44:30 2010
From: report at bugs.python.org (Phyo Arkar Lwin)
Date: Sat, 11 Dec 2010 11:44:30 +0000
Subject: [New-bugs-announce] [issue10678] email.utils.mktime_tz Giving wrong
	result , by ignoring Timezone  that comes from value of  parsedate .
In-Reply-To: <1292067870.01.0.821446492471.issue10678@psf.upfronthosting.co.za>
Message-ID: <1292067870.01.0.821446492471.issue10678@psf.upfronthosting.co.za>


New submission from Phyo Arkar Lwin :

DESCRIPTION:

I am trying to parse Time Zone information out of email messages and i found out that mktime_tz is totally ignoring TimeZone information from parsedate_tz.


VERSION: 2.6.5
CODE and RESULTS:


from time import mktime
from email.utils import parsedate,parsedate_tz,formatdate,mktime_tz

parsedate_tz('Sat, 10 Apr 2004 03:50:19 +400')
>>> (2004, 4, 10, 3, 50, 19, 0, 1, -1, 14400)


mktime_tz(parsedate_tz('Sat, 10 Apr 2004 03:50:19 +400'))
>>>1081554619.0
mktime(parsedate('Sat, 10 Apr 2004 03:50:19'))
>>>1081545619.0

Same????

formatdate(mktime_tz(parsedate_tz('Sat, 10 Apr 2004 03:50:19 +400')))
>>>'Fri, 09 Apr 2004 23:50:19 -0000' # WRONG TOTALLY

Expected Result:
>>>'Sat, 10 Apr 2004 03:50:19 +400'

----------
components: None
messages: 123783
nosy: Phyo.Arkar.Lwin
priority: normal
severity: normal
status: open
title: email.utils.mktime_tz Giving wrong result , by ignoring Timezone  that comes from value of  parsedate .
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 12:47:38 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Dec 2010 11:47:38 +0000
Subject: [New-bugs-announce] [issue10679] "make altinstall" will clobber OS
	provided scripts
In-Reply-To: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>
Message-ID: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>


New submission from Nick Coghlan :

"make altinstall" installs "2to3", "pydoc3" and "idle3" without version specific names.

This was at least a deliberate decision in the case of 2to3, but there doesn't appear to be any reason not to use a properly qualified version suffix on the pydoc and idle executables.

----------
messages: 123784
nosy: benjamin.peterson, georg.brandl, ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: "make altinstall" will clobber OS provided scripts
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 17:00:48 2010
From: report at bugs.python.org (Mads Michelsen)
Date: Sat, 11 Dec 2010 16:00:48 +0000
Subject: [New-bugs-announce] [issue10680] argparse: titles and
	add_mutually_exclusive_group don't	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>


New submission from Mads Michelsen :

This is a follow-up to Issue 58 from the Google Project Hosting bug tracker (http://code.google.com/p/argparse/issues/detail?id=58). I couldn't find any equivalent/re-posting of it here, so I took the liberty of creating a new one - despite the bug being marked 'WontFix' on Google. The reason for this is that I cannot make the suggested workaround... well, work. 

The root problem: the argparse parser add_mutually_exclusive_group method does not accept title or description arguments. 

The workaround: steven.bethard suggests on google to create a 'straight' dummy group (i.e. one made using the title-accepting add_argument_group method) and then attach the mutually exclusive group to the dummy group - which is attached to the parser itself. 

The problem: while the group does appear as a group with title on the help output, the group does not appear to actually _be_ mutually exclusive (I get no objections to running several arguments from the same group together) nor does it display as mutually exclsuive on the help output. 

Please see attached file for code + resulting output.

(I hope I'm doing this right - this is my first bug report, so bear with and instruct me if I'm getting it wrong)

----------
components: Library (Lib)
files: argsconfig.txt
messages: 123797
nosy: Mads.Michelsen
priority: normal
severity: normal
status: open
title: argparse: titles and add_mutually_exclusive_group don't mix (even with workaround)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20014/argsconfig.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 19:12:59 2010
From: report at bugs.python.org (Phil Thompson)
Date: Sat, 11 Dec 2010 18:12:59 +0000
Subject: [New-bugs-announce] [issue10681] PySlice_GetIndices() signature
	changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>


New submission from Phil Thompson :

In Python v3.2b1 the type of the first argument of PySlice_GetIndices() and PySlice_GetIndicesEx() has changed from PySliceObject* to PyObject*.

The documentation does not reflect this change.

Which is correct, the source code or the documentation?

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 123809
nosy: Phil.Thompson, docs at python
priority: normal
severity: normal
status: open
title: PySlice_GetIndices() signature changed
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 12 05:30:02 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 12 Dec 2010 04:30:02 +0000
Subject: [New-bugs-announce] [issue10682] With '*args' or even bare '*' in
	def/call argument list, trailing comma causes SyntaxError
In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>
Message-ID: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski :

Let examples speak:

    def x(a, z): pass      # this is ok
    def x(a, z,): pass     # this is ok
    def x(a, *, z): pass   # this is ok in Py3k
    def x(a, *, z,): pass  # but this causes SyntaxError (!)

    def x(a, *args): pass      # this is ok
    def x(a, *args,): pass     # but this causes SyntaxError
    def x(a, **kwargs): pass   # this is ok
    def x(a, **kwargs,): pass  # but this causes SyntaxError
    def x(a, *args, z): pass   # this is ok in Py3k
    def x(a, *args, z,): pass  # but this causes SyntaxError (!)

And similarly -- calls:

    def x(*args, **kwargs): pass
    x(1, *(2,3,4))        # this is ok
    x(1, *(2,3,4),)       # but this causes SyntaxError
    x(1, **{5: 6})        # this is ok
    x(1, **{5: 6},)       # but this causes SyntaxError
    x(1, 2, 3, 4, z=5)    # this is ok
    x(1, *(2,3,4), z=5)   # this is ok in Py2.6+ and Py3k
    x(1, *(2,3,4), z=5,)  # but this causes SyntaxError (!)

Similar problem was discussed years ago as a docs bug -- see: issue798652, but -- as inconsistent with intuition and a general Python rule that trailing commas are ok in argument lists and sequence literals (except empty ones) -- it seems to be rather a language syntax definition issue.

Now, after introducing new syntax possibilities in Py2.6 and especially Py3k (see the examples above), the issue is even much more painful.

Also, please consider that Py3k's function annotations encourage to format argument list in one-argument-per-line-manner:

    def my_func(
        spam:"Very tasty and nutritious piece of food",
        ham:"For experts only",
        *more_spam:"Not less tasty and not less nutritious!",
        spammish:"Nobody expects this!"='Inquisition',
    ):
        ...

----------
components: Interpreter Core
messages: 123823
nosy: zuo
priority: normal
severity: normal
status: open
title: With '*args' or even bare '*' in def/call argument list, trailing comma causes SyntaxError
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 12 06:59:09 2010
From: report at bugs.python.org (honglei jiang)
Date: Sun, 12 Dec 2010 05:59:09 +0000
Subject: [New-bugs-announce] [issue10683] PreLinkEvent error under VC2010
In-Reply-To: <1292133549.4.0.198657844522.issue10683@psf.upfronthosting.co.za>
Message-ID: <1292133549.4.0.198657844522.issue10683@psf.upfronthosting.co.za>


New submission from honglei jiang :

1>PreLinkEvent:
1>  Description: Generate build information...
1>  Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
1>  Copyright (C) Microsoft Corporation.  All rights reserved.
1>  
1>  cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD ..\Modules\getbuildinfo.c -Fo"E:\Python-3.2b1\PCbuild\Win32-temp-Release\pythoncore"\getbuildinfo.o" -I..\Include -I..\PC
1>  getbuildinfo.c
1>..\Modules\getbuildinfo.c(1): fatal error C1083: Cannot open include file: 'Python.h': No such file or directory
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(108,5): error MSB3073: The command ""E:\Python-3.2b1\PCbuild\make_buildinfo.exe" Release "E:\Python-3.2b1\PCbuild\Win32-temp-Release\pythoncore\"
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(108,5): error MSB3073: :VCEnd" exited with code -1.
1>
1>Build FAILED.

the following will be ok:
cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD ..\Modules\getbuildinfo.c -I..\Include -I..\PC -Fo"E:\Python-3.2b1\PCbuild\Win32-temp-Release\pythoncore"\getbuildinfo.o" 

included dir should ahead of -F options.

----------
components: Build
messages: 123826
nosy: honglei.jiang
priority: normal
severity: normal
status: open
title: PreLinkEvent error under VC2010
type: compile error
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 12 11:18:44 2010
From: report at bugs.python.org (harish)
Date: Sun, 12 Dec 2010 10:18:44 +0000
Subject: [New-bugs-announce] [issue10684] Shutil.move deletes file/folder in
	windows while renaming
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>


New submission from harish :

Shutil.move method deletes a file/folder when the file/folder is renamed to same name but different case.
eg.
shutil.move('folder','Folder')

----------
components: Windows
messages: 123833
nosy: harish
priority: normal
severity: normal
status: open
title: Shutil.move deletes file/folder in windows while renaming
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 12 13:34:30 2010
From: report at bugs.python.org (Rusi)
Date: Sun, 12 Dec 2010 12:34:30 +0000
Subject: [New-bugs-announce] [issue10685] trace does nto ignore
	--ignore-module
In-Reply-To: <1292157270.73.0.200325030661.issue10685@psf.upfronthosting.co.za>
Message-ID: <1292157270.73.0.200325030661.issue10685@psf.upfronthosting.co.za>


New submission from Rusi :

When running trace, I get a a lot of lines like:
filename: /usr/lib/python2.7/cmd.py, modulename: cmd, funcname: Cmd

That is to say system modules are shown in the trace whereas I only want to see the code I am working on

Ive tried
python2.7 -m trace --listfuncs tt.py --ignore-dir '/usr/lib' > const-dir.trace

python2.7 -m trace --listfuncs --ignore-module cmd tt.py  > const.trace

python2.7 -m trace --ignore-module --listfuncs  cmd tt.py  > const.trace

----------
messages: 123836
nosy: RusiMody
priority: normal
severity: normal
status: open
title: trace does nto ignore --ignore-module
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 12 19:01:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 18:01:49 +0000
Subject: [New-bugs-announce] [issue10686] email.Generator should use
	unknown-8bit encoded words	for headers with 8 bit data
In-Reply-To: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>
Message-ID: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>


New submission from R. David Murray :

This is a followon to Issue 4661.  The fix for that issue introduced a way to parse messages containing 8bit bytes.  When Generator is called on a model containing 8 bit bytes, it converts it to 7bit clean.  There is, however, a bug in this conversion process: currently when encountering 8bit bytes in headers, it simply replaces then with ?.  According to the RFCs[*], what it should do instead is to replace them with encoded words using the 'charset' "unknown-8bit".

[*] I'm specifically referring to RFC 1428...email is effectively acting as a translating gateway when requested to do the 8bit to 7bit conversion.  Although that RFC does not explicitly say that the unknown-8bit charset should be used in encoded words, it does imply it strongly in its section 3 prescription.

----------
assignee: r.david.murray
messages: 123842
nosy: r.david.murray
priority: high
severity: normal
stage: needs patch
status: open
title: email.Generator should use unknown-8bit encoded words for headers with 8 bit data
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 12 19:34:05 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 12 Dec 2010 18:34:05 +0000
Subject: [New-bugs-announce] [issue10687] Python fails to install with empty
	ABI flags
In-Reply-To: <1292178845.71.0.0485366537198.issue10687@psf.upfronthosting.co.za>
Message-ID: <1292178845.71.0.0485366537198.issue10687@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis :

$ make DESTDIR=/var/tmp/portage/dev-lang/python-3.2_pre20101212/image/ altinstall 
Creating directory /usr/bin
Creating directory /usr/lib64
/usr/bin/install -c python /var/tmp/portage/dev-lang/python-3.2_pre20101212/image//usr/bin/python3.2
if test -f /var/tmp/portage/dev-lang/python-3.2_pre20101212/image//usr/bin/python3.2 -o -h /var/tmp/portage/dev-lang/python-3.2_pre20101212/image//usr/bin/python3.2; \
then rm -f /var/tmp/portage/dev-lang/python-3.2_pre20101212/image//usr/bin/python3.2; \
else true; \
fi
(cd /var/tmp/portage/dev-lang/python-3.2_pre20101212/image//usr/bin; ln python3.2 python3.2)
ln: accessing `python3.2': No such file or directory
make: *** [altbininstall] Error 1

----------
components: Build
messages: 123845
nosy: Arfrever, barry
priority: normal
severity: normal
status: open
title: Python fails to install with empty ABI flags
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 12 23:38:45 2010
From: report at bugs.python.org (CZ)
Date: Sun, 12 Dec 2010 22:38:45 +0000
Subject: [New-bugs-announce] [issue10688] pydoc removes lib directory
In-Reply-To: <1292193525.59.0.524407556664.issue10688@psf.upfronthosting.co.za>
Message-ID: <1292193525.59.0.524407556664.issue10688@psf.upfronthosting.co.za>


New submission from CZ :

when pydoc is run with "python -m" (e.g., "python -m pydoc map"),
you will receive an error message: No module named tempfile.

The reason is pydoc removes 'C:\Python26\lib' (in my case) from sys.path.

But you can run it as "python " because the lib directory appears twice in the sys.path in such situation.

----------
messages: 123853
nosy: CZ
priority: normal
severity: normal
status: open
title: pydoc removes lib directory
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 03:22:21 2010
From: report at bugs.python.org (Pierre Vinet)
Date: Mon, 13 Dec 2010 02:22:21 +0000
Subject: [New-bugs-announce] [issue10689] _scproxy extension is NOT build
In-Reply-To: <1292206941.33.0.0915401161156.issue10689@psf.upfronthosting.co.za>
Message-ID: <1292206941.33.0.0915401161156.issue10689@psf.upfronthosting.co.za>


New submission from Pierre Vinet :

>From Python 2.7 http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tar.bz2 released on November 27th, 2010.

At compile time :

 $ ../Python-2.7.1/configure --enable-framework
 $ make

we obtain within standard output:

building '_scproxy' extension
creating build/Python-2.7.1
creating build/Python-2.7.1/Mac
creating build/Python-2.7.1/Mac/Modules
/sw/lib/gcc4.2/bin/gcc -fno-strict-aliasing -fno-common -dynamic -O2 -Wall -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/vinp/Documents/informatique/python/installation/version-2.7.1/Python-2.7.1/Mac/Include -I. -IInclude -I../Python-2.7.1/Include -I/sw/include -I/opt/macports/include -I/opt/include -I/usr/X11R6/include -I/usr/include -I/usr/local/include -I/Users/vinp/Documents/informatique/python/installation/version-2.7.1/Python-2.7.1/Include -I/Users/vinp/Documents/informatique/python/installation/version-2.7.1/objet_fwk -c ../Python-2.7.1/Mac/Modules/_scproxy.c -o build/temp.macosx-10.3-ppc-2.7/../Python-2.7.1/Mac/Modules/_scproxy.o
../Python-2.7.1/Mac/Modules/_scproxy.c: In function ?get_proxy_settings?:
../Python-2.7.1/Mac/Modules/_scproxy.c:67: error: lvalue required as unary ?&? operand

Then the module _scproxy is not build, which yield to 35 tests crashes:
    test_SimpleHTTPServer test___all__ test_cgi test_codecmaps_cn
    test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
    test_codecmaps_tw test_cookielib test_distutils test_email
    test_email_codecs test_email_renamed test_httpservers test_mailbox
    test_mimetypes test_normalization test_old_mailbox test_pyclbr
    test_robotparser test_sax test_site test_smtplib test_smtpnet
    test_ssl test_sundry test_urllib test_urllib2
    test_urllib2_localnet test_urllib2net test_urllibnet test_wsgiref
    test_xml_etree test_xml_etree_c test_xmlrpc

$ uname -a
Darwin ts-77.rmkipqxaas02.globetrotter.net 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc

Compiler gcc (GCC) is 4.2.4 (2007)

Thanks,

Pierre Vinet

----------
assignee: ronaldoussoren
components: Build, Macintosh, Tests
messages: 123857
nosy: ronaldoussoren, vinp
priority: normal
severity: normal
status: open
title: _scproxy extension is NOT build
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 03:53:07 2010
From: report at bugs.python.org (David)
Date: Mon, 13 Dec 2010 02:53:07 +0000
Subject: [New-bugs-announce] [issue10690] IDLE Crash when running/saving
	Module
In-Reply-To: <1292208787.46.0.425889720507.issue10690@psf.upfronthosting.co.za>
Message-ID: <1292208787.46.0.425889720507.issue10690@psf.upfronthosting.co.za>


New submission from David :

Hello, 

Python version 2.7.1 x64
Mac OS X 10.6.5 x86_64
Tk/Tcl version 8.5/4

Python will crash when saving/running/checking a module, i tried googling for a few hours to come up to NOTHING for a solution. Hopefully we can both get this fixed. Thank you.

Attached is a Python crash log.

----------
components: IDLE
files: Python_2010-12-12-214329_Darwin.txt
messages: 123859
nosy: David_Anon
priority: normal
severity: normal
status: open
title: IDLE Crash when running/saving Module
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file20027/Python_2010-12-12-214329_Darwin.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 09:26:09 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 13 Dec 2010 08:26:09 +0000
Subject: [New-bugs-announce] [issue10691] make testall no longer working on
	Darwin
In-Reply-To: <1292228769.61.0.198684606781.issue10691@psf.upfronthosting.co.za>
Message-ID: <1292228769.61.0.198684606781.issue10691@psf.upfronthosting.co.za>


New submission from Ismail Donmez :

Using py3k r87206 on Mac OSX 10.6.5,

[~/Sources/py3k]> make testall
running build
running build_ext
building dbm using ndbm

Python build finished, but the necessary bits to build these modules were not found:
_gdbm              ossaudiodev        spwd            
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

running build_scripts
find ./Lib -name '*.py[co]' -print | xargs rm -f
./python -Wd -E -bb  ./Lib/compileall.py
Traceback (most recent call last):
  File "./Lib/compileall.py", line 223, in 
    exit_status = int(not main())
  File "./Lib/compileall.py", line 205, in main
    if os.path.isdir(dest):
  File "/Users/cartman/Sources/py3k/Lib/genericpath.py", line 41, in isdir
    st = os.stat(s)
TypeError: Can't convert 'NoneType' object to str implicitly
make: *** [testall] Error 1

----------
components: Tests
messages: 123865
nosy: cartman
priority: normal
severity: normal
status: open
title: make testall no longer working on Darwin
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 13:11:45 2010
From: report at bugs.python.org (Yevgeniy)
Date: Mon, 13 Dec 2010 12:11:45 +0000
Subject: [New-bugs-announce] [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>


New submission from Yevgeniy :

When i trying to connect to courier-imap server i got error:
"server not IMAP4 compliant"
But as i see in the debug information and server responses there is error in the source code of library.
imaplib.py version: 2.58 
courier-imap server version: 0.91-ubuntu1
os version: ubunto 10.04(lucid)
You can see debug information and telnet session in attached file.
Best regards, Yevgeniy.

----------
components: Library (Lib)
files: debug.txt
messages: 123871
nosy: silversky
priority: normal
severity: normal
status: open
title: imap lib server compabilities
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file20028/debug.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 13:47:12 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Dec 2010 12:47:12 +0000
Subject: [New-bugs-announce] [issue10693] error in documentation
	of	distutils.archive_util.make_zipfile
In-Reply-To: <1292244432.84.0.973297010856.issue10693@psf.upfronthosting.co.za>
Message-ID: <1292244432.84.0.973297010856.issue10693@psf.upfronthosting.co.za>


New submission from Eli Bendersky :

The documentation of:

distutils.archive_util.make_zipfile(base_name, base_dir[, verbose=0, dry_run=0]) 

Says:

  Create a zip file from all files in and under base_dir. The output zip file will be named base_dir + .zip. 

This isn't correct, as the name of the output file is "base_name + .zip"

The error exists both in the docstring of make_zipfile in distutils/archive_util.py and in the ReST documentation of the function

----------
assignee: tarek
components: Distutils, Documentation
keywords: easy
messages: 123872
nosy: docs at python, eli.bendersky, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: error in documentation of distutils.archive_util.make_zipfile
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 19:57:51 2010
From: report at bugs.python.org (Kevin Hendricks)
Date: Mon, 13 Dec 2010 18:57:51 +0000
Subject: [New-bugs-announce] [issue10694] zipfile.py end of central
	directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>


New submission from Kevin Hendricks :

The current version of zipfile.py is not robust to slight errors at the end of zip archives.  Many file servers **improperly** append a new line to the end of files that do not have a new line when they are uploaded from a browser.  This bug ends up adding 0x0d 0xa to the end of the zip archive.  This in turn makes zipfile.py eventually throw a "Not a zip file" exception when no other zip tools seem to have trouble with them.  Even unzip -t passes these "problem" zip archives with flying colours.

I hate to have to extract and create my own zipfile.py script just to be robust to zip archives that are commonly found on the net and that are handled more robustly by other software.

So please consider changing this code from _EndRecData below to simply ignore any trailing data after the proper stringEndArchive and structEndArchive are found instead of looking for the comment and verifying if the comment is properly formatted and throwing an exception if not correct.  Ignoring the "comment" seems to be more robust in this case as everything needed to unpack the zip archive has been found.


    # Either this is not a ZIP file, or it is a ZIP file with an archive
    # comment.  Search the end of the file for the "end of central directory"
    # record signature. The comment is the last item in the ZIP file and may be
    # up to 64K long.  It is assumed that the "end of central directory" magic
    # number does not appear in the comment.
    maxCommentStart = max(filesize - (1 << 16) - sizeEndCentDir, 0)
    fpin.seek(maxCommentStart, 0)
    data = fpin.read()
    start = data.rfind(stringEndArchive)
    if start >= 0:
        # found the magic number; attempt to unpack and interpret
        recData = data[start:start+sizeEndCentDir]
        endrec = list(struct.unpack(structEndArchive, recData))
        comment = data[start+sizeEndCentDir:]
        # check that comment length is correct
        if endrec[_ECD_COMMENT_SIZE] == len(comment):
            # Append the archive comment and start offset
            endrec.append(comment)
            endrec.append(maxCommentStart + start)
            if endrec[_ECD_OFFSET] == 0xffffffff:
                # There is apparently a "Zip64 end of central directory"
                # structure present, so go look for it
                return _EndRecData64(fpin, start - filesize, endrec)
            return endrec


This will in turn make the Python implementation of zipfile.py more robust to data improperly appended when some zip archives are uploaded or downloaded (similar to how other zip tools handle this issue).

Thank you for your time and consideration.

----------
messages: 123891
nosy: KevinH
priority: normal
severity: normal
status: open
title: zipfile.py end of central directory detection not robust
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 20:27:09 2010
From: report at bugs.python.org (Christian S. Perone)
Date: Mon, 13 Dec 2010 19:27:09 +0000
Subject: [New-bugs-announce] [issue10695] telnetlib.Telnet port number
	int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>


New submission from Christian S. Perone :

When you use telnetlib with a "str" parameter as Port Number:
tel = telnetlib.Telnet("10.0.2.9", "8123")
tel.read_until("login: ")

It works fine, except if you set the debuglevel:
tel.set_debuglevel(30)

Then the follow exception is thrown:

Traceback (most recent call last):
  File "", line 1, in 
  File "c:\python26\lib\telnetlib.py", line 306, in read_until
    self.fill_rawq()
  File "c:\python26\lib\telnetlib.py", line 517, in fill_rawq
    self.msg("recv %r", buf)
  File "c:\python26\lib\telnetlib.py", line 239, in msg
    print 'Telnet(%s,%d):' % (self.host, self.port),
TypeError: %d format: a number is required, not str

I think that the string "Telnet(%s,%d):" on the telnetlib.py should be "Telnet(%s,%s):", since it works fine with a str as Port Number.

----------
components: Library (Lib)
messages: 123894
nosy: Christian.S..Perone
priority: normal
severity: normal
status: open
title: telnetlib.Telnet port number int/str inconsistency
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 21:05:48 2010
From: report at bugs.python.org (JTMoon79)
Date: Mon, 13 Dec 2010 20:05:48 +0000
Subject: [New-bugs-announce] [issue10696] port not split in function
	urllib.parse.urlsplit
In-Reply-To: <1292270748.56.0.94944870348.issue10696@psf.upfronthosting.co.za>
Message-ID: <1292270748.56.0.94944870348.issue10696@psf.upfronthosting.co.za>


New submission from JTMoon79 :

urlsplit function from urllib.parse.urlsplit does not return the port field.
Repro steps

>>> import urllib
>>> import urllib.parse
>>> urllib.parse.urlsplit(r'http://foo.bar.com:80/blarg?a=1&b=2')
RETURNS:
SplitResult(scheme='http', netloc='foo.bar.com:80', path='/blarg', query='a=1&b=2', fragment='')
EXPECTED:
SplitResult(scheme='http', netloc='foo.bar.com', path='/blarg', port='80', query='a=1&b=2', fragment='')

----------
components: Library (Lib)
messages: 123897
nosy: JTMoon79
priority: normal
severity: normal
status: open
title: port not split in function urllib.parse.urlsplit
type: behavior
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 21:17:20 2010
From: report at bugs.python.org (JTMoon79)
Date: Mon, 13 Dec 2010 20:17:20 +0000
Subject: [New-bugs-announce] [issue10697] port not split in function
	urllib.parse.urlparse
In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za>
Message-ID: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za>


New submission from JTMoon79 :

Copy of issue 10696
This issue is exactly the same as issue 10696 except it affects a different function, urllib.parse.urlparse (instead of urllib.parse.urlsplit).

urlparse function from urllib.parse.urlparse does not return the port field.
REPRO STEPS:
>>> import urllib
>>> import urllib.parse
>>> urllib.parse.urlparse(r'http://foo.bar.com:80/blarg?a=1&b=2')
RETURNS:
ParseResult(scheme='http', netloc='foo.bar.com:80', path='/blarg', params='', query='a=1&b=2', fragment='')
EXPECTED: 
ParseResult(scheme='http', netloc='foo.bar.com', path='/blarg', port='80', params='', query='a=1&b=2', fragment='')
END REPRO

The documentation at http://docs.python.org/py3k/library/urllib.parse.html#urllib.parse.urlsplit shows this as expected.  What is the purpose of a possible port parameter if that port parameter is not set?

According to RFC 1808 the syntatic components are 
:///;?#
However, according to referenced RFC 1738 (referenced by RFC 1808)
http://tools.ietf.org/html/rfc1738#section-3.1
the  can be further separated to  and .

I guess a bigger more general complaint about this is, why not make urlparse more useful by separating  and ?
I imagine this is a common need of users.  I like standards.  And doing a little extra to work with standards make those standards even more useful.

----------
components: Library (Lib)
messages: 123898
nosy: JTMoon79
priority: normal
severity: normal
status: open
title: port not split in function urllib.parse.urlparse
type: behavior
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 22:38:56 2010
From: report at bugs.python.org (Andrew Dalke)
Date: Mon, 13 Dec 2010 21:38:56 +0000
Subject: [New-bugs-announce] [issue10698] doctest load_tests() typo
In-Reply-To: <1292276336.42.0.386145725492.issue10698@psf.upfronthosting.co.za>
Message-ID: <1292276336.42.0.386145725492.issue10698@psf.upfronthosting.co.za>


New submission from Andrew Dalke :

doctest.html Section 24.2.5 "Unittest API" says:


def load_tests(loader, tests, ignore):
    tests.addTests(doctest.DocTestSuite(my_module_with_doctests))
    return test

That last line should be "return tests"

----------
assignee: docs at python
components: Documentation
messages: 123904
nosy: dalke, docs at python
priority: normal
severity: normal
status: open
title: doctest load_tests() typo
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 00:07:12 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Mon, 13 Dec 2010 23:07:12 +0000
Subject: [New-bugs-announce] [issue10699] [patch] fix incorrect help doc
	with time.tzset
In-Reply-To: <1292281632.56.0.898289640731.issue10699@psf.upfronthosting.co.za>
Message-ID: <1292281632.56.0.898289640731.issue10699@psf.upfronthosting.co.za>


New submission from Garrett Cooper :

The following patch fixes the help docstring as time.tzset when called doesn't require any arguments (as noted in the source and also in the library documentation).

The patch produced was against trunk, but this appears to be an issue on release-maint26 and release-maint27 (and the patch applies cleanly) as the text is the same.

----------
assignee: docs at python
components: Documentation
files: fix-timemodule-helpdoc.patch
keywords: patch
messages: 123908
nosy: docs at python, yaneurabeya
priority: normal
severity: normal
status: open
title: [patch] fix incorrect help doc with time.tzset
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20033/fix-timemodule-helpdoc.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 06:04:56 2010
From: report at bugs.python.org (HwidongNa)
Date: Tue, 14 Dec 2010 05:04:56 +0000
Subject: [New-bugs-announce] [issue10700] python pickle.dumps AssertionError
In-Reply-To: <1292303096.18.0.227107282365.issue10700@psf.upfronthosting.co.za>
Message-ID: <1292303096.18.0.227107282365.issue10700@psf.upfronthosting.co.za>


New submission from HwidongNa :

I'm trying to pickle a class instance containing two lists of another instances. The instances in the two lists have attributes that refer instances of each other. Here are the classes.

import pickle
from copy import copy

class Graph:
    def __init__(self):
        self.vertices = {}
        self.edges = set()
    def __repr__(self):
        return "\n".join(map(str, sorted(self.vertices, key=lambda v:v.id)))

class Edge:
    def __init__(self, vfrom, vto):
        self.vfrom = vfrom
        self.vto = vto
    def __hash__(self):
        return hash((self.vto, self.vfrom))
    def __repr__(self):
        return str(self.vto.id)
    def __getstate__(self):
        vfrom = copy(self.vfrom)
        vfrom.del_outgoing(self)
        vto = copy(self.vto)
        vto.del_incoming(self)
        self.__dict__.update({"vfrom":vfrom, "vto":vto, })
        return self.__dict__
    def __setstate__(self, state):
        self.__dict__.update(state)
        self.__dict__["vfrom"].add_outgoing(self)
        self.__dict__["vto"].add_incoming(self)

class Vertex:
    def __init__(self, id):
        self.id = id
        self.incoming = set()
        self.outgoing = set()
    def __repr__(self):
        return "Vertex %d -> %s"%(self.id, ", ".join(map(str, self.outgoing)))
    def __hash__(self):
        return hash(self.id)
    def add_incoming(self, edge):
        if not edge in self.incoming:
            self.incoming.add(edge)
    def add_outgoing(self, edge):
        if not edge in self.outgoing:
            self.outgoing.add(edge)
    def del_incoming(self, edge):
        self.incoming.discard(edge)
    def del_outgoing(self, edge):
        self.outgoing.discard(edge)

I got an AssertionError when I pickled a simple graph as follows.

>>> v0 = Vertex(0)
>>> v1 = Vertex(1)
>>> e0to1 = Edge(v0, v1)
>>> v0.add_outgoing(e0to1)
>>> v1.add_incoming(e0to1)
>>> g = Graph()
>>> g.vertices[v0] = v0
>>> g.vertices[v1] = v1
>>> g.edges.add(e0to1)
>>> g.edges.add(e0to1)
>>> v2 = Vertex(2)
>>> e0to2 = Edge(v0, v2)
>>> v0.add_outgoing(e0to2)
>>> v2.add_incoming(e0to2)
>>> g.vertices[v2] = v2
>>> g.edges.add(e0to2)
>>> 
>>> print g
Vertex 0 -> 2, 1
Vertex 1 -> 
Vertex 2 -> 
>>> p = pickle.dumps(g)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.6/pickle.py", line 1366, in dumps
    Pickler(file, protocol).dump(obj)
  File "/usr/lib/python2.6/pickle.py", line 224, in dump
    self.save(obj)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 725, in save_inst
    save(stuff)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/lib/python2.6/pickle.py", line 663, in _batch_setitems
    save(v)
  File "/usr/lib/python2.6/pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/lib/python2.6/pickle.py", line 401, in save_reduce
    save(args)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 562, in save_tuple
    save(element)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 600, in save_list
    self._batch_appends(iter(obj))
  File "/usr/lib/python2.6/pickle.py", line 615, in _batch_appends
    save(x)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 725, in save_inst
    save(stuff)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/lib/python2.6/pickle.py", line 663, in _batch_setitems
    save(v)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 725, in save_inst
    save(stuff)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/lib/python2.6/pickle.py", line 663, in _batch_setitems
    save(v)
  File "/usr/lib/python2.6/pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/lib/python2.6/pickle.py", line 405, in save_reduce
    self.memoize(obj)
  File "/usr/lib/python2.6/pickle.py", line 244, in memoize
    assert id(obj) not in self.memo
AssertionError

I worked when the v2 is removed. 

>>> v0 = Vertex(0)
>>> v1 = Vertex(1)
>>> e0to1 = Edge(v0, v1)
>>> v0.outgoing.add(e0to1)
>>> v1.incoming.add(e0to1)
>>> g = Graph()
>>> g.vertices[v0] = v0
>>> g.vertices[v1] = v1
>>> g.edges.add(e0to1)
>>> g.edges.add(e0to1)
>>> import cPickle as pickle
>>> p = pickle.dumps(g)
>>> print pickle.loads(p)
Vertex 0 -> 1
Vertex 1 -> 

Do you have any idea?

----------
components: Library (Lib)
messages: 123925
nosy: Leo.Na
priority: normal
severity: normal
status: open
title: python pickle.dumps AssertionError
type: crash
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 15:53:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 14:53:56 +0000
Subject: [New-bugs-announce] [issue10701] Error pickling a dict
In-Reply-To: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za>
Message-ID: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky :

The work-around that I proposed for issue10700 does not work with Python 2.x:

$ python2.7 dict-graph.py
Vertex 0 -> 2, 1
Vertex 1 -> 
Vertex 2 -> 
Traceback (most recent call last):
  File "dict-graph.py", line 74, in 
    p = pickle.dumps(g)
    ...
File ".../Lib/pickle.py", line 661, in _batch_setitems
    for k, v in items:
RuntimeError: dictionary changed size during iteration

----------
files: dict-graph.py
messages: 123948
nosy: Leo.Na, belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Error pickling a dict
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20038/dict-graph.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 18:26:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 17:26:04 +0000
Subject: [New-bugs-announce] [issue10702] bytes and bytearray methods are
	not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky :

Library reference manual has a section dedicated to string methods [1], but similar methods of bytes and bytearray types are not documented.  Adding two new sections would probably be too repetitious, so I wonder if it would make sense to add notes about byte/bytearray methods to the matching string methods' entries.  See also issue10587.

[1] http://docs.python.org/dev/py3k/library/stdtypes.html#string-methods

----------
assignee: docs at python
components: Documentation
messages: 123960
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: bytes and bytearray methods are not documented
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 18:41:57 2010
From: report at bugs.python.org (Steve Moran)
Date: Tue, 14 Dec 2010 17:41:57 +0000
Subject: [New-bugs-announce] [issue10703] Regex 0.1.20101210
In-Reply-To: <1292348517.73.0.298960721159.issue10703@psf.upfronthosting.co.za>
Message-ID: <1292348517.73.0.298960721159.issue10703@psf.upfronthosting.co.za>


New submission from Steve Moran :

The regex package doesn't seem to correctly implement the single grapheme match "\X" (\P{M}\p{M}*) for pre-Python 3. I'm using the string "?i-te" (i, U+0301, i, -, t, e -- where U+0301 is Unicode COMBINING ACUTE ACCENT), reading it in from a file to bypass Unicode c&p issues in the older IDLEs). 


stiv at x$ python3.1
Python 3.1.2 (r312:79147, May 19 2010, 11:50:28) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import regex
>>> file = open("test_data", "rt", encoding="utf-8")
>>> s = file.readline()
>>> print (s)
?i-te
>>> print (g.findall(s))
['?', 'i', '-', 't', 'e']

* Correct in 3.1 - i+U+0301 considered one grapheme.

stiv at x$ python2.7
Python 2.7 (r27:82500, Oct  4 2010, 14:49:53) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs                                
>>> import regex
>>> file = codecs.open("test_data", "r", "utf-8")
>>> g = regex.compile("\X")
>>> s = file.readline()
>>> s
u'i\u0301i-te'
>>> print s.encode("utf-8")
?i-te
>>> print g.findall(s)
[u'i', u'\u0301', u'i', u'-', u't', u'e']

*Not correct -- accent is treated as a separate character.

Thanks.

----------
components: Regular Expressions
messages: 123961
nosy: stiv
priority: normal
severity: normal
status: open
title: Regex 0.1.20101210
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 19:08:57 2010
From: report at bugs.python.org (Steve Moran)
Date: Tue, 14 Dec 2010 18:08:57 +0000
Subject: [New-bugs-announce] [issue10704] Regex 0.1.20101210 Python 3.1
	install problem Mac OS X	10.6.5
In-Reply-To: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>
Message-ID: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>


New submission from Steve Moran :

Package doesn't want to install on Mac OS X 10.6.5 with Python 3.1 using instructions "python3.1 setup.py install" (or "sudo python3.1 setup.py install").

Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.4u.sdk

Extended error log attached.

NB: I realize this package is in dev and it's got less than 50 current downloads. Thought I'd post anyway. I appreciate any input. Xcode is installed v 3.2.2. 64-bit.

----------
components: Installation
files: regex-0.1.20101210-python31-install-error
messages: 123964
nosy: stiv
priority: normal
severity: normal
status: open
title: Regex 0.1.20101210 Python 3.1 install problem Mac OS X 10.6.5
versions: Python 3.1
Added file: http://bugs.python.org/file20042/regex-0.1.20101210-python31-install-error

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 20:22:43 2010
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Tue, 14 Dec 2010 19:22:43 +0000
Subject: [New-bugs-announce] [issue10705] HTTPConnection.set_debuglevel has
	no information about	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>


New submission from J_Tom_Moon_79 :

Function HTTPConnection.set_debuglevel(level)
There is no range of acceptable debug levels.
What should be the difference in set_debuglevel(1) and set_debuglevel(1000)?
If the documentation lists the levels this would save users from needing to do tedious trial-error experimentation.

From
http://docs.python.org/py3k/library/http.client.html#http.client.HTTPConnection.set_debuglevel

----------
assignee: docs at python
components: Documentation
messages: 123974
nosy: JTMoon79, docs at python
priority: normal
severity: normal
status: open
title: HTTPConnection.set_debuglevel has no information about level range
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 22:57:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Dec 2010 21:57:51 +0000
Subject: [New-bugs-announce] [issue10706] kill runtests.sh
In-Reply-To: <1292363871.99.0.211094833748.issue10706@psf.upfronthosting.co.za>
Message-ID: <1292363871.99.0.211094833748.issue10706@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

There are two official ways to run tests:
- "make test" for beginners
- "./python -m test [etc.]" for experts

runtests.sh serves no useful purpose and had completely outdated reporting, making it potentially confusing for newcomers who would try to test it. I therefore propose to kill it.

----------
components: Tests
messages: 123979
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: kill runtests.sh
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 23:04:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Dec 2010 22:04:04 +0000
Subject: [New-bugs-announce] [issue10707] compileall is broken
In-Reply-To: <1292364244.37.0.894892312979.issue10707@psf.upfronthosting.co.za>
Message-ID: <1292364244.37.0.894892312979.issue10707@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

$ ./python -m compileall
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/antoine/py3k/__svn__/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/antoine/py3k/__svn__/Lib/compileall.py", line 223, in 
    exit_status = int(not main())
  File "/home/antoine/py3k/__svn__/Lib/compileall.py", line 205, in main
    if os.path.isdir(dest):
  File "/home/antoine/py3k/__svn__/Lib/genericpath.py", line 41, in isdir
    st = os.stat(s)
TypeError: Can't convert 'NoneType' object to str implicitly

----------
components: Library (Lib)
messages: 123980
nosy: benjamin.peterson, ncoghlan, pitrou
priority: high
severity: normal
status: open
title: compileall is broken
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 16:37:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 15:37:33 +0000
Subject: [New-bugs-announce] [issue10708] Misc/porting should be folded in
	to the development FAQ
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

Title says it all.

----------
assignee: brett.cannon
components: Documentation
messages: 124023
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Misc/porting should be folded in to the development FAQ
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 16:50:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 15:50:56 +0000
Subject: [New-bugs-announce] [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

S?bastien, would you like to provide an updated version of that file? The current contents look hopelessly outdated.

----------
assignee: docs at python
components: Documentation
messages: 124024
nosy: docs at python, pitrou, sable
priority: normal
severity: normal
stage: needs patch
status: open
title: Misc/AIX-NOTES needs updating
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 16:53:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 15:53:37 +0000
Subject: [New-bugs-announce] [issue10710] Is Misc/setuid-prog.c still needed?
In-Reply-To: <1292428417.91.0.430999104384.issue10710@psf.upfronthosting.co.za>
Message-ID: <1292428417.91.0.430999104384.issue10710@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

I guess it was created for ease of hosting CGI scripts written in Python, but is it still useful (or even functional) nowadays? Last updated goes back to 1998.

----------
components: Demos and Tools
messages: 124025
nosy: brett.cannon, gvanrossum, jhylton, pitrou, r.david.murray
priority: low
severity: normal
status: open
title: Is Misc/setuid-prog.c still needed?
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 18:04:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 17:04:58 +0000
Subject: [New-bugs-announce] [issue10711] Rip off HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

Both http.client and http.server claim to support HTTP 0.9. The HTTP 1.0 RFC was filed in 1996, and 1.1 is most commonly used nowadays. We should probably rip off 0.9 support.

----------
components: Library (Lib)
messages: 124032
nosy: jhylton, orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Rip off HTTP 0.9 support
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 20:36:36 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 19:36:36 +0000
Subject: [New-bugs-announce] [issue10712] 2to3 fixer for deprecated unittest
	method names
In-Reply-To: <1292441796.9.0.018359428873.issue10712@psf.upfronthosting.co.za>
Message-ID: <1292441796.9.0.018359428873.issue10712@psf.upfronthosting.co.za>


New submission from Ezio Melotti :

The attached patch against 2.7 adds a new fixer to 2to3 that replaces deprecated unittest method names with the correct ones.
There are a few issues:
1) only the "safe" renamings are included; the assert[SameElements|ItemsEqual|CountEqual] and the  assert*Regexp*->assert*Regex* changes are missing;
2) unless 2to3 provides a way to specify a target version (e.g. 3.2 rather than just 3.x), the missing renamings can't be included;
3) the patch is against 2.7 but I'm not sure in what versions could/should be included, or if the fixer should (also|only) go on PyPI;
4) this fixer is useful from 3.1 to 3.2 too, is there a way to use it with 3.x versions only?
5) doc is still missing;

----------
files: issue10712.diff
keywords: needs review, patch
messages: 124054
nosy: benjamin.peterson, ezio.melotti, georg.brandl, michael.foord
priority: normal
severity: normal
stage: patch review
status: open
title: 2to3 fixer for deprecated unittest method names
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20062/issue10712.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 02:05:35 2010
From: report at bugs.python.org (Ralph Corderoy)
Date: Thu, 16 Dec 2010 01:05:35 +0000
Subject: [New-bugs-announce] [issue10713] re module doesn't describe string
	boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>


New submission from Ralph Corderoy :

The re module defines \b in a regexp to need \w one side and \W the other.  What about when the end of the string or line is involved?  perlre(1) says that's treated as a \W.  Python should precisely document that case too.

----------
assignee: docs at python
components: Documentation
messages: 124097
nosy: docs at python, ralph.corderoy
priority: normal
severity: normal
status: open
title: re module doesn't describe string boundaries for \b

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 05:48:11 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 16 Dec 2010 04:48:11 +0000
Subject: [New-bugs-announce] [issue10714] httpserver request length
In-Reply-To: <1292474891.55.0.351573149453.issue10714@psf.upfronthosting.co.za>
Message-ID: <1292474891.55.0.351573149453.issue10714@psf.upfronthosting.co.za>


New submission from Ross Lagerwall :

BaseHTTPRequestHandler in http.server does not limit the length of the request line so a malicious client can cause the server to run out of memory with a malicious request.

This patch limits the length to 64K (like Apache) and sends Error 414 if it exceeds this.

----------
components: Library (Lib)
files: httpserver_py3k.patch
keywords: patch
messages: 124106
nosy: rosslagerwall
priority: normal
severity: normal
status: open
title: httpserver request length
type: security
versions: Python 3.2
Added file: http://bugs.python.org/file20074/httpserver_py3k.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 07:27:38 2010
From: report at bugs.python.org (Phillip Feldman)
Date: Thu, 16 Dec 2010 06:27:38 +0000
Subject: [New-bugs-announce] [issue10715] uninformative error message
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>


New submission from Phillip Feldman :

The error message "OSError: [Errno 2] No such file or directory" would be far more helpful if it specified the name of the file or directory that cannot be found.

----------
messages: 124108
nosy: Phillip.M.Feldman
priority: normal
severity: normal
status: open
title: uninformative error message
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 10:25:39 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 09:25:39 +0000
Subject: [New-bugs-announce] [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>


New submission from Raymond Hettinger :

This is a straight-forward project.

Pydoc currently generated 1990's style html which mixes content and presentation, making it very difficult for users to customize the appearance of the output.

It is full of html like:





 

 
%s		%s

    ''' % (bgcol, fgcol, title, fgcol, extras or ' ')

    def section(self, title, fgcol, bgcol, contents, width=6,
                prelude='', marginalia=None, gap=' '):
        """Format a section with a heading."""
        if marginalia is None:
            marginalia = '' + ' ' * width + ''
        result = '''


    ''' % (bgcol, fgcol, title)
        if prelude:
            result = result + '''
''' % (bgcol, marginalia, prelude, gap)

Please convert it to simple, validated HTML with the formatting moved to a simple, validated default style sheet.  Liberally apply div/span elements with class/id attributes as necessary.

----------
components: Library (Lib)
keywords: gsoc
messages: 124119
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Modernize pydoc to use CSS
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 15:08:59 2010
From: report at bugs.python.org (Dimitrios Pritsos)
Date: Thu, 16 Dec 2010 14:08:59 +0000
Subject: [New-bugs-announce] [issue10717] Multiprocessing module Pickling
	unPickling issues
In-Reply-To: <1292508539.32.0.622447898726.issue10717@psf.upfronthosting.co.za>
Message-ID: <1292508539.32.0.622447898726.issue10717@psf.upfronthosting.co.za>


New submission from Dimitrios Pritsos :

My name is Dimitrios and I am newbie in python. I am working on a Project (part of my PhD) that is called Synergeticprocessing module. Initially is imitating the multiprocessing built in module but the processes are distributed on a LAN and not Locally. The main issue I have is with Pickle module. And I think I found some kind of BUG in the built in multiprocessing module.

(Synergeticprocessing module is located at GitHub: https://github.com/dpritsos/synergeticprocessing)

Starting with the "BUG". In case someone uses the multiprocessing.Pool of processes he/she has to face the problem of types.MehtodType Impossible pickling. That is you cannot dispatch an class instance method to the to the Process Pool. However, digging in to the Source Code of the module there are few lines that resolve this issue however are not activated or they are faultily activated so they do not work. This is the 'BUG'

@ ....../multiprocessing/forking.py


.
.
.

#
# Try making some callable types picklable
#

from pickle import Pickler
class ForkingPickler(Pickler):
    dispatch = Pickler.dispatch.copy()

    @classmethod
    def register(cls, type, reduce):
        def dispatcher(self, obj):
            rv = reduce(obj)
            self.save_reduce(obj=obj, *rv)
        cls.dispatch[type] = dispatcher

def _reduce_method(m):
    if m.im_self is None:
        return getattr, (m.im_class, m.im_func.func_name)
    else:
        return getattr, (m.im_self, m.im_func.func_name)
ForkingPickler.register(type(ForkingPickler.save), _reduce_method)

def _reduce_method_descriptor(m):
    return getattr, (m.__objclass__, m.__name__)
ForkingPickler.register(type(list.append), _reduce_method_descriptor)
ForkingPickler.register(type(int.__add__), _reduce_method_descriptor)

#def _reduce_builtin_function_or_method(m):
#    return getattr, (m.__self__, m.__name__)
#ForkingPickler.register(type(list().append), _reduce_builtin_function_or_method)
#ForkingPickler.register(type(int().__add__), _reduce_builtin_function_or_method)
.
.
.

The RED lines are not doing the job, for some reason they are not managing to register the GREEN function as a global reduce/pickling function even if you call the registration function into you __main__ script.

The solution I found is just to do this

import copy_reg
import types

def _reduce_method(m):
    if m.im_self is None:
        return getattr, (m.im_class, m.im_func.func_name)
    else:
        return getattr, (m.im_self, m.im_func.func_name)

copy_reg.pickle(types.MethodType, _reduce_method)
.
.
.

Doing that everything works FINE. But ONLY for local methods i.e. the ones that their class is defined on the __main__ script or other import-ed.

In case you want to send something remotely (in an other machine) or to an other __main__ script running separately then you get a message like this:

'module' object has no attribute ''

The only way to resolve this is firstly to import a script that has  defined there and everything works fine.

SO the problems it seems to be that the m.im_class  (look code above) has some attribute __module__ defined as __module__ = '__main__' or something like that. And this is the reason why remote script cannot execute the function. I mean that the _reduce_method() above DOES is pickling the whole CLASS object so there is no reason not to be executed at the remote script. Besides it does as mentioned above in you just import this the user defined class form an other script.


I have already spent about 12 weeks working on building my synergeticPool and resolve the issue of Pickling and only 2 days needed for the code of the Pool and the rest of the time was spent for the Pickling issues, and study all the Class related mechanics of python. That was the reason I ve started digging the multipocessessing module and found this say 'BUG', and finally sent this email.

Best Regards,


Dimitrios

----------
components: None
messages: 124133
nosy: dimitrios
priority: normal
severity: normal
status: open
title: Multiprocessing module Pickling unPickling issues
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 15:17:39 2010
From: report at bugs.python.org (Jill)
Date: Thu, 16 Dec 2010 14:17:39 +0000
Subject: [New-bugs-announce] [issue10718] brand new to programming. crashes
	at run
In-Reply-To: <1292509059.79.0.914872833558.issue10718@psf.upfronthosting.co.za>
Message-ID: <1292509059.79.0.914872833558.issue10718@psf.upfronthosting.co.za>


New submission from Jill :

Hello and thanks in advance.  I installed Python 2.7 from the python site onto my MAC with OS X 10.6.4.  After entering my code (which makes me feel humbled and brilliant all at the same time) I am prompted to save, which I do and then when I select run the whole thing crashes.  Error message below.


Process:         Python [14162]
Path:            /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
Identifier:      org.python.IDLE
Version:         2.7.1 (2.7.1)
Code Type:       X86 (Native)
Parent Process:  launchd [149]

Date/Time:       2010-12-16 09:09:15.644 -0500
OS Version:      Mac OS X 10.6.4 (10F569)
Report Version:  6

Interval Since Last Report:          8227 sec
Crashes Since Last Report:           2
Per-App Interval Since Last Report:  1974 sec
Per-App Crashes Since Last Report:   2
Anonymous UUID:                      48621F8F-C51F-400A-8AA8-76DDA70F8973

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000030747369
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
objc_msgSend() selector name: release


Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	0x9798eedb objc_msgSend + 27
1   com.apple.CoreFoundation      	0x96ec191d _CFAutoreleasePoolPop + 253
2   com.apple.Foundation          	0x9309cdb6 NSPopAutoreleasePool + 76
3   com.apple.Foundation          	0x9309ccde -[NSAutoreleasePool drain] + 130
4   Tk                            	0x0072cf18 XQueryPointer + 2393
5   Tk                            	0x0072d219 Tk_MacOSXSetupTkNotifier + 634
6   Tcl                           	0x005f4aa8 Tcl_DoOneEvent + 310
7   _tkinter.so                   	0x003d75b2 Tkapp_MainLoop + 450
8   org.python.python             	0x000c18e0 PyEval_EvalFrameEx + 26576
9   org.python.python             	0x000c3c7c PyEval_EvalCodeEx + 1996
10  org.python.python             	0x000c15ce PyEval_EvalFrameEx + 25790
11  org.python.python             	0x000c2ba3 PyEval_EvalFrameEx + 31379
12  org.python.python             	0x000c3c7c PyEval_EvalCodeEx + 1996
13  org.python.python             	0x000c3dc7 PyEval_EvalCode + 87
14  org.python.python             	0x000e82fc PyRun_FileExFlags + 172
15  org.python.python             	0x000e8664 PyRun_SimpleFileExFlags + 596
16  org.python.python             	0x00100255 Py_Main + 3365
17  Python                        	0x00001f65 start + 53

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib             	0x961f4942 kevent + 10
1   libSystem.B.dylib             	0x961f505c _dispatch_mgr_invoke + 215
2   libSystem.B.dylib             	0x961f4519 _dispatch_queue_invoke + 163
3   libSystem.B.dylib             	0x961f42be _dispatch_worker_thread2 + 240
4   libSystem.B.dylib             	0x961f3d41 _pthread_wqthread + 390
5   libSystem.B.dylib             	0x961f3b86 start_wqthread + 30

Thread 2:
0   libSystem.B.dylib             	0x961ed086 select$DARWIN_EXTSN + 10
1   Tcl                           	0x0062a72b Tcl_InitNotifier + 1643
2   libSystem.B.dylib             	0x961fb81d _pthread_start + 345
3   libSystem.B.dylib             	0x961fb6a2 thread_start + 34

Thread 3:
0   libSystem.B.dylib             	0x961f39d2 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x961f3f68 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x961f3b86 start_wqthread + 30

Thread 4:
0   libSystem.B.dylib             	0x961f39d2 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x961f3f68 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x961f3b86 start_wqthread + 30

Thread 5:
0   libSystem.B.dylib             	0x961ce0fa mach_msg_trap + 10
1   libSystem.B.dylib             	0x961ce867 mach_msg + 68
2   com.apple.CoreFoundation      	0x96ec4faf __CFRunLoopRun + 2079
3   com.apple.CoreFoundation      	0x96ec4094 CFRunLoopRunSpecific + 452
4   com.apple.CoreFoundation      	0x96ec9fd4 CFRunLoopRun + 84
5   com.apple.DesktopServices     	0x91b61e13 TSystemNotificationTask::SystemNotificationTaskProc(void*) + 643
6   ...ple.CoreServices.CarbonCore	0x90dc1dee PrivateMPEntryPoint + 68
7   libSystem.B.dylib             	0x961fb81d _pthread_start + 345
8   libSystem.B.dylib             	0x961fb6a2 thread_start + 34

Thread 6:
0   libSystem.B.dylib             	0x961f39d2 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x961f3f68 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x961f3b86 start_wqthread + 30

Thread 7:
0   libSystem.B.dylib             	0x961ed086 select$DARWIN_EXTSN + 10
1   com.apple.CoreFoundation      	0x96f0480d __CFSocketManager + 1085
2   libSystem.B.dylib             	0x961fb81d _pthread_start + 345
3   libSystem.B.dylib             	0x961fb6a2 thread_start + 34

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x17febda0  ebx: 0x96e94bdd  ecx: 0x90b48f80  edx: 0x17febaa3
  edi: 0x30747369  esi: 0x17febda0  ebp: 0xbfffeb48  esp: 0xbfffeb24
   ss: 0x0000001f  efl: 0x00010206  eip: 0x9798eedb   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x30747369

Binary Images:
    0x1000 -     0x1ff7 +Python ??? (???) <51596607-6FF7-D67F-3A8C-2E356F7C2E5F> /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
    0x4000 -   0x142fff +org.python.python 2.7.1, (c) 2004-2008 Python Software Foundation. (2.7.1)  /Library/Frameworks/Python.framework/Versions/2.7/Python
  0x3d3000 -   0x3daff7 +_tkinter.so ??? (???) <81678E64-0547-50B0-EBEA-CBFA43314244> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so
  0x3f5000 -   0x3f8ff7 +strop.so ??? (???) <2FD28DAD-4479-79EC-9842-B3C52E3CAF35> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so
  0x3fd000 -   0x3fdff7 +_bisect.so ??? (???)  /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_bisect.so
  0x576000 -   0x648fe7  Tcl 8.5.7 (8.5.7)  /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
  0x661000 -   0x75aff7  Tk 8.5.7 (8.5.7) <9519AEE0-8D83-CBE9-9A99-AE7E2B2CC5FE> /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk
  0x7c8000 -   0x7cfff7 +_socket.so ??? (???) <62293AFA-3EDE-2269-947C-76849F5BB528> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so
  0x7d7000 -   0x7d8ff7 +_functools.so ??? (???) <8B634E9B-420B-892A-25B6-11954BD48DF4> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_functools.so
  0x7db000 -   0x7dfff7 +_ssl.so ??? (???) <2BB61E6D-DC31-8D06-994B-10B4B5BEBF80> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_ssl.so
  0x7e4000 -   0x7e5ff7 +cStringIO.so ??? (???) <08EBE192-3DC1-CADD-57BB-08574C0C04B1> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so
  0x7e9000 -   0x7eaff7 +time.so ??? (???) <2AEA478A-A870-63C5-C3D0-EC48A6ECFEDD> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so
  0x7ef000 -   0x7f2ff7 +_collections.so ??? (???) <454B6F3A-1EF8-A9B6-EB7C-890A6449338A> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_collections.so
  0x7f7000 -   0x7faff7 +operator.so ??? (???) <9705DADE-C96B-11C8-9BFC-6CA8FF8B5604> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/operator.so
 0x1a00000 -  0x1a05ff7 +itertools.so ??? (???) <32A1DC96-2F03-4A3B-8296-43B7AD4DAF09> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/itertools.so
 0x1a0d000 -  0x1a0eff7 +_heapq.so ??? (???)  /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_heapq.so
 0x1a52000 -  0x1a54ff7 +select.so ??? (???) <5563F45B-D2EF-B3A3-3641-33A802EEF45D> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/select.so
 0x1ab9000 -  0x1abaff7 +fcntl.so ??? (???) <3642A8F8-1F0B-C087-CC96-F26F9E800913> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/fcntl.so
 0x1abd000 -  0x1ac0ff7 +_struct.so ??? (???)  /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_struct.so
 0x1ac7000 -  0x1ac9ff7 +binascii.so ??? (???) <6E6BD57A-A222-30BA-25F6-C095448750E6> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so
 0x1b8d000 -  0x1b91ff7 +math.so ??? (???) <4AC469C2-630F-871E-A32C-10AC30D84C55> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/math.so
 0x1b96000 -  0x1b97ff7 +_hashlib.so ??? (???)  /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_hashlib.so
 0x1b9b000 -  0x1b9cff7 +_random.so ??? (???) <7A02D855-38C3-533E-6075-4B82B5CDE359> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_random.so
 0x1b9f000 -  0x1ba0ff7 +_locale.so ??? (???)  /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so
 0x1be3000 -  0x1bf1ff7 +cPickle.so ??? (???) <4D4159DF-3705-8AB2-AE65-8ED1A9BD103E> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cPickle.so
0x8fe00000 - 0x8fe4162b  dyld 132.1 (???)  /usr/lib/dyld
0x90273000 - 0x9027dfe7  com.apple.audio.SoundManager 3.9.3 (3.9.3)  /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x902c8000 - 0x90371ff7  com.apple.CFNetwork 454.9.8 (454.9.8)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x90372000 - 0x90c52ff7  com.apple.AppKit 6.6.6 (1038.29) <6F28C335-6DC2-AE0E-B79A-F256DBD0BB45> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x90c53000 - 0x90c8bff7  libcups.2.dylib 2.8.0 (compatibility 2.0.0) <76C02F5C-98FD-BD64-B5FB-C698FB76EA25> /usr/lib/libcups.2.dylib
0x90d69000 - 0x90d9aff7  libGLImage.dylib ??? (???) <9340012D-595A-6243-9C97-7D30D76D9D9E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x90d9b000 - 0x910bbfeb  com.apple.CoreServices.CarbonCore 861.13 (861.13) <52803668-3669-36BD-57DD-078FBA835081> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x910fc000 - 0x91114ff7  com.apple.CFOpenDirectory 10.6 (10.6) <3F5A2267-3C89-63A1-724D-3C09538BE092> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x91347000 - 0x913a2ff7  com.apple.framework.IOKit 2.0 (???)  /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x913a3000 - 0x913f3ff7  com.apple.framework.familycontrols 2.0.1 (2010)  /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
0x91449000 - 0x9144cffb  com.apple.help 1.3.1 (41) <6A5AD406-9D8E-5BAC-51E1-E09AB9A6D159> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x9144d000 - 0x91458ff7  libCSync.A.dylib 543.50.0 (compatibility 64.0.0) <4FA0CE4A-BDE5-0E3D-37F0-03B41F0C2637> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x91459000 - 0x91496ff7  com.apple.SystemConfiguration 1.10.2 (1.10.2) <398BB007-41FD-1A30-26D8-CB86ED5E467E> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x91497000 - 0x914a1ff7  com.apple.HelpData 2.0.4 (34) <7F27DBA6-3015-7AFB-D256-AF7C41823E6C> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
0x917a7000 - 0x91822fe7  com.apple.audio.CoreAudio 3.2.2 (3.2.2) <51D0E2DC-B15F-AF6C-70D8-026DDAD4E2A5> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x91867000 - 0x918abfe7  com.apple.Metadata 10.6.3 (507.10) <630494FA-3BB3-EDD3-E10B-8DAAF4831E26> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x9199b000 - 0x91a1dffb  SecurityFoundation ??? (???) <3670AE8B-06DA-C447-EB14-79423DB9C474> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x91a1e000 - 0x91a8dff7  libvMisc.dylib 268.0.1 (compatibility 1.0.0)  /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x91a8e000 - 0x91b5ffe3  ColorSyncDeprecated.dylib 4.6.0 (compatibility 1.0.0) <8FDB4C40-D453-DA53-2A66-9A53998AB23C> /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ColorSync.framework/Versions/A/Resources/ColorSyncDeprecated.dylib
0x91b60000 - 0x91c3bfe7  com.apple.DesktopServices 1.5.7 (1.5.7)  /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x91c3c000 - 0x91c6dff3  libTrueTypeScaler.dylib ??? (???) <7601D717-236D-8F4E-91F5-E69BB2920478> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
0x91c6e000 - 0x91c6eff7  com.apple.Cocoa 6.6 (???) <5A785062-1ABB-2A54-BAAC-8FEF95275E05> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0x91c6f000 - 0x91c6fff7  com.apple.Carbon 150 (152) <9252D5F2-462D-2C15-80F3-109644D6F704> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x91c70000 - 0x91cb6ff7  libauto.dylib ??? (???) <7FE46BC8-ED91-12A7-83D0-2102D37CA32D> /usr/lib/libauto.dylib
0x91cb7000 - 0x91ccbfe7  libbsm.0.dylib ??? (???)  /usr/lib/libbsm.0.dylib
0x91ccc000 - 0x91d15fe7  libTIFF.dylib ??? (???) <9CFF48CC-4852-4D06-17AC-3C947C824159> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x91d7c000 - 0x91d9bff7  com.apple.CoreVideo 1.6.1 (45.5) <567D483E-58F7-54F9-3E6F-FAD3B21FAABF> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x91d9c000 - 0x91da5ff7  com.apple.DiskArbitration 2.3 (2.3) <6AA6DDF6-AFC3-BBDB-751A-64AE3580A49E> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x91da6000 - 0x91dadff3  com.apple.print.framework.Print 6.1 (237.1) <726A7F31-8C27-8403-0016-71E022EDC14C> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x91e71000 - 0x91eb2ff7  libRIP.A.dylib 543.50.0 (compatibility 64.0.0) <8BAE1FC1-A478-F151-17C7-2D5DE470AC4F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x91eb3000 - 0x91eb7ff7  libGIF.dylib ??? (???) <3ECD4D2C-40FE-E9A0-A2D2-E36D1C00D3A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x91eb8000 - 0x91ed3ff7  libPng.dylib ??? (???) <36A3D75E-5178-4358-7F02-444E276D61AD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x92eff000 - 0x92f14fff  com.apple.ImageCapture 6.0 (6.0) <04BD774A-2A1A-DA87-0885-10A7E8EB3E3F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x92f6e000 - 0x9307aff7  libGLProgrammability.dylib ??? (???) <1B315838-F477-5416-7504-67EC3433AD4A> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
0x93099000 - 0x93309ffb  com.apple.Foundation 6.6.3 (751.29)  /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x9380c000 - 0x938a4fe7  edu.mit.Kerberos 6.5.10 (6.5.10) <8B83AFF3-C074-E47C-4BD0-4546EED0D1BC> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x938a5000 - 0x93c53fe3  com.apple.RawCamera.bundle 3.3.0 (533) <05A38D21-8556-434C-8BAA-850A6EC99B37> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
0x94783000 - 0x94785ff7  libRadiance.dylib ??? (???)  /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x94787000 - 0x947c9ff7  libvDSP.dylib 268.0.1 (compatibility 1.0.0) <1AE34B00-8A62-1E51-935F-BB3F0E4BE50F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x94831000 - 0x94836ff7  com.apple.OpenDirectory 10.6 (10.6) <27D81AE3-DB56-3872-8CBB-BE88EF5DB3B3> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x94837000 - 0x9483dfff  com.apple.CommonPanels 1.2.4 (91)  /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x94a28000 - 0x94a5efff  libtidy.A.dylib ??? (???)  /usr/lib/libtidy.A.dylib
0x94a5f000 - 0x94adffeb  com.apple.SearchKit 1.3.0 (1.3.0) <7AE32A31-2B8E-E271-C03A-7A0F7BAFC85C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x94c10000 - 0x94c11ff7  com.apple.TrustEvaluationAgent 1.1 (1) <06484720-AB50-6FD9-B5BF-05F5A640C9E5> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x94c12000 - 0x94c76fff  com.apple.htmlrendering 72 (1.1.4) <0D22B190-513B-7FF6-39FC-9D336285DE08> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x94cb8000 - 0x94d68ff3  com.apple.ColorSync 4.6.3 (4.6.3)  /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x94f61000 - 0x94f83fef  com.apple.DirectoryService.Framework 3.6 (621.3) <96E7B3D5-A881-2B02-E97F-6B09461F3C98> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x94f84000 - 0x94f90ff7  libkxld.dylib ??? (???) <322A4B52-8305-3081-6B74-813C3A87A56D> /usr/lib/system/libkxld.dylib
0x950d5000 - 0x950d8ff7  libCoreVMClient.dylib ??? (???)  /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x950d9000 - 0x950f5fe3  com.apple.openscripting 1.3.1 (???) <0E6B81D1-C1BD-1B5F-836F-256E6701B5DE> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x95130000 - 0x951c2fe3  com.apple.print.framework.PrintCore 6.2 (312.5) <71C60B1F-2DD7-3321-0DEC-7947ACFBE977> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x951c3000 - 0x951d1ff7  com.apple.opengl 1.6.9 (1.6.9) <4F06C166-00CF-5ACF-77E3-5A960A5E8AD3> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x951d2000 - 0x952d3fe7  libxml2.2.dylib 10.3.0 (compatibility 10.0.0)  /usr/lib/libxml2.2.dylib
0x9531b000 - 0x9536cff7  com.apple.HIServices 1.8.0 (???) <5FA723CA-B04B-0576-1511-D1FAD5AF0546> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x9536d000 - 0x953b0ff7  libGLU.dylib ??? (???) <2093A1FB-67BD-39E0-CDE5-A97A77BDDBCE> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x956a8000 - 0x956b6fe7  libz.1.dylib 1.2.3 (compatibility 1.0.0) <3CE8AA79-F077-F1B0-A039-9103A4A02E92> /usr/lib/libz.1.dylib
0x956b7000 - 0x95aecff7  libLAPACK.dylib 219.0.0 (compatibility 1.0.0) <4D2F47EF-BD32-1E3C-6A0A-438896ADE2BE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x95c4e000 - 0x95c81ff7  com.apple.AE 496.4 (496.4) <23F0DB1F-2856-0091-80AE-BDEF9A4F1731> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x95c82000 - 0x95ee6fef  com.apple.security 6.1.1 (37594) <3F68A006-6B30-85D5-1A75-8D748F72A6D5> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x961cd000 - 0x96373feb  libSystem.B.dylib 125.2.0 (compatibility 1.0.0) <3441F338-2218-6D36-3F95-3A16FBF6713D> /usr/lib/libSystem.B.dylib
0x96374000 - 0x9652efe3  com.apple.ImageIO.framework 3.0.3 (3.0.3)  /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x96572000 - 0x96596ff7  libJPEG.dylib ??? (???) <5CE96981-6B2A-D15B-4A17-E7BD329095B6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x96597000 - 0x96601fe7  libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <411D87F4-B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib
0x96602000 - 0x9669ffe3  com.apple.LaunchServices 362.1 (362.1)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x966a0000 - 0x966a3ff7  libCGXType.A.dylib 543.50.0 (compatibility 64.0.0) <3B49AED9-0DBA-9D21-F9AC-8784363AD762> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
0x966a4000 - 0x966a4ff7  com.apple.Accelerate.vecLib 3.6 (vecLib 3.6)  /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x9692c000 - 0x96939ff7  com.apple.NetFS 3.2.1 (3.2.1)  /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x96983000 - 0x969c6ff7  com.apple.NavigationServices 3.5.4 (182)  /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x969c7000 - 0x969f1ff7  com.apple.shortcut 1.1 (1.1) <08A1868D-FEF4-8FB3-D814-79385DCBEC7D> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
0x969f2000 - 0x969f2ff7  com.apple.Accelerate 1.6 (Accelerate 1.6) <3891A689-4F38-FACD-38B2-4BF937DE30CF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x969f3000 - 0x96aacfe7  libsqlite3.dylib 9.6.0 (compatibility 9.0.0)  /usr/lib/libsqlite3.dylib
0x96c89000 - 0x96c8dff7  IOSurface ??? (???) <66E11D8E-CF4B-EFD0-37F9-20177C647021> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x96c8e000 - 0x96d36ffb  com.apple.QD 3.35 (???) <70D824C5-C1DF-A0E7-22EC-533B2C10957A> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x96d37000 - 0x96e65fe7  com.apple.CoreData 102.1 (251) <0C2636F3-CCB4-5ED9-1D3E-5AE36BE57071> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x96e88000 - 0x97002fe3  com.apple.CoreFoundation 6.6.3 (550.29) <00373783-3744-F47D-2191-BEEA658F0C3D> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x97003000 - 0x97419ff7  libBLAS.dylib 219.0.0 (compatibility 1.0.0) <9D89FCB3-24C9-8FCF-DB49-27B184AC3222> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x97439000 - 0x9743dff7  libGFXShared.dylib ??? (???) <2D32BDBF-C941-93FD-E233-F03D28DB9E94> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x974bd000 - 0x974f8feb  libFontRegistry.dylib ??? (???)  /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
0x974f9000 - 0x97521ff7  libxslt.1.dylib 3.24.0 (compatibility 3.0.0) <12FBE8CB-CC8E-FE8A-7362-C852625C5AAF> /usr/lib/libxslt.1.dylib
0x97522000 - 0x97543fe7  com.apple.opencl 12.1 (12.1)  /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x97544000 - 0x97544ff7  com.apple.CoreServices 44 (44)  /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x97571000 - 0x976f3fe7  libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <2314BD12-0821-75BB-F3BC-98D324CFD30A> /usr/lib/libicucore.A.dylib
0x976ff000 - 0x97743ff3  com.apple.coreui 2 (114) <1A3C3B7F-3837-6477-3114-47F6BFD56CB2> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x97927000 - 0x97988fe7  com.apple.CoreText 3.1.0 (???) <98011243-2CCE-DED0-5326-98DA0CA8577D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
0x97989000 - 0x97a36fe7  libobjc.A.dylib 227.0.0 (compatibility 1.0.0)  /usr/lib/libobjc.A.dylib
0x97a37000 - 0x97d9fff7  com.apple.QuartzCore 1.6.2 (227.22) <4288F0D2-0C87-F054-C372-8764B44DE024> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x97da0000 - 0x97daaffb  com.apple.speech.recognition.framework 3.11.1 (3.11.1) <90C38107-AEE7-AE55-5C51-28D129B19BCD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x97df2000 - 0x97e12fe7  libresolv.9.dylib 41.0.0 (compatibility 1.0.0) <751955F3-21FB-A03A-4E92-1F3D4EFB8C5B> /usr/lib/libresolv.9.dylib
0x97ea2000 - 0x97eb6ffb  com.apple.speech.synthesis.framework 3.10.35 (3.10.35) <9F5CE4F7-D05C-8C14-4B76-E43D07A8A680> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x97eb7000 - 0x97eebff7  libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <0B900F26-51C1-7639-346F-24B080AEDAF3> /usr/lib/libssl.0.9.8.dylib
0x97eec000 - 0x97ef2ff7  libCGXCoreImage.A.dylib 543.50.0 (compatibility 64.0.0) <94F66BA6-A4E8-63A4-1B70-EFAA4C75D668> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib
0x97ef3000 - 0x97efeff7  libGL.dylib ??? (???)  /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x97eff000 - 0x97ff1ff7  libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8)  /usr/lib/libcrypto.0.9.8.dylib
0x97ff2000 - 0x987e1557  com.apple.CoreGraphics 1.545.0 (???)  /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x987e2000 - 0x988acfef  com.apple.CoreServices.OSServices 357 (357)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x98922000 - 0x989ffff7  com.apple.vImage 4.0 (4.0)  /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x98aad000 - 0x98b48ff7  com.apple.ApplicationServices.ATS 275.11.1 (???) <5FF65EC7-F512-530A-7771-3DE240EE6E43> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x98b60000 - 0x98c8cfff  com.apple.audio.toolbox.AudioToolbox 1.6.3 (1.6.3)  /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x98c95000 - 0x98ce2feb  com.apple.DirectoryService.PasswordServerFramework 6.0 (6.0) <27F3FF53-F818-9836-2101-3E963FE0C0E0> /System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer
0x98ce3000 - 0x98d99ffb  libFontParser.dylib ??? (???) <067DC1A2-764B-41EA-B07E-4205472749B7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x98d9a000 - 0x98d9dfe7  libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib
0x98f51000 - 0x98f63ff7  com.apple.MultitouchSupport.framework 205.34 (205.34) <813475E3-B323-9405-F758-DDA1F5D63B20> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x98f64000 - 0x98f65ff7  com.apple.audio.units.AudioUnit 1.6.3 (1.6.3)  /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x98fa8000 - 0x98fa8ff7  com.apple.vecLib 3.6 (vecLib 3.6)  /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
0x98fbd000 - 0x98fbdff7  com.apple.ApplicationServices 38 (38)  /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x98fbe000 - 0x98fbeff7  liblangid.dylib ??? (???)  /usr/lib/liblangid.dylib
0x98fbf000 - 0x992e3fef  com.apple.HIToolbox 1.6.3 (???) <0A5F56E2-9AF3-728D-70AE-429522AEAD8A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x99493000 - 0x994a3ff7  libsasl2.2.dylib 3.15.0 (compatibility 3.0.0)  /usr/lib/libsasl2.2.dylib
0x995af000 - 0x995b1ff7  com.apple.securityhi 4.0 (36638) <38D36D4D-C798-6ACE-5FA8-5C001993AD6B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x99778000 - 0x99826ff3  com.apple.ink.framework 1.3.3 (107)  /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x99906000 - 0x9992cfff  com.apple.DictionaryServices 1.1.1 (1.1.1) <72D54B80-2D85-5BAB-CBB4-8002E150635D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x9992d000 - 0x9993eff7  com.apple.LangAnalysis 1.6.6 (1.6.6) <97511CC7-FE23-5AC3-2EE2-B5479FAEB316> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0xffff0000 - 0xffff1fff  libSystem.B.dylib ??? (???) <3441F338-2218-6D36-3F95-3A16FBF6713D> /usr/lib/libSystem.B.dylib

Model: MacBookPro7,1, BootROM MBP71.0039.B05, 2 processors, Intel Core 2 Duo, 2.66 GHz, 4 GB, SMC 1.62f6
Graphics: NVIDIA GeForce 320M, NVIDIA GeForce 320M, PCI, 256 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D), Broadcom BCM43xx 1.0 (5.10.131.16.1)
Bluetooth: Version 2.3.7f1, 2 service, 12 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: Hitachi HTS545050B9SA02, 465.76 GB
Serial ATA Device: MATSHITADVD-R   UJ-898
USB Device: Built-in iSight, 0x05ac  (Apple Inc.), 0x8507, 0x24600000
USB Device: Internal Memory Card Reader, 0x05ac  (Apple Inc.), 0x8403, 0x26100000
USB Device: BRCM2046 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x06600000
USB Device: Bluetooth USB Host Controller, 0x05ac  (Apple Inc.), 0x8213, 0x06610000
USB Device: IR Receiver, 0x05ac  (Apple Inc.), 0x8242, 0x06500000
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac  (Apple Inc.), 0x0236, 0x06300000

----------
components: IDLE
messages: 124134
nosy: Jill
priority: normal
severity: normal
status: open
title: brand new to programming.  crashes at run
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 16:52:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Dec 2010 15:52:01 +0000
Subject: [New-bugs-announce] [issue10719] compileall no longer warns when
	cli arguments name	non-existent files
In-Reply-To: <1292514721.24.0.504015013998.issue10719@psf.upfronthosting.co.za>
Message-ID: <1292514721.24.0.504015013998.issue10719@psf.upfronthosting.co.za>


New submission from R. David Murray :

The introduction of support for compiling individual files broke the previous behavior of compileall, where it would report that it could not turn a directory name into a file list if the named directory did not exist.

A fix would be to reverse the test used to determine whether or not to call compile_file: instead of calling it if the name is not a directory, we should call it if the name is a file, and pass everything else to compile_dir.  This would restore the previous behaviour.

Note that compileall considers not finding a named file/directory as successful compilation, so this is a low priority bug.

----------
keywords: easy
messages: 124136
nosy: r.david.murray
priority: low
severity: normal
stage: unit test needed
status: open
title: compileall no longer warns when cli arguments name non-existent files
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 19:02:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 18:02:06 +0000
Subject: [New-bugs-announce] [issue10720] test_threadsignals hang on FreeBSD
	6.4
In-Reply-To: <1292522526.66.0.947822056177.issue10720@psf.upfronthosting.co.za>
Message-ID: <1292522526.66.0.947822056177.issue10720@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

The title says it all. This is related to r87292 (issue8844).

----------
components: Library (Lib), Tests
messages: 124141
nosy: db3l, pitrou, rnk
priority: normal
severity: normal
status: open
title: test_threadsignals hang on FreeBSD 6.4
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 19:21:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 18:21:45 +0000
Subject: [New-bugs-announce] [issue10721] Remove HTTP 0.9 server support
In-Reply-To: <1292523705.43.0.300913774105.issue10721@psf.upfronthosting.co.za>
Message-ID: <1292523705.43.0.300913774105.issue10721@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

http.server has support for old-style HTTP 0.9 requests ("command path" without a version string). This issue proposes to remove this support, since there are probably no clients around which still issue such requests.

See issue10711 for the client side.

----------
components: Library (Lib)
files: http09server.patch
keywords: patch
messages: 124145
nosy: exarkun, giampaolo.rodola, gregory.p.smith, jhylton, orsenthil, pitrou, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Remove HTTP 0.9 server support
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20077/http09server.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 00:13:31 2010
From: report at bugs.python.org (T Rink)
Date: Thu, 16 Dec 2010 23:13:31 +0000
Subject: [New-bugs-announce] [issue10722] IDLE's subprocess didnit make
	connection ..... Python 2.7
In-Reply-To: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za>
Message-ID: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za>


New submission from T Rink :

Hi. 
My problem is that this evening, the message "IDLE's subprocess didn't make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection." appears after I hit F5 to run a file I am editing.

The program briefly worked on and off ... but after ca. 10 minutes it stopped for good. 

I have tried searhcing for solutions, but found nothing that seems to work. 

CONFIGURATION:
   Windows Vista 32
   Python 2.7 (downloaded a week ago)
   New User to Python. Amatuer/Hobby Programmer 

SOLUTIONS I HAVE TRIED
-Tried solution "kill process in task manager". No effect. Process was usually already closed by me anyway, but killing it did not help either. 

-Tried solution "repair via .MSI" file. No change.

-Tried to tell Windows Firewall to ignore python and pythonw, that they were acceptable. No change.  

-Would prefer not to "Scrap IDLE" as I just started! (Also I do not want to write Python only in Notepad and use command lines. As much as I love the command line, I do not want that anymore)

-Started to try to use workaround "-n" flag when starting IDLE. 
  a) I would prefer a Solution and not a Workaround that hinders the program before I am started.  
  b) I am new to Python and Idle. Windows Vista hides the links, it is not clear to me how Python is setup and I am still working on understanding how Python operates ... that is pain enough at the moment....

REQUEST:
 -Either a useful suggestion to get IDLE to work properly and as it should. 
 -Or a good recommendation for a universal and Idiot-Friendly alternative Python programming environment. It should be simple, user-friendly, reliable and suitable for novices to experiment (i.e. no complicated setup!) 

(FYI:I spent two years learning Java, and finally canned it, because I got sick of spending my free-time trying to debug and decipher workarounds to what should have been a simple solution! grrrrrrr!)

Thanks to any who can help.

----------
components: Windows
messages: 124163
nosy: plovet
priority: normal
severity: normal
status: open
title: IDLE's subprocess didnit make connection ..... Python 2.7
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 01:07:22 2010
From: report at bugs.python.org (flashk)
Date: Fri, 17 Dec 2010 00:07:22 +0000
Subject: [New-bugs-announce] [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>


New submission from flashk :

The "Built-in Exceptions" page of the Python 2.7 documentation is missing descriptions for BufferError, IndentationError, and TabError.

I've gone ahead and added a brief description of each error to the page.

----------
assignee: docs at python
components: Documentation
files: exceptions.rst
messages: 124165
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: Undocumented built-in exceptions
versions: Python 2.7
Added file: http://bugs.python.org/file20084/exceptions.rst

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 08:40:37 2010
From: report at bugs.python.org (sean216)
Date: Fri, 17 Dec 2010 07:40:37 +0000
Subject: [New-bugs-announce] [issue10724] socket.close close telnet with RST
In-Reply-To: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>
Message-ID: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>


New submission from sean216 :

when use socket.close to close the telnet connection, in normal usage the tcp disconnect will be (socket.close send the TCP FIN)

      TCP A                                                TCP B

  1.  ESTABLISHED                                          ESTABLISHED

  2.  (Close)
      FIN-WAIT-1  -->   --> CLOSE-WAIT

  3.  FIN-WAIT-2  <--       <-- CLOSE-WAIT

  4.                                                       (Close)
      TIME-WAIT   <--   <-- LAST-ACK

  5.  TIME-WAIT   -->       --> CLOSED

  6.  (2 MSL)
      CLOSED                                                      
but sometimes socket.close will send TCP RST to disconnect the telnet and with wrong sequence number. This kind of RST will be considering as Network RST attack, and this packet will be dropped, the telnet connection will still established and cannot be closed.
Seems python socket.close has some issues.

    def close(self):
        self._sock = _closedsocket()
        dummy = self._sock._dummy
        for method in _delegate_methods:
            setattr(self, method, dummy)
    close.__doc__ = _realsocket.close.__doc__

----------
components: Library (Lib)
files: telnet_unnormal RST.pcap
messages: 124187
nosy: sean216
priority: normal
severity: normal
status: open
title: socket.close close telnet with RST
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file20090/telnet_unnormal RST.pcap

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 10:48:34 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Dec 2010 09:48:34 +0000
Subject: [New-bugs-announce] [issue10725] Better cache instrumentation
In-Reply-To: <1292579314.55.0.548643170883.issue10725@psf.upfronthosting.co.za>
Message-ID: <1292579314.55.0.548643170883.issue10725@psf.upfronthosting.co.za>


New submission from Raymond Hettinger :

Nick, can you look at this?

----------
assignee: ncoghlan
components: Library (Lib)
files: sized_cache.diff
keywords: patch
messages: 124194
nosy: ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: Better cache instrumentation
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file20092/sized_cache.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 13:17:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Dec 2010 12:17:24 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue10726=5D_pydoc=3A_don?=
 =?utf-8?q?=E2=80=99t_display_raw_reST_in_keyword_help?=
In-Reply-To: <1292588244.03.0.247847700331.issue10726@psf.upfronthosting.co.za>
Message-ID: <1292588244.03.0.247847700331.issue10726@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

When one runs ?pydoc with?, the output is a block of text marked up with reST.  It would be more helpful to render it as text or HTML thanks to a minimal reST parser and transformer.

In http://mail.python.org/pipermail/python-dev/2010-July/101563.html, Martin Geisler (Mercurial dev) said:

?We're using light-weight ReST markup in the Mercurial help texts and
transform it into straight text upon display in the terminal.

We want no external dependencies for Mercurial, so I wrote a "mini ReST"
parser in about 400 lines of code. It cheats a lot and can only handle
simple constructs...? [A few messages later] ?I would be happy to relicense it under the Python license.?

So, proposed battle plan:
1) Agree this feature request is desirable.

2) Agree on the inclusion of mg?s minirst, which provides an reST parser and a plain text formatter.

3) Add an HTML formatter.

4) Wire minirst into pydoc.

----------
messages: 124196
nosy: eric.araujo
priority: normal
severity: normal
status: open
title: pydoc: don?t display raw reST in keyword help
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 21:05:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 20:05:29 +0000
Subject: [New-bugs-announce] [issue10727] intermittent test_cmd_line failure
In-Reply-To: <1292616329.6.0.61377155391.issue10727@psf.upfronthosting.co.za>
Message-ID: <1292616329.6.0.61377155391.issue10727@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

It really looks like a subprocess issue:

======================================================================
ERROR: test_usage (test.test_cmd_line.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py", line 43, in test_usage
    rc, out, err = assert_python_ok('-h')
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", line 50, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", line 30, in _assert_python
    env=env)
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", line 721, in __init__
    self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor


See http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/1213/steps/test/logs/stdio

----------
assignee: gregory.p.smith
components: Library (Lib)
messages: 124254
nosy: gregory.p.smith, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: intermittent test_cmd_line failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 04:10:56 2010
From: report at bugs.python.org (Silvio Ricardo Cordeiro)
Date: Sat, 18 Dec 2010 03:10:56 +0000
Subject: [New-bugs-announce] [issue10728] argparse.ArgumentParser.print_help
	uses sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>


New submission from Silvio Ricardo Cordeiro :

The documentation at http://docs.python.org/dev/library/argparse.html explicitly says that "If file is None, sys.stderr is assumed".

However, both print_usage and print_help assume sys.stdout when file=None. The helper method _print_message actually does it right, when called with file=None.

----------
components: Library (Lib)
messages: 124271
nosy: silvioricardoc
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser.print_help uses sys.stdout
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 09:49:32 2010
From: report at bugs.python.org (Ayman Elmasry)
Date: Sat, 18 Dec 2010 08:49:32 +0000
Subject: [New-bugs-announce] [issue10729] fwbackups python lib error
In-Reply-To: <1292662172.01.0.0120827412376.issue10729@psf.upfronthosting.co.za>
Message-ID: <1292662172.01.0.0120827412376.issue10729@psf.upfronthosting.co.za>


New submission from Ayman Elmasry :

I hope this topic is not completely unfitting here.

fwbackups error after backup attempt which concerned python lib:

ERROR : Traceback (most recent call last):   File "/usr/lib/python2.4/site-packages/fwbackups/operations/backup.py", line 698, in start  pkgListfiles = self.createPkgLists()   File "/usr/lib/python2.4/site-packages/fwbackups/operations/backup.py", line 85, in createPkgLists   fh = tempfile.NamedTemporaryFile(suffix='.txt', prefix="%s - tmp" % _('rpm - Package list'), delete=False)  TypeError: NamedTemporaryFile() got an unexpected keyword argument 'delete'

----------
components: Library (Lib)
messages: 124276
nosy: elmasry-ayman
priority: normal
severity: normal
status: open
title: fwbackups python lib error
versions: Python 2.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 14:13:14 2010
From: report at bugs.python.org (Grygoriy Fuchedzhy)
Date: Sat, 18 Dec 2010 13:13:14 +0000
Subject: [New-bugs-announce] [issue10730] add .svgz to mimetypes.suffix_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>


New submission from Grygoriy Fuchedzhy :

Please add '.svgz': '.svg.gz' map to mimetypes.suffix_map

----------
components: Library (Lib)
messages: 124282
nosy: gry
priority: normal
severity: normal
status: open
title: add .svgz to mimetypes.suffix_map
type: feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 16:22:41 2010
From: report at bugs.python.org (Marc Culler)
Date: Sat, 18 Dec 2010 15:22:41 +0000
Subject: [New-bugs-announce] [issue10731] UnicodeDecodeError in OS X tkinter
	when binding to	
In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za>
Message-ID: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za>


New submission from Marc Culler :

In OS X tkinter the "two-finger scroll" generates  events.

The following code:

#### bug.py
import tkinter

def mouse_wheel(event):
    print('Mouse wheel event')

tk = tkinter.Tk()
list = tkinter.Listbox(tk)
list.bind('', mouse_wheel)
for n in range(20):
    list.insert(tkinter.END, str(n**n))
list.pack(fill=tkinter.BOTH, expand=1)
tk.mainloop()
####

often throws a UnicodeDecodeError exception with a traceback like the one shown below when you do a "two-finger scroll" in the window.

Traceback (most recent call last):
  File "bug.py", line 12, in 
    tk.mainloop()
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/tkinter/__init__.py", line 1009, in mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x84 in position 1: unexpected code byte

The value of the byte changes from time to time, and sometimes it may be possible to scroll a few times without producing the error.

This problem did not occur on my Mandriva 2010.2 system.  I think it is specific to the Macintosh.  It might possibly be related to:
http://bugs.python.org/issue834351

----------
components: Tkinter
messages: 124287
nosy: culler
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in OS X tkinter when binding to 
type: crash
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 20:11:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Dec 2010 19:11:49 +0000
Subject: [New-bugs-announce] [issue10732] Wrong destructor function type in
	Python/getargs.c
In-Reply-To: <1292699509.72.0.581758913937.issue10732@psf.upfronthosting.co.za>
Message-ID: <1292699509.72.0.581758913937.issue10732@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

In getargs.c, in addcleanup_convert(), PyCapsule_SetContext() is called with a second argument "int (*destr)(PyObject*,void*)", but it really expects a "void (*PyCapsule_Destructor)(PyObject *)".
I'm not sure it's a good idea, although the ABI may be lenient enough on common architectures (?)...

----------
components: Interpreter Core
messages: 124307
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: Wrong destructor function type in Python/getargs.c
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 20:40:01 2010
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 18 Dec 2010 19:40:01 +0000
Subject: [New-bugs-announce] [issue10733] plistlib rejects strings
	containing control characters
In-Reply-To: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za>
Message-ID: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za>


New submission from Mitchell Model :

plistlib rejects control characters found in XML plists that Apple's 'plutil lint' accepts. I have attached my Terminal preferences as an example. (plistlib accepts the contents of the default Terminal preferences file)

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
files: com.apple.Terminal.plist
messages: 124311
nosy: MLModel, ronaldoussoren
priority: normal
severity: normal
status: open
title: plistlib rejects strings containing control characters
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file20104/com.apple.Terminal.plist

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 22:15:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Dec 2010 21:15:22 +0000
Subject: [New-bugs-announce] [issue10734] test_ttk failure under Windows
In-Reply-To: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>
Message-ID: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

It looks like the Windows buildbots have been failing since the tk upgrade (at least, I'm assuming it is related since there haven't been any tk changes recently).

======================================================================
FAIL: test_heading_callback (tkinter.test.test_ttk.test_widgets.TreeviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\tkinter\test\test_ttk\test_widgets.py", line 945, in test_heading_callback
    self.fail("The command associated to the treeview heading wasn't "
AssertionError: The command associated to the treeview heading wasn't invoked.

----------------------------------------------------------------------

(see e.g. http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x )

----------
components: Tests, Tkinter
messages: 124318
nosy: georg.brandl, gpolo, loewis, pitrou
priority: release blocker
severity: normal
status: open
title: test_ttk failure under Windows
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 19 07:28:29 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 06:28:29 +0000
Subject: [New-bugs-announce] [issue10735] platform.architecture() gives
	misleading results for OS	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>


New submission from Ned Deily :

OS X Mach-O universal executable files often contain multiple architectures including a combination of 32-bit and 64-bit archs, as with the newer OS X installer variants provided on python.org.  In such cases, the platform.architecture() function always returns '64bit' as the bit architecture regardless of whether the interpreter is running in 32-bit or 64-bit mode.  Thus, there is no documented way to reliably tell whether an interpreter is running in 32- or 64-bit in OS X.  Instead of the platform module, one must resort to hacks like examining sys.maxsize (or sys.maxint) or checking type sizes from the struct module.

$ arch -x86_64 /usr/local/bin/python3.2 -c 'import sys,platform; 
print(sys.maxsize,platform.architecture())'
9223372036854775807 ('64bit', '')
$ arch -i386 /usr/local/bin/python3.2 -c 'import sys,platform; 
print(sys.maxsize,platform.architecture())'
2147483647 ('64bit', '')

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 124331
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: platform.architecture() gives misleading results for OS X multi-architecture executables
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 19 14:29:55 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 13:29:55 +0000
Subject: [New-bugs-announce] [issue10736] test_ttk_guionly fails on OS X
	using ActiveState Tcl	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>


New submission from Ned Deily :

3.2b2(~)

The following two test failures are seen with the newly released Cocoa-based ActiveState Tcl 8.5.9 on OS X 10.6.  No failures are reported when using the Apple Tcl/Tk 8.5 supplied with 10.6.

======================================================================
ERROR: test_tab_identifiers (tkinter.test.test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/test/test_ttk/test_widgets.py", line 564, in test_tab_identifiers
    self.assertEqual(self.nb.tab('@5,5'), self.nb.tab('current'))
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/ttk.py", line 922, in tab
    return _val_or_dict(kw, self.tk.call, self._w, "tab", tab_id)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/ttk.py", line 318, in _val_or_dict
    res = func(*(args + options))
_tkinter.TclError: tab '@5,5' not found

======================================================================
FAIL: test_traversal (tkinter.test.test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/test/test_ttk/test_widgets.py", line 726, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child1))
AssertionError: '.4654766160' != '.4654766352'
- .4654766160
?         ^^^
+ .4654766352
?         ^^^

Also multiple instances of the following apparently harmless message appear when using the ActiveState 8.5.9 Tcl:

setCanCycle: is deprecated.  Please use setCollectionBehavior instead

This is likely due to an upstream build problem from ActiveState.

http://permalink.gmane.org/gmane.comp.lang.tcl.mac/6524

----------
assignee: ned.deily
components: Macintosh, Tests, Tkinter
messages: 124346
nosy: ned.deily, ronaldoussoren
priority: deferred blocker
severity: normal
status: open
title: test_ttk_guionly fails on OS X using ActiveState Tcl 8.5.9 (Cocoa)
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 19 14:32:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Dec 2010 13:32:45 +0000
Subject: [New-bugs-announce] [issue10737] test_concurrent_futures failure on
	Windows
In-Reply-To: <1292765565.27.0.231692660703.issue10737@psf.upfronthosting.co.za>
Message-ID: <1292765565.27.0.231692660703.issue10737@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

This has been happening recently on our Windows Server 2008 buildbot:


======================================================================
FAIL: test_first_completed (test.test_concurrent_futures.ThreadPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_concurrent_futures.py", line 252, in test_first_completed
    self.assertEqual(set([future1]), done)
AssertionError: Items in the second set but not the first:


======================================================================
FAIL: test_first_exception (test.test_concurrent_futures.ThreadPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_concurrent_futures.py", line 293, in test_first_exception
    self.assertEqual(set([future1, future2]), finished)
AssertionError: Items in the second set but not the first:


======================================================================
FAIL: test_first_exception_some_already_complete (test.test_concurrent_futures.ThreadPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_concurrent_futures.py", line 323, in test_first_exception_some_already_complete
    future1]), finished)
AssertionError: Items in the second set but not the first:


======================================================================
FAIL: test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_concurrent_futures.py", line 442, in test_timeout
    future1]), finished)
AssertionError: Items in the second set but not the first:



(see e.g. http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/306/steps/test/logs/stdio )

----------
assignee: bquinlan
components: Library (Lib), Tests
messages: 124347
nosy: bquinlan, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_concurrent_futures failure on Windows
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 19 16:05:23 2010
From: report at bugs.python.org (NE1)
Date: Sun, 19 Dec 2010 15:05:23 +0000
Subject: [New-bugs-announce] [issue10738] webbrowser.py bug with Opera on
	Linux
In-Reply-To: <1292771123.61.0.59980527904.issue10738@psf.upfronthosting.co.za>
Message-ID: <1292771123.61.0.59980527904.issue10738@psf.upfronthosting.co.za>


New submission from NE1 :

Tested with Python 2.7.1 / Linux 2.6.33.2 / Opera 10.63. Build 6450 for Linux

class Opera(UnixBrowser) shows:
raise_opts = ["", "-raise"]

"-raise" is not a valid command line option for Opera.

This causes all webbrowser open methods (that use autoraise=True by default) to not work correclty with Opera (webbrowser.open returns True, but Opera does not open, etc).

The raise options should probably be changed to:
raise_opts = ["-noraise", ""]

Opera - UNIX Command Line Options: http://www.opera.com/docs/switches/#unix

----------
messages: 124358
nosy: NE1
priority: normal
severity: normal
status: open
title: webbrowser.py bug with Opera on Linux
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 08:29:17 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 20 Dec 2010 07:29:17 +0000
Subject: [New-bugs-announce] [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>


New submission from Ross Lagerwall :

On Windows, creating a subprocess does not work when stdin (or stdout or stderr) is set as a file object created from socket.makefile(). An IOError is thrown.

This works fine on Unix so I assume it is a platform limitation rather than a Python bug.

If this is so then this should be documented under the subprocess module.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: test.py
messages: 124382
nosy: docs at python, rosslagerwall
priority: normal
severity: normal
status: open
title: Subprocess behavior on Windows
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20115/test.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 19:02:15 2010
From: report at bugs.python.org (Scott Urban)
Date: Mon, 20 Dec 2010 18:02:15 +0000
Subject: [New-bugs-announce] [issue10740] sqlite3 module should allow DDL
	statements in	transactions
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>


New submission from Scott Urban :

The python sqlite module automatically commits open transactions
when it encounters a DDL statement.  This is unnecessary; DDL is
transactional in my testing (see attached).

Attached patch addresses the issue. Patch is against 2.6.1, but
looking at Trunk in svn, it seems like the patch is needed and
would apply. One issue I could foresee is that this behavior might
depend on the sqlite version in use (I'm on 3.6.10).

Patch also allows pragma statement.

----------
components: Library (Lib)
files: pysql-transactions.2.diff
keywords: patch
messages: 124392
nosy: scott.urban
priority: normal
severity: normal
status: open
title: sqlite3 module should allow DDL statements in transactions
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20118/pysql-transactions.2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 19:09:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Dec 2010 18:09:52 +0000
Subject: [New-bugs-announce] [issue10741] PyGILState_GetThisThreadState()
	lacks a doc entry
In-Reply-To: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>
Message-ID: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

PyGILState_GetThisThreadState() is "documented" in Include/pystate.h but not in the official docs. It should be documented along PyGILState_Ensure() and friends.

----------
assignee: docs at python
components: Documentation
messages: 124394
nosy: docs at python, haypo, pitrou
priority: normal
severity: normal
status: open
title: PyGILState_GetThisThreadState() lacks a doc entry
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 22:33:42 2010
From: report at bugs.python.org (flashk)
Date: Mon, 20 Dec 2010 21:33:42 +0000
Subject: [New-bugs-announce] [issue10742] memoryview.readonly attribute is
	not documented
In-Reply-To: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>
Message-ID: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>


New submission from flashk :

The 'readonly' attribute is not explicitly described, even though it is used in the sample code for the memoryview type.

I've attached a patch that adds a description of the 'readonly' attribute.

----------
assignee: docs at python
components: Documentation
files: stdtypes.diff
keywords: patch
messages: 124403
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: memoryview.readonly attribute is not documented
versions: Python 2.7
Added file: http://bugs.python.org/file20121/stdtypes.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 23:06:43 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 20 Dec 2010 22:06:43 +0000
Subject: [New-bugs-announce] [issue10743] 3.2's sysconfig doesn't work with
	virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar :

>From http://code.google.com/p/virtualenv5/issues/detail?id=6 - it seems that the `sysconfig` module is looking for Makefile in wrong directory, while ideally it must be looking into the base Python install.

>> import sysconfig; sysconfig.get_paths('purelib')
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 332, in _init_posix
    _parse_makefile(makefile, vars)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 220, in _parse_makefile
    with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: '/tmp/e/lib/python3.2/config-3.2m/Makefile'

----------
assignee: tarek
components: Distutils, Macintosh
messages: 124405
nosy: eric.araujo, srid, tarek
priority: normal
severity: normal
status: open
title: 3.2's sysconfig doesn't work with virtualenv
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 23:06:48 2010
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 20 Dec 2010 22:06:48 +0000
Subject: [New-bugs-announce] [issue10744] ctypes arrays have incorrect
	buffer information	(PEP-3118)
In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za>
Message-ID: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za>


New submission from Pauli Virtanen :

Ctypes arrays have invalid buffer interface information (on Python 3.1.2):

>>> import ctypes
>>> x = (ctypes.c_double*2)()
>>> y = memoryview(x)
>>> y.shape
(2,)
>>> y.format
'(2)

_______________________________________

From report at bugs.python.org  Mon Dec 20 23:11:54 2010
From: report at bugs.python.org (Chris Lasher)
Date: Mon, 20 Dec 2010 22:11:54 +0000
Subject: [New-bugs-announce] [issue10745] --user option,
	per user site-packages undocumented in Installing Python
	Modules	document
In-Reply-To: <1292883114.81.0.0146533387318.issue10745@psf.upfronthosting.co.za>
Message-ID: <1292883114.81.0.0146533387318.issue10745@psf.upfronthosting.co.za>


New submission from Chris Lasher :

Python 2.6 saw the introduction of per user site-packages directory for easy installation of Python packages into a guaranteed location in which the user has appropriate permissions.

http://bugs.python.org/issue1799
http://www.python.org/dev/peps/pep-0370/
http://docs.python.org/whatsnew/2.6.html#pep-370-per-user-site-packages-directory

With it came a new option available in distutils-powered setup.py scripts, "--user". It has been a year since this feature was introduced, yet no documentation has appeared in the official Python Documentation other than in the "What's New" document. Specifically, this option should appear and be documented in the "Installing Python Modules" document.

http://docs.python.org/install/

It would be very helpful if the documentation described the advantages of using this option over "--home" and "--prefix".

I am not the first user to notice this gap in the documentation, e.g.,

http://www.devx.com/opensource/Article/42353/1763

however, I couldn't find any bugs open for this issue so I have created this new one.

----------
assignee: tarek
components: Distutils, Documentation
messages: 124408
nosy: eric.araujo, gotgenes, tarek
priority: normal
severity: normal
status: open
title: --user option, per user site-packages undocumented in Installing Python Modules document
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 Dec 21 00:37:28 2010
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 20 Dec 2010 23:37:28 +0000
Subject: [New-bugs-announce] [issue10746] ctypes c_long & c_bool have
	incorrect PEP-3118 type codes
In-Reply-To: <1292888248.06.0.197043159654.issue10746@psf.upfronthosting.co.za>
Message-ID: <1292888248.06.0.197043159654.issue10746@psf.upfronthosting.co.za>


New submission from Pauli Virtanen :

Currently on Python 3.x:

>>> import ctypes
>>> memoryview(ctypes.c_long()).format
'>> import numpy as np
>>> from ctypes import *
>>> class Point(Structure):
...     _fields_ = [("x", c_long), ("y", c_long)]
... 
>>> class StructWithArrays(Structure):
...     _fields_ = [("x", c_long * 3 * 2), ("y", Point * 4)]
... 
>>> x = StructWithArrays()
>>> y = np.asarray(x)
>>> y.dtype
dtype([('x', '>> y['x'] = [[1,2,3],[4,5,6]]
>>> y['y']['x'] = np.arange(4) + 10
>>> y['y']['y'] = np.arange(4) + 20
>>> x.x[0][0]
1
>>> x.x[0][1]
2
>>> x.x[0][2]
3
>>> x.y[0].x
10
>>> x.y[1].x
11
>>> x.y[0].y
20
>>> x.y[1].y
21

----------
files: 001-ctypes-fix-pep-3118-type-codes-for-c-long-and-c-bool.patch
keywords: patch
messages: 124411
nosy: pv
priority: normal
severity: normal
status: open
title: ctypes c_long & c_bool have incorrect PEP-3118 type codes
Added file: http://bugs.python.org/file20124/001-ctypes-fix-pep-3118-type-codes-for-c-long-and-c-bool.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 12:53:59 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 21 Dec 2010 11:53:59 +0000
Subject: [New-bugs-announce] [issue10747] Include version info in Windows
	shortcuts
In-Reply-To: <1292932439.68.0.958376446451.issue10747@psf.upfronthosting.co.za>
Message-ID: <1292932439.68.0.958376446451.issue10747@psf.upfronthosting.co.za>


New submission from Nick Coghlan :

This issue is to propose specific wording to Martin for inclusion of version details in the Windows shortcuts. This is to make the shortcuts easier to use when the hierarchical menu information is lost for any reason (e.g frequently used program list, searching the start menu, copied to desktop).

Shortcuts currently installed:
- Python (command line)
- Python Manuals
- Module Docs
- IDLE (Python GUI)
- Uninstall Python

Initial proposal for 32 bit builds:
- Python 3.2 (command line - 32 bit)
- Python 3.2 Manuals
- Python 3.2 Docs Server (pydoc - 32 bit)
- IDLE (Python 3.2 GUI - 32 bit)
- Uninstall Python 3.2 (32 bit)

Initial proposal for 64 bit builds:
- Python 3.2 (command line - 64 bit)
- Python 3.2 Manuals
- Python 3.2 Docs Server (pydoc - 64 bit)
- IDLE (Python 3.2 GUI - 64 bit)
- Uninstall Python 3.2 (64 bit)

Any feedback/alternate suggestions/bikeshedding on the python-dev thread, please ;)

----------
messages: 124427
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Include version info in Windows shortcuts
type: feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 17:30:28 2010
From: report at bugs.python.org (Ian Stevens)
Date: Tue, 21 Dec 2010 16:30:28 +0000
Subject: [New-bugs-announce] [issue10748] zipfile does not write empty ZIP
	structure if close()	called after __init__() as doc suggests
In-Reply-To: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>
Message-ID: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>


New submission from Ian Stevens :

The zipfile documentation (http://docs.python.org/library/zipfile.html) states:

"If the file is created with mode 'a' or 'w' and then close()d without adding any files to the archive, the appropriate ZIP structures for an empty archive will be written to the file."

This is not the case, eg.::

    >>> from StringIO import StringIO
    >>> import zipfile
    >>> s = StringIO()
    >>> z = zipfile.ZipFile(s, 'w')
    >>> z.close()
    >>> s.len
    0

The code for zipfile (http://svn.python.org/projects/python/trunk/Lib/zipfile.py) does not support the documentation either. The ending records are written only if ZipFile._didModify is True, and that attribute is only set to True if writestr() or write() are called.

Either the code should be fixed to support writing the ending records on an empty zip, or the documentation should be changed to reflect the existing behaviour.

Test case (for Lib/test/test_zipfile)::

    def test_close_empty_zip_creates_valid_zip(self):
        # Test that close() called on a ZipFile without write creates a valid ZIP.
        zf = zipfile.ZipFile(TESTFN, "w")
        zf.close()
        chk = zipfile.is_zipfile(TESTFN)
        self.assertTrue(chk)

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 124433
nosy: Ian.Stevens, docs at python
priority: normal
severity: normal
status: open
title: zipfile does not write empty ZIP structure if close() called after __init__() as doc suggests
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 19:38:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 18:38:59 +0000
Subject: [New-bugs-announce] [issue10749] lots of warnings when generating
	logging docs
In-Reply-To: <1292956739.84.0.250201293355.issue10749@psf.upfronthosting.co.za>
Message-ID: <1292956739.84.0.250201293355.issue10749@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

"make html" in the Doc directory and then:

[...]
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:507: WARNING: duplicate object description of logging.logging.Formatter.__init__, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst, use :noindex: for one of them
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:733: WARNING: duplicate label library-config, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:849: WARNING: duplicate label useful-handlers, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:834: WARNING: duplicate label custom-levels, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:944: WARNING: duplicate label logging-exceptions, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:969: WARNING: duplicate label arbitrary-object-messages, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:460: WARNING: duplicate label handler-basic, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:596: WARNING: duplicate label filters-contextual, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:149: WARNING: duplicate label multiple-destinations, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:333: WARNING: duplicate label network-logging, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:470: WARNING: duplicate label context-info, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:872: WARNING: duplicate label zeromq-handlers, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:670: WARNING: duplicate label multiple-processes, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
[...]

----------
assignee: vinay.sajip
components: Documentation, Library (Lib)
messages: 124446
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: lots of warnings when generating logging docs

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 21:21:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 20:21:59 +0000
Subject: [New-bugs-announce] [issue10750] "raw" attribute of buffered IO
	objects is assignable
In-Reply-To: <1292962919.83.0.998422022844.issue10750@psf.upfronthosting.co.za>
Message-ID: <1292962919.83.0.998422022844.issue10750@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

This really looks backwards:

>>> f = open("LICENSE", "rb")
>>> f.name = "bar"
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: attribute 'name' of '_io.BufferedReader' objects is not writable
>>> f.raw = None
__main__:1: ResourceWarning: unclosed file <_io.FileIO name='LICENSE' mode='rb'>
>>>

----------
components: IO, Library (Lib)
messages: 124451
nosy: amaury.forgeotdarc, benjamin.peterson, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "raw" attribute of buffered IO objects is assignable
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 23:46:16 2010
From: report at bugs.python.org (Alex Raitz)
Date: Tue, 21 Dec 2010 22:46:16 +0000
Subject: [New-bugs-announce] [issue10751] WSGIREF - REMOTE_USER and
	REMOTE-USER collision
In-Reply-To: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>
Message-ID: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>


New submission from Alex Raitz :

Clients can overwrite 'REMOTE_USER' header variable value with an arbitrary 'Remote-User' value by specifying the later after the former.

This has tricky implications when a proxy server is being used, namely that if the proxy passes a re-written REMOTE_USER but also the user-supplied 'Remote-User', Python WSGI will actually store HTTP_REMOTE_USER as the value of the user-supplied 'Remote-User' header based on the order that the headers are processed. 

./python2.6/wsgiref/headers.py:

184         for k, v in _params.items():
185             if v is None:
186                 parts.append(k.replace('_', '-'))
187             else:
188                 parts.append(_formatparam(k.replace('_', '-'), v))

----------
components: Extension Modules
messages: 124466
nosy: Alex.Raitz
priority: normal
severity: normal
status: open
title: WSGIREF - REMOTE_USER and REMOTE-USER collision
type: security
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 22 00:09:42 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 21 Dec 2010 23:09:42 +0000
Subject: [New-bugs-announce] [issue10752] build_ssl.py is relying on
	unreliable behaviour of	os.popen
In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za>
Message-ID: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar :

I noticed that despite ActivePerl being installed, `os.popen(...).close()` returned 1 (see find_working_perl in build_ssl.py), while in actuality that command executed successfully with return code 0; I verified this by using the subprocess module.

Here's a patch:

--- python/PCbuild/build_ssl.py.orig
+++ python/PCbuild/build_ssl.py
@@ -45,11 +45,11 @@
 # Being a Perl dummy, the simplest way I can check is if the "Win32" package
 # is available.
 def find_working_perl(perls):
+    import subprocess
     for perl in perls:
-        fh = os.popen('"%s" -e "use Win32;"' % perl)
-        fh.read()
-        rc = fh.close()
-        if rc:
+        try:
+            subprocess.check_call('"%s" -e "use Win32;"' % perl, shell=True)
+        except subprocess.CalledProcessError:
             continue
         return perl
     print("Can not find a suitable PERL:")

----------
components: Build, Windows
messages: 124467
nosy: srid
priority: normal
severity: normal
status: open
title: build_ssl.py is relying on unreliable behaviour of os.popen
type: compile error
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 22 00:42:28 2010
From: report at bugs.python.org (Timothy Gates)
Date: Tue, 21 Dec 2010 23:42:28 +0000
Subject: [New-bugs-announce] [issue10753] request_uri method of wsgiref
	module does not support	RFC1808 params.
In-Reply-To: <1292974948.23.0.113503342061.issue10753@psf.upfronthosting.co.za>
Message-ID: <1292974948.23.0.113503342061.issue10753@psf.upfronthosting.co.za>


New submission from Timothy Gates :

Consider the URL making use of the RFC1808 param syntax...

http://www/path;cookie=1234

The entire section '/path;cookie=1234' is passed in as PATH_INFO and so under the request_uri implementation it will be quoted

> import wsgiref
> wsgiref.request_uri({'wsgi.url_scheme': 'http', 'HTTP_HOST': 'www', 'PATH_INFO': '/path;cookie=1234'})
'http://www/path%3Bcookie%3D1234'

----------
components: Library (Lib)
messages: 124468
nosy: Timothy.Gates
priority: normal
severity: normal
status: open
title: request_uri method of wsgiref module does not support RFC1808 params.
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 22 02:52:00 2010
From: report at bugs.python.org (Wang Yanjin)
Date: Wed, 22 Dec 2010 01:52:00 +0000
Subject: [New-bugs-announce] [issue10754] os.path.isfile doesn't work with
	some greek characters
In-Reply-To: <1292982720.53.0.448142280407.issue10754@psf.upfronthosting.co.za>
Message-ID: <1292982720.53.0.448142280407.issue10754@psf.upfronthosting.co.za>


New submission from Wang Yanjin :

There is a file named "?Torrent.lnk" in the folder.

Here is the code:

#encoding=utf-8

import os
for i in os.listdir('.'):
    print os.path.isfile(i), '\t', i
a = input()

and the output:


True    3.py
False   a???.txt
True    uTorrent.lnk
False   ?Torrent.lnk
False   ?Torrent1.lnk
False   ???.txt
False   ???.txt.lnk
True    ?????
True    ??.txt
True    ??.txt.lnk


the function just doesn't work with the character "?"

----------
components: Unicode, Windows
messages: 124473
nosy: wyj1046
priority: normal
severity: normal
status: open
title: os.path.isfile doesn't work with some greek characters
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 22 08:26:15 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 22 Dec 2010 07:26:15 +0000
Subject: [New-bugs-announce] [issue10755] Add posix.fdlistdir
In-Reply-To: <1293002775.56.0.279049090331.issue10755@psf.upfronthosting.co.za>
Message-ID: <1293002775.56.0.279049090331.issue10755@psf.upfronthosting.co.za>


New submission from Ross Lagerwall :

Along with #4761, the *at wrappers, it would be nice to have a patch adding the use of fdopendir.

This patch adds a function fdlistdir, a unittest and documentation.

----------
components: Extension Modules
files: i_fdlistdir.patch
keywords: patch
messages: 124489
nosy: Chris.Gerhard, anacrolix, benjamin.peterson, christian.heimes, durban, loewis, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: Add posix.fdlistdir
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20136/i_fdlistdir.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 22 08:58:36 2010
From: report at bugs.python.org (kai zhu)
Date: Wed, 22 Dec 2010 07:58:36 +0000
Subject: [New-bugs-announce] [issue10756] Error in atexit._run_exitfuncs
	[...] Exception expected	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>


New submission from kai zhu :

public at colinux 3 ~: python3.2
Python 3.2b2 (py3k, Dec 22 2010, 02:38:55) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import atexit; atexit.register(lambda:1/0)
 at 0xb7c7e12c>
>>> exit()
Error in atexit._run_exitfuncs:
TypeError: print_exception(): Exception expected for value, str found



might b related to Issue5089, so included those ppl to nosy.  this bug is subtle.  unit tests which explicitly 'raise' exceptions will not b caught, e.g. this will raise properly:

@exit.register
def foo(): raise ZeroDivisionError()

----------
components: Interpreter Core
messages: 124490
nosy: BreamoreBoy, kaizhu, mark.dickinson
priority: normal
severity: normal
status: open
title: Error in atexit._run_exitfuncs [...]  Exception expected for value, str found
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 22 13:44:06 2010
From: report at bugs.python.org (=?utf-8?b?SmFjZWsgSmFixYJvxYRza2k=?=)
Date: Wed, 22 Dec 2010 12:44:06 +0000
Subject: [New-bugs-announce] [issue10757] zipfile.write,
	arcname should be bytestring
In-Reply-To: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za>
Message-ID: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za>


New submission from Jacek Jab?o?ski :

file = 'somefile.dat'
filename = "?????????.dat"
zip = zipfile.ZipFile('archive.zip', 'w', zipfile.ZIP_DEFLATED)
zip.write(file, filename)

above produces very nasty filename in zip archive.
*************************************************************
file = 'somefile.dat'
filename = "?????????.dat"
zip = zipfile.ZipFile('archive.zip', 'w', zipfile.ZIP_DEFLATED)
zip.write(file, filename.encode('cp852'))

this produces TypeError: expected an object with the buffer interface

Documentation says that:
There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write().

I convert them to byte string but it ends with an error.
If it is documentation bug, what is the proper way to have filenames like "?????????" in zip archive?

----------
components: Library (Lib)
messages: 124499
nosy: connexion2000
priority: normal
severity: normal
status: open
title: zipfile.write, arcname should be bytestring
type: compile error
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 22 13:45:10 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Dec 2010 12:45:10 +0000
Subject: [New-bugs-announce] [issue10758] posix_access swallows all errors
In-Reply-To: <1293021910.31.0.818314214299.issue10758@psf.upfronthosting.co.za>
Message-ID: <1293021910.31.0.818314214299.issue10758@psf.upfronthosting.co.za>


New submission from Georg Brandl :

access(2) can return errnos that correspond to input errors or general system faults, such as EINVAL, EIO or ENOMEM.  In this case, an exception should be raised instead of returning False.

It is probably best to whitelist those errnos that indicate missing access -- it needs to be discussed whether that is just EACCES, or also e.g. ENOENT.

----------
components: Library (Lib)
messages: 124500
nosy: georg.brandl
priority: normal
severity: normal
stage: needs patch
status: open
title: posix_access swallows all errors
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 22 14:51:08 2010
From: report at bugs.python.org (Martin Potthast)
Date: Wed, 22 Dec 2010 13:51:08 +0000
Subject: [New-bugs-announce] [issue10759] HTMLParser.unescape() cannot
	handle HTML entities with	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>


New submission from Martin Potthast :

The title says it all; try the minimal example.

----------
components: Library (Lib)
files: parser-fail.py
messages: 124506
nosy: Martin.Potthast
priority: normal
severity: normal
status: open
title: HTMLParser.unescape() cannot handle HTML entities with incorrect syntax (e.g. &#hearts;)
versions: Python 2.6
Added file: http://bugs.python.org/file20139/parser-fail.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 22 18:05:54 2010
From: report at bugs.python.org (Yoni Tsafir)
Date: Wed, 22 Dec 2010 17:05:54 +0000
Subject: [New-bugs-announce] [issue10760] tarfile doesn't handle sysfs well
In-Reply-To: <1293037554.87.0.808780630488.issue10760@psf.upfronthosting.co.za>
Message-ID: <1293037554.87.0.808780630488.issue10760@psf.upfronthosting.co.za>


New submission from Yoni Tsafir :

When I try to add a special file from sys, e.g.:
/sys/class/scsi_host/host0/cmd_per_lun (which is reported of size 4096 but actually reading it will return only several bytes of a result), I get the following exception:

Traceback (most recent call last):
  File "/opt/xpyv/lib/python26.zip/tarfile.py", line 1975, in add
    self.addfile(tarinfo, f)
  File "/opt/xpyv/lib/python26.zip/tarfile.py", line 2004, in addfile
    copyfileobj(fileobj, self.fileobj, tarinfo.size)
  File "/opt/xpyv/lib/python26.zip/tarfile.py", line 287, in copyfileobj
    raise IOError("end of file reached")
IOError: end of file reached

Notice what happens if I try to add the file with regular tar:
root at buzaglo # tar cvzf /tmp/blat.tgz /sys/class/scsi_host/host0/cmd_per_lun
tar: Removing leading `/' from member names
/sys/class/scsi_host/host0/cmd_per_lun
tar: /sys/class/scsi_host/host0/cmd_per_lun: File shrank by 4094 bytes; padding with zeros
tar: Error exit delayed from previous errors

So it handles the issue by padding the rest of the file size with zeros.

I think this should be the behavior as well, instead of throwing an IOError.

----------
components: None
messages: 124514
nosy: Yoni.Tsafir
priority: normal
severity: normal
status: open
title: tarfile doesn't handle sysfs well
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 23 01:17:16 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 23 Dec 2010 00:17:16 +0000
Subject: [New-bugs-announce] [issue10761] tarfile.extractall fails to
	overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar :

tarfile.extractall overwrites normal files and directories, yet it fails to overwrite symlinks:

  [..]
    tf.extractall()
  File "/opt/ActivePython-2.7/lib/python2.7/tarfile.py", line 2046, in extractall
    self.extract(tarinfo, path)
  File "/opt/ActivePython-2.7/lib/python2.7/tarfile.py", line 2083, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "/opt/ActivePython-2.7/lib/python2.7/tarfile.py", line 2167, in _extract_member
    self.makelink(tarinfo, targetpath)
  File "/opt/ActivePython-2.7/lib/python2.7/tarfile.py", line 2243, in makelink
    os.symlink(tarinfo.linkname, targetpath)
OSError: [Errno 17] File exists

To reproduce, use a .tar.gz file containing relative (i.e., in the same directory) symlinks.

Perhaps it should delete `targetpath` before attempting to create a symlink.

----------
components: Library (Lib)
messages: 124523
nosy: srid
priority: normal
severity: normal
status: open
title: tarfile.extractall fails to overwrite symlinks
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 23 10:57:42 2010
From: report at bugs.python.org (David Leonard)
Date: Thu, 23 Dec 2010 09:57:42 +0000
Subject: [New-bugs-announce] [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>


New submission from David Leonard :

Installed http://www.python.org/ftp/python/2.7.1/python-2.7.1.amd64.msi
on Windows 7, x64 into C:\Python27

C:\>\Python27\python.exe
Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%f')

Dialog raises: "Python.exe has stopped working"

----------
components: Library (Lib)
messages: 124542
nosy: dleonard0
priority: normal
severity: normal
status: open
title: strftime('%f') segfault
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 23 12:59:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 11:59:28 +0000
Subject: [New-bugs-announce] [issue10763] subprocess.communicate() doesn't
	close pipes on Windows
In-Reply-To: <1293105568.33.0.901642583653.issue10763@psf.upfronthosting.co.za>
Message-ID: <1293105568.33.0.901642583653.issue10763@psf.upfronthosting.co.za>


New submission from STINNER Victor :

If more than one file (stdin, stdout and stderr) are pipes, Popen.communicate() uses threads calling _readerthread() on each pipe. But this method doesn't close the pipes, whereas all other communicate implementations (select, poll and the optimization if there is only one pipe) do close all pipes.

Attached patch fixes this issue.

Thanks Antoine for your nice ResourceWarning patch!

----------
components: Library (Lib), Windows
files: subprocess_close_pipes.patch
keywords: patch
messages: 124547
nosy: haypo
priority: normal
severity: normal
status: open
title: subprocess.communicate() doesn't close pipes on Windows
versions: Python 3.2
Added file: http://bugs.python.org/file20146/subprocess_close_pipes.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 23 18:56:24 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 23 Dec 2010 17:56:24 +0000
Subject: [New-bugs-announce] [issue10764] sysconfig and alternative
	implementations
In-Reply-To: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>
Message-ID: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>


New submission from Michael Foord :

sysconfig assumes there will be a makefile if the platform is posix, which isn't always true. For example IronPython on Mac OS X with mono.

This leads to a traceback on startup with IronPython 2.7:

$ ipy27
Traceback (most recent call last):
  File "/Second/michael/Downloads/IronPython-2.7/Lib/site.py", line 548, in 
  File "/Second/michael/Downloads/IronPython-2.7/Lib/site.py", line 530, in main
  File "/Second/michael/Downloads/IronPython-2.7/Lib/site.py", line 264, in addusersitepackages
  File "/Second/michael/Downloads/IronPython-2.7/Lib/site.py", line 239, in getusersitepackages
  File "/Second/michael/Downloads/IronPython-2.7/Lib/site.py", line 229, in getuserbase
  File "/Second/michael/Downloads/IronPython-2.7/Lib/sysconfig.py", line 518, in get_config_var
  File "/Second/michael/Downloads/IronPython-2.7/Lib/sysconfig.py", line 421, in get_config_vars
  File "/Second/michael/Downloads/IronPython-2.7/Lib/sysconfig.py", line 275, in _init_posix
IOError: invalid Python installation: unable to open /Volumes/Second Drive/michael/Downloads/IronPython-2.7/lib/python2.7/config/Makefile (Could not find a part of the path "/Volumes/Second Drive/michael/Downloads/IronPython-2.7/lib/python2.7/config/Makefile".)IronPython 2.7 Beta 1 (2.7.0.10) on .NET 4.0.30319.1
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------
messages: 124560
nosy: eric.araujo, michael.foord, tarek
priority: normal
severity: normal
status: open
title: sysconfig and alternative implementations
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 24 00:19:07 2010
From: report at bugs.python.org (Martin)
Date: Thu, 23 Dec 2010 23:19:07 +0000
Subject: [New-bugs-announce] [issue10765] Build regression from automation
	changes on windows
In-Reply-To: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za>
Message-ID: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za>


New submission from Martin :

The build changes in r87093 broke me, as my py3k branch is under a dir with a space in the name, and the OutDir path needs escaping in the makefiles. Various extra quoting seems to be sufficient, though inelegant.

----------
components: Build, Windows
files: py3k_build.patch
keywords: patch
messages: 124575
nosy: gz, loewis
priority: normal
severity: normal
status: open
title: Build regression from automation changes on windows
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20151/py3k_build.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 24 00:59:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Dec 2010 23:59:13 +0000
Subject: [New-bugs-announce] [issue10766] optparse uses %s in gettext calls
In-Reply-To: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za>
Message-ID: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

When you run xgettext other optparse.py, you get this warning:
?'msgid' format string with unnamed arguments cannot be properly localized: The translator cannot reorder the arguments.  Please consider using a format string with named arguments, and a mapping instead of a tuple for the arguments.?

Attached patch fixes the incorrect calls (my patch for #4391 already fixes two of them).

See similar bug and fix for argparse in #10528.  Georg, please tell if this can go into 3.2.

----------
assignee: eric.araujo
components: Library (Lib)
files: fix-gettext-positionals.diff
keywords: patch
messages: 124578
nosy: eric.araujo, georg.brandl, gward
priority: normal
severity: normal
stage: commit review
status: open
title: optparse uses %s in gettext calls
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20153/fix-gettext-positionals.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 24 04:32:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Dec 2010 03:32:05 +0000
Subject: [New-bugs-announce] [issue10767] Lib/test/crashers/README is out of
	date
In-Reply-To: <1293161525.36.0.778982454407.issue10767@psf.upfronthosting.co.za>
Message-ID: <1293161525.36.0.778982454407.issue10767@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky :

Among other things, README says:

"""
Each test should have a link to the bug report:

        # http://python.org/sf/BUG#

"""

but the only such link is found in crashers/infinite_loop_re.py and points to a closed issue 1541697.

It looks like the purpose of Lib/test/crashers has changed from being a repository of outstanding bugs to a repository of crashers that are not considered to be bugs.

----------
assignee: docs at python
components: Documentation, Tests
messages: 124586
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Lib/test/crashers/README is out of date

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 24 11:03:13 2010
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 24 Dec 2010 10:03:13 +0000
Subject: [New-bugs-announce] [issue10768] Bug in scrolledtext
In-Reply-To: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>
Message-ID: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>


New submission from Pierre Quentel :

The scrolledtext example crashes with this message :

TypeError: unsupported operand type(s) for +: 'dict_keys' and 'dict_keys'

It works if keys() are converted to lists in line 33 :

methods = list(vars(Pack).keys()) + list(vars(Grid).keys()) + \list(vars(Place).keys())

Configuration : Python 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)] on win32

----------
components: Tkinter
messages: 124593
nosy: quentel
priority: normal
severity: normal
status: open
title: Bug in scrolledtext
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 24 15:07:48 2010
From: report at bugs.python.org (Sven Brauch)
Date: Fri, 24 Dec 2010 14:07:48 +0000
Subject: [New-bugs-announce] [issue10769] ast: provide more useful range
	information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>


New submission from Sven Brauch :

Hi,

I'm writing a python language support plugin for an IDE. I'm using the AST module to get information about the loaded source code, which works pretty well. However, in some cases, the information provided by the AST is simply not sufficient to do proper highlighting (or whatever); for example, 

class_instance.method(argument1.arg_attribute).attribute
class_instance.method(   argument1.    arg_attribute)    . attribute
and
class_instance.method(   argument1. \
                         arg_attribute)   \
                                   . attribute

produce exactly the same syntax tree, making it impossible to determine where e.g. "attribute" starts and ends. Although technically obviously correct, the information that the column offset for "attribute" is "0" is quite pointless.

It would really be great if there could be an additional attribute for Attribute Access nodes which tells me where the attribute access the node refers to *really* takes place, not just "column 0". :)
It would be even better if there was not only an offset, but also an "end" attribute providing information on where the node ends; that'd make this module way more useful, at least for me.

Thanks and best regards,
Sven

----------
components: Library (Lib)
messages: 124596
nosy: georg.brandl, scummos
priority: normal
severity: normal
status: open
title: ast: provide more useful range information
type: feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 24 19:49:54 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 24 Dec 2010 18:49:54 +0000
Subject: [New-bugs-announce] [issue10770] zipinfo - fix of a typo in the doc
In-Reply-To: <1293216594.75.0.298298210336.issue10770@psf.upfronthosting.co.za>
Message-ID: <1293216594.75.0.298298210336.issue10770@psf.upfronthosting.co.za>


New submission from Sandro Tosi :

Hello,
as reported[1] on python-doc, there's a typo in zipinfo doc.

[1] http://mail.python.org/pipermail/docs/2010-December/002526.html

The attached (trivial) patch fixes it; the file would also need a rewrap to 80th column.

Cheers,
Sandro

----------
assignee: sandro.tosi
components: Documentation
files: zipinfo_typo.patch
keywords: patch
messages: 124600
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: zipinfo - fix of a typo in the doc
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20156/zipinfo_typo.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 25 06:05:54 2010
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sat, 25 Dec 2010 05:05:54 +0000
Subject: [New-bugs-announce] [issue10771] descriptor protocol documentation
	has two different	definitions of "owner" class
In-Reply-To: <1293253554.32.0.921681514845.issue10771@psf.upfronthosting.co.za>
Message-ID: <1293253554.32.0.921681514845.issue10771@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre :

In trunk/Doc/reference/datamodel.rst , under _Implementing Descriptors_, the documentation states: 

`The following methods only apply when an instance of the class containing the method (a so-called *descriptor* class) appears in the class dictionary of another new-style class, known as the *owner* class. [...]`

Immediately below, in the documentation for __get__, it says, `*owner* is always the owner class [...]`.

These two uses of "the owner class" are incompatible, because there is only one class which matches the first use: the class where the descriptor was initially assigned to a class attribute; however, for the second use, any descendant class may be called "the owner class". This is demonstrated in the attached doctest file.

It is kind of hard to create a better definition for "owner" as used in `__get__`, though. It can't be said to be the class with the descriptor in its class dict, because it can be present in the class dict of some class in the MRO of the owner. It can't be said to be an attribute, because it has to be in a class dict of an ancestor node.

It might be possible to change the definition to call the owner class something like, "the class from which the descriptor was invoked", and if that isn't clear enough, provide examples (TypeDescriptor from the attached doctest file might work as an example); however, this would involve reworking the structure of the paragraph substantially. I personally would prefer this option. The paragraph is already badly structured; for example, it defines two terms in a single and rather complex sentence, and should probably be split up into a list of definitions rather than an explanatory jumble paragraph. In addition, this paragraph is the only place in the documentation where this idea of "the owner class" is used in this way. In the descriptions of the descriptor protocol methods below it, "the owner class" always refers to the class from which the attribute was accessed, or the type from which an instance had the attribute accessed.

Alternatively, it could be simpler to replace all references below from "the owner class" to "any class with the owner class in the MRO".

----------
assignee: docs at python
components: Documentation
files: descriptor.py.doctest
messages: 124630
nosy: Devin Jeanpierre, docs at python
priority: normal
severity: normal
status: open
title: descriptor protocol documentation has two different definitions of "owner" class
versions: Python 2.7
Added file: http://bugs.python.org/file20160/descriptor.py.doctest

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 02:33:04 2010
From: report at bugs.python.org (ipatrol)
Date: Sun, 26 Dec 2010 01:33:04 +0000
Subject: [New-bugs-announce] [issue10772] Several actions for argparse
	arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>


New submission from ipatrol :

I actually noticed this while trying to free the -h option for my program. The actions not mentioned are count, help, and parsers. Also for nargs, '...' and 'A...' are not documented either in the Sphinx docs or the leading docstring for the Action class.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 124654
nosy: docs at python, ipatrol
priority: normal
severity: normal
status: open
title: Several actions for argparse arguments missing from docs
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 18:27:44 2010
From: report at bugs.python.org (Thorsten Behrens)
Date: Sun, 26 Dec 2010 17:27:44 +0000
Subject: [New-bugs-announce] [issue10773] "Building C and C++ Extensions on
	Windows" documentation	shows 2.x way of initializing module
In-Reply-To: <1293384464.17.0.166913159604.issue10773@psf.upfronthosting.co.za>
Message-ID: <1293384464.17.0.166913159604.issue10773@psf.upfronthosting.co.za>


New submission from Thorsten Behrens :

The documentation titled "Building C and C++ Extensions on Windows" at http://docs.python.org/py3k/extending/windows.html shows a Python 2.x way of handling static type object initializers, to whit:

>>
If your module creates a new type, you may have trouble with this line:

PyVarObject_HEAD_INIT(&PyType_Type, 0)

Static type object initializers in extension modules may cause compiles to fail with an error message like ?initializer not a constant?. This shows up when building DLL under MSVC. Change it to:

PyVarObject_HEAD_INIT(NULL, 0)

and add the following to the module initialization function:

MyObject_Type.ob_type = &PyType_Type;

>>

That last line will not function in Python 3.x. However, PyType_Ready will fill in the ob_type field if it is empty, if I understand PyType_Ready correctly. Therefore, the last few lines of this documentation snippet can become:

>>
and add the following to the module initialization function:

if (PyType_Ready(&MyObject_Type) < 0)
    return NULL;
>>

----------
assignee: docs at python
components: Documentation
messages: 124667
nosy: docs at python, thorsten.behrens
priority: normal
severity: normal
status: open
title: "Building C and C++ Extensions on Windows" documentation shows 2.x way of initializing module
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 18:51:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 17:51:56 +0000
Subject: [New-bugs-announce] [issue10774] test_logging leaks temp files
In-Reply-To: <1293385916.1.0.162939898354.issue10774@psf.upfronthosting.co.za>
Message-ID: <1293385916.1.0.162939898354.issue10774@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

After a test_logging run in 3.2, I get stray files in $TMP.  I think some test is not using the right mixin or addCleanup or tearDown.

Less importantly, some recently added docstrings produce unwanted output on the console (the method name is clear enough, the redundant docstring is redundant); attached output turns them into comments.

----------
assignee: vinay.sajip
components: Tests
files: test_logging-nits.diff
keywords: patch
messages: 124669
nosy: eric.araujo, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging leaks temp files
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20168/test_logging-nits.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 20:19:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Dec 2010 19:19:03 +0000
Subject: [New-bugs-announce] [issue10775] assertRaises as a context manager
	should accept a 'msg'	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>


New submission from R. David Murray :

assertRaises used as a method can't take a msg keyword argument because all args and keywords are passed to the callable.  But in context manager form it could, and this can be useful.  See, for example, issue 3583.

----------
keywords: easy
messages: 124675
nosy: michael.foord, r.david.murray, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: assertRaises as a context manager should accept a 'msg' keyword argument.
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 00:14:22 2010
From: report at bugs.python.org (Aaron Masover)
Date: Sun, 26 Dec 2010 23:14:22 +0000
Subject: [New-bugs-announce] [issue10776] os.utime returns an error on
	NTFS-3G partition
In-Reply-To: <1293405262.1.0.932340163478.issue10776@psf.upfronthosting.co.za>
Message-ID: <1293405262.1.0.932340163478.issue10776@psf.upfronthosting.co.za>


New submission from Aaron Masover :

I'm working with Anki (http://ankisrs.net/) on a linux NTFS-3G partition. Anki requires access to modification times in order to handle its backup files. This works fine on my ext3 partition, but on an NTFS partition accessed with NTFS-3G an error is returned:

youlun at yinghuochong:/storage/??/anki/decks$ python -c 'import shutil,os; shutil.copyfile(u"\u6f22\u5b57.anki", "new.anki"); os.utime("new.anki", None)'
youlun at yinghuochong:/storage/??/anki/decks$ python -c 'import shutil,os; shutil.copyfile(u"\u6f22\u5b57.anki", "new.anki"); os.utime("new.anki", (1293402264,1293402264))'
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 1] Operation not permitted: 'new.anki'

Note that passing numbers into os.utime returns an error.

----------
components: IO
messages: 124684
nosy: Aaron.Masover
priority: normal
severity: normal
status: open
title: os.utime returns an error on NTFS-3G partition
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 01:12:09 2010
From: report at bugs.python.org (Peter)
Date: Mon, 27 Dec 2010 00:12:09 +0000
Subject: [New-bugs-announce] [issue10777] xml.etree.register_namespace
	dictionary changed size	during iteration
In-Reply-To: <1293408729.9.0.0323219588466.issue10777@psf.upfronthosting.co.za>
Message-ID: <1293408729.9.0.0323219588466.issue10777@psf.upfronthosting.co.za>


New submission from Peter :

The following was found testing the Biopython unit tests (latest code from git) against Python 3.2 beta 2 (compiled from source on 64 bit Linux Ubuntu). Reduced test case:

$ python3.2
Python 3.2b2 (r32b2:87398, Dec 26 2010, 19:01:30) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree import ElementTree
>>> ElementTree.register_namespace("xs", "http://www.w3.org/2001/XMLSchema")
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/peterjc/lib/python3.2/xml/etree/ElementTree.py", line 1071, in register_namespace
    for k, v in _namespace_map.items():
RuntimeError: dictionary changed size during iteration


Suggested fix, replace this:

def register_namespace(prefix, uri):
    if re.match("ns\d+$", prefix):
        raise ValueError("Prefix format reserved for internal use")
    for k, v in _namespace_map.items():
        if k == uri or v == prefix:
            del _namespace_map[k]
    _namespace_map[uri] = prefix


with something like this:

def register_namespace(prefix, uri):
    if re.match("ns\d+$", prefix):
        raise ValueError("Prefix format reserved for internal use")
    for k, v in list(_namespace_map.items()):
        if k == uri or v == prefix:
            del _namespace_map[k]
    _namespace_map[uri] = prefix


Note that cElementTree seems to be OK.

Note that Python 3.1 was not affected as it didn't even have register_namespace,

$ python3
Python 3.1.2 (r312:79147, Sep 27 2010, 09:57:50) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree import ElementTree
>>> ElementTree.register_namespace("xs", "http://www.w3.org/2001/XMLSchema")
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'register_namespace'

----------
components: XML
messages: 124688
nosy: maubp
priority: normal
severity: normal
status: open
title: xml.etree.register_namespace dictionary changed size during iteration
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 02:57:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 01:57:03 +0000
Subject: [New-bugs-announce] [issue10778] decoding_fgets() (tokenizer.c)
	decodes the filename from	the wrong encoding
In-Reply-To: <1293415023.66.0.544290735249.issue10778@psf.upfronthosting.co.za>
Message-ID: <1293415023.66.0.544290735249.issue10778@psf.upfronthosting.co.za>


New submission from STINNER Victor :

decoding_fgets() decodes the input filename from UTF-8 whereas the filename is encoded to the filesystem encoding. PyUnicode_DecodeFSDefault() should be used.

decoding_fgets() raises a SyntaxError("Non-UTF-8 code starting with '\xHH' in file xxx on line xxx, but no encoding declared; ...").

indenterror() (inconsistent use of tabs and spaces in indentation) and

----------
components: Interpreter Core, Unicode
messages: 124693
nosy: haypo
priority: normal
severity: normal
status: open
title: decoding_fgets() (tokenizer.c) decodes the filename from the wrong encoding
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 03:05:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 02:05:48 +0000
Subject: [New-bugs-announce] [issue10779] Change filename encoding to FS
	encoding in	PyErr_WarnExplicit()
In-Reply-To: <1293415548.91.0.0358465969488.issue10779@psf.upfronthosting.co.za>
Message-ID: <1293415548.91.0.0358465969488.issue10779@psf.upfronthosting.co.za>


New submission from STINNER Victor :

PyErr_WarnExplicit() expects a filename encoded to UTF-8. This function is only called twice in the Python interpreter: compiler_assert() (with "assertion is always true, perhaps remove parentheses?") and symtable_warn() (eg. with "name 'xxx' is assigned to before global declaration"), and both functions pass a filename encoded to the filesystem encoding.

PyErr_WarnExplicit() should use the filesystem encoding instead of UTF-8 to decode the filename. I already did the same change in issue #9713 and #10114 (r85569).

Attached patch fixes this issue.

See also issue #10778 (decoding_fgets() (tokenizer.c) decodes the filename from the wrong encoding).

----------
components: Interpreter Core, Unicode
files: warnexplicit_fsencoding.patch
keywords: patch
messages: 124694
nosy: haypo
priority: normal
severity: normal
status: open
title: Change filename encoding to FS encoding in PyErr_WarnExplicit()
versions: Python 3.2
Added file: http://bugs.python.org/file20170/warnexplicit_fsencoding.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 03:30:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 02:30:43 +0000
Subject: [New-bugs-announce] [issue10780] Fix filename encoding
	in	PyErr_SetFromWindowsErrWithFilename()
	(and	PyErr_SetExcFromWindowsErrWithFilename())
In-Reply-To: <1293417043.69.0.869420684931.issue10780@psf.upfronthosting.co.za>
Message-ID: <1293417043.69.0.869420684931.issue10780@psf.upfronthosting.co.za>


New submission from STINNER Victor :

PyErr_SetFromWindowsErrWithFilename() expects a filename encoded to UTF-8. It is called by win32_error() function of the nt (posix) module, and win32_error() is called on an error in the bytes implementation of a function (if the argument is a byte string, not an Unicode string). But on Windows, bytes filenames are encoded to the ANSI code page, not to UTF-8.

PyErr_SetExcFromWindowsErrWithFilename() expects also a filename encoded to UTF-8. It is not used in Python core, but I think that it should be fixed too.

See also #10779 (and #9713 and #10114).

----------
components: Interpreter Core, Unicode, Windows
messages: 124697
nosy: haypo
priority: normal
severity: normal
status: open
title: Fix filename encoding in PyErr_SetFromWindowsErrWithFilename() (and PyErr_SetExcFromWindowsErrWithFilename())
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 16:36:13 2010
From: report at bugs.python.org (Goffi)
Date: Mon, 27 Dec 2010 15:36:13 +0000
Subject: [New-bugs-announce] [issue10781] minidom Node.writexml method
	doesn't manage encoding	parameter correctly
In-Reply-To: <1293464173.75.0.623330823257.issue10781@psf.upfronthosting.co.za>
Message-ID: <1293464173.75.0.623330823257.issue10781@psf.upfronthosting.co.za>


New submission from Goffi :

G'day,

While translating my software to french, I realised that minidom's writexml method doesn't handle "encoding" parameter correctly: it changes the header of the resulting xml, but not the encoding itself (which it should according to the documentation: http://docs.python.org/library/xml.dom.minidom.html).

The given example doesn't work with writexml; but if I save by myself using the toxml's encoding parameter (like in the commented line), it works as expected.

Anyway, it would be better if minidom could handle unicode string directly.

----------
components: XML
files: test_minidom.py
messages: 124709
nosy: Goffi
priority: normal
severity: normal
status: open
title: minidom Node.writexml method doesn't manage encoding parameter correctly
versions: Python 2.6
Added file: http://bugs.python.org/file20174/test_minidom.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 19:09:36 2010
From: report at bugs.python.org (Ben Gamari)
Date: Mon, 27 Dec 2010 18:09:36 +0000
Subject: [New-bugs-announce] [issue10782] Not possible to cross-compile due
	to poor detection of	%lld support in printf
In-Reply-To: <1293473376.4.0.265613686073.issue10782@psf.upfronthosting.co.za>
Message-ID: <1293473376.4.0.265613686073.issue10782@psf.upfronthosting.co.za>


New submission from Ben Gamari :

Configure.in assumes that %lld is not supported by printf if cross-compiling. This causes build errors in pyport.h,

In file included from Include/Python.h:58:0,
                 from Parser/parser.c:8:
Include/pyport.h:243:13: error: #error "This platform's pyconfig.h needs to define PY_FORMAT_LONG_LONG"
...

What is one supposed to do about this short of changing the configure script to assume support by default.

----------
components: Build
messages: 124722
nosy: bgamari
priority: normal
severity: normal
status: open
title: Not possible to cross-compile due to poor detection of %lld support in printf
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 21:09:56 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 27 Dec 2010 20:09:56 +0000
Subject: [New-bugs-announce] [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>


New submission from David Beazley :

Is the struct.pack() function supposed to automatically encode Unicode strings into binary?  For example:

>>> struct.pack("10s","Jalape\u00f1o")
b'Jalape\xc3\xb1o\x00'
>>>

This is Python 3.2b1.

----------
components: Library (Lib)
messages: 124727
nosy: dabeaz
priority: normal
severity: normal
status: open
title: struct.pack() and Unicode strings
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 02:46:50 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 28 Dec 2010 01:46:50 +0000
Subject: [New-bugs-announce] [issue10784] os.getpriority() and
	os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' :

After having implemented a similar thing in psutil ( http://code.google.com/p/psutil/issues/detail?id=142 ) I decided to contribute a patch for Python which exposes getpriority() and setpriority() POSIX calls in the os module.

They can be used to get/set process niceness/priority in a fashion similar to os.nice() but extended to *all* processes instead of just os.getpid():
http://linux.die.net/man/2/setpriority

----------
assignee: giampaolo.rodola
keywords: patch
messages: 124751
nosy: giampaolo.rodola, loewis, pitrou
priority: normal
severity: normal
status: open
title: os.getpriority() and os.setpriority()
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 03:40:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 02:40:22 +0000
Subject: [New-bugs-announce] [issue10785] parser: store the filename as an
	unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>


New submission from STINNER Victor :

The Python parser stores the filename as a byte string. But it decodes the filename on error because most Python functions now use unicode strings. Instead of decoding the filename at error, which may raise a new error, I propose to decode the filename on the creation of the parser object and only store the filename as unicode.

This issue would prepare the last part of the full unicode support (#3080).

----------
components: Interpreter Core, Unicode
files: parse_filename_obj.patch
keywords: patch
messages: 124755
nosy: haypo
priority: normal
severity: normal
status: open
title: parser: store the filename as an unicode object
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20179/parse_filename_obj.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 07:57:59 2010
From: report at bugs.python.org (cooyeah)
Date: Tue, 28 Dec 2010 06:57:59 +0000
Subject: [New-bugs-announce] [issue10786] unittest.TextTextRunner does not
	respect redirected	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>


New submission from cooyeah :

The constructor of TextTestRunner class looks like:
def __init__(self, stream=sys.stderr, descriptions=1, verbosity=1)

Since the default parameter is evaluated only once, if sys.stderr is redirected later, the test would still use the old stderr when it was first initialized.

----------
components: Tests
messages: 124764
nosy: cooyeah
priority: normal
severity: normal
status: open
title: unittest.TextTextRunner does not respect redirected stderr
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 17:48:38 2010
From: report at bugs.python.org (David Kremer)
Date: Tue, 28 Dec 2010 16:48:38 +0000
Subject: [New-bugs-announce] [issue10787] [random.gammavariate] Add the
	expression of the	distribution in a comprehensive form for
	random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>


New submission from David Kremer :

Could you please add the exact form of the distribution, because it's rather confusing in the current form.

In this url, the role of k and theta is precised with a formula :
[http://tinyurl.com/24jxfrk]*

It seems that in 
[http://docs.python.org/library/random.html#random.gammavariate] , alpha is playing the role of k and beta is playing the role of theta.

But it's still not clear, because one can confuse beta with 1/beta and vice et versa, like there is two usual representation for the gamma distribution [http://en.wikipedia.org/wiki/Gamma_distribution]

[http://docs.scipy.org/doc/numpy-1.5.x/reference/generated/numpy.random.gamma.html#numpy.random.gamma]*

Please update the documentation to avoid this ambiguity.

I provide an indicative patch which is updating the doc string in random.py

----------
assignee: docs at python
components: Documentation
files: patch_documentation_random.py.diff
keywords: patch
messages: 124803
nosy: David.Kremer, docs at python
priority: normal
severity: normal
status: open
title: [random.gammavariate] Add the expression of the distribution in a comprehensive form for random.gammavariate
versions: Python 2.7
Added file: http://bugs.python.org/file20181/patch_documentation_random.py.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 18:36:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Dec 2010 17:36:15 +0000
Subject: [New-bugs-announce] [issue10788] test_logging failure
In-Reply-To: <1293557775.34.0.401807724335.issue10788@psf.upfronthosting.co.za>
Message-ID: <1293557775.34.0.401807724335.issue10788@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

This on the Windows Server 2008 buildbot:

(http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x)

Re-running test 'test_logging' in verbose mode
test_flat (test.test_logging.BuiltinLevelsTest) ... FAIL
test_nested_explicit (test.test_logging.BuiltinLevelsTest) ... FAIL
test_nested_inherited (test.test_logging.BuiltinLevelsTest) ... FAIL
test_nested_with_virtual_parent (test.test_logging.BuiltinLevelsTest) ... FAIL
test_callable_filter (test.test_logging.BasicFilterTest) ... FAIL
test_filter (test.test_logging.BasicFilterTest) ... FAIL
test_handler_filter (test.test_logging.CustomLevelsAndFiltersTest) ... FAIL
test_logger_filter (test.test_logging.CustomLevelsAndFiltersTest) ... FAIL
test_specific_filters (test.test_logging.CustomLevelsAndFiltersTest) ... FAIL
test_flush (test.test_logging.MemoryHandlerTest) ... FAIL
test_config0_ok (test.test_logging.ConfigFileTest) ... FAIL
test_config1_ok (test.test_logging.ConfigFileTest) ... FAIL
test_config2_failure (test.test_logging.ConfigFileTest) ... FAIL
test_config3_failure (test.test_logging.ConfigFileTest) ... FAIL
test_config4_ok (test.test_logging.ConfigFileTest) ... FAIL
test_config5_ok (test.test_logging.ConfigFileTest) ... FAIL
test_config6_ok (test.test_logging.ConfigFileTest) ... FAIL
test_output (test.test_logging.SocketHandlerTest) ... FAIL
test_persistent_loggers (test.test_logging.MemoryTest) ... FAIL
test_encoding_cyrillic_unicode (test.test_logging.EncodingTest) ... FAIL
test_encoding_plain_file (test.test_logging.EncodingTest) ... FAIL
test_warnings (test.test_logging.WarningsTest) ... FAIL
test_config0_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config11_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config12_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config13_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config1_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config2_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config2a_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config2b_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config3_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config4_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config4a_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config5_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config6_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config7_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config_10_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config_8_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config_9_ok (test.test_logging.ConfigDictTest) ... FAIL
test_listen_config_10_ok (test.test_logging.ConfigDictTest) ... FAIL
test_listen_config_1_ok (test.test_logging.ConfigDictTest) ... FAIL
test_manager_loggerclass (test.test_logging.ManagerTest) ... FAIL
test_braces (test.test_logging.FormatterTest) ... ok
test_dollars (test.test_logging.FormatterTest) ... ok
test_percent (test.test_logging.FormatterTest) ... ok
test_logrecord_class (test.test_logging.LogRecordFactoryTest) ... FAIL
test_child_loggers (test.test_logging.ChildLoggerTest) ... FAIL
test_queue_handler (test.test_logging.QueueHandlerTest) ... FAIL
test_file_created (test.test_logging.RotatingFileHandlerTest) ... FAIL
test_rollover_filenames (test.test_logging.RotatingFileHandlerTest) ... FAIL
test_should_not_rollover (test.test_logging.RotatingFileHandlerTest) ... FAIL
test_should_rollover (test.test_logging.RotatingFileHandlerTest) ... FAIL
test_last_resort (test.test_logging.LastResortTest) ... FAIL

======================================================================
FAIL: test_flat (test.test_logging.BuiltinLevelsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_nested_explicit (test.test_logging.BuiltinLevelsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_nested_inherited (test.test_logging.BuiltinLevelsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_nested_with_virtual_parent (test.test_logging.BuiltinLevelsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_callable_filter (test.test_logging.BasicFilterTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_filter (test.test_logging.BasicFilterTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_handler_filter (test.test_logging.CustomLevelsAndFiltersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 411, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_logger_filter (test.test_logging.CustomLevelsAndFiltersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 411, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_specific_filters (test.test_logging.CustomLevelsAndFiltersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 411, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_flush (test.test_logging.MemoryHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 500, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config0_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config1_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config2_failure (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config3_failure (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config4_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config5_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config6_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_output (test.test_logging.SocketHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 822, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_persistent_loggers (test.test_logging.MemoryTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 868, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_encoding_cyrillic_unicode (test.test_logging.EncodingTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_encoding_plain_file (test.test_logging.EncodingTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_warnings (test.test_logging.WarningsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config0_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config11_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config12_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config13_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config1_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config2_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config2a_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config2b_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config3_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config4_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config4a_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config5_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config6_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config7_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config_10_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================Warning -- logging._handlerList was modified by test_logging
test test_logging failed -- multiple errors occurred

FAIL: test_config_8_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config_9_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_listen_config_10_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_listen_config_1_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_manager_loggerclass (test.test_logging.ManagerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_logrecord_class (test.test_logging.LogRecordFactoryTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1826, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_child_loggers (test.test_logging.ChildLoggerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_queue_handler (test.test_logging.QueueHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1851, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_file_created (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1977, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_rollover_filenames (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1977, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_should_not_rollover (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1977, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_should_rollover (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1977, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_last_resort (test.test_logging.LastResortTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

----------------------------------------------------------------------

----------
assignee: vinay.sajip
components: Tests
messages: 124808
nosy: brian.curtin, georg.brandl, pitrou, vinay.sajip
priority: release blocker
severity: normal
status: open
title: test_logging failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 29 18:41:18 2010
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Wed, 29 Dec 2010 17:41:18 +0000
Subject: [New-bugs-announce] [issue10789] Lock.acquire documentation is
	misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>


New submission from Jyrki Pulliainen :

In threading module, the Lock.acquire documentation is misleading. The signature suggests that the blocking can be given as a keyword argument but that would lead to an TypeError, as thread.lock.acquire does not accept keyword arguments.

The signature in documentation should be formatted as in thread.lock.acquire.

----------
assignee: docs at python
components: Documentation
messages: 124861
nosy: Jyrki.Pulliainen, docs at python
priority: normal
severity: normal
status: open
title: Lock.acquire documentation is misleading
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 29 19:38:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 18:38:23 +0000
Subject: [New-bugs-announce] [issue10790] Header.append's charset logic is
	bogus, 'shift_jis' and "euc_jp' don't work as charsets
In-Reply-To: <1293647903.09.0.559364426725.issue10790@psf.upfronthosting.co.za>
Message-ID: <1293647903.09.0.559364426725.issue10790@psf.upfronthosting.co.za>


New submission from R. David Murray :

Working on issue 10686, I've discovered that the logic for charset conversion in email.header.Header.append is bogus.  It happens to work for most charsets because for most charsets the input codec and the output codec are the same.  For shift_jis and euc_jp, however, this is not the case.

The attached patch fixes the logic and provides a test.

The logic is still not quite correct, since the 'errors' parameter should not be passed to the 'encode' test call, because the errors parameter is not passed to the encode call when the actual encoding is done in the Header.encode method.  If that call were fixed in this patch, one of the email tests would fail that currently passes.  However, if a 'Header.encode' call were made in that test, the encode call would fail.  Fixing that will require resolving issue 10686.

----------
assignee: r.david.murray
files: header_append.patch
keywords: patch
messages: 124865
nosy: r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Header.append's charset logic is bogus, 'shift_jis' and "euc_jp' don't work as charsets
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20188/header_append.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 29 20:53:54 2010
From: report at bugs.python.org (David Beazley)
Date: Wed, 29 Dec 2010 19:53:54 +0000
Subject: [New-bugs-announce] [issue10791] Wrapping TextIOWrapper around gzip
	files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>


New submission from David Beazley :

Is something like this supposed to work:

>>> import gzip
>>> import io
>>> f = io.TextIOWrapper(gzip.open("foo.gz"),encoding='ascii'))
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: readable

In a nutshell--reading a .gz file as text.

----------
messages: 124870
nosy: dabeaz
priority: normal
severity: normal
status: open
title: Wrapping TextIOWrapper around gzip files
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 29 21:01:42 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Dec 2010 20:01:42 +0000
Subject: [New-bugs-announce] [issue10792] Compile() and 'Windows/Mac
	newlines'
In-Reply-To: <1293652902.05.0.92926379276.issue10792@psf.upfronthosting.co.za>
Message-ID: <1293652902.05.0.92926379276.issue10792@psf.upfronthosting.co.za>


New submission from Terry J. Reedy :

In python-list thread "Does Python 3.1 accept \r\n in compile()?"
jmfauth notes that
compile('print(999)\r\n', '', 'exec')
works in 2.7 but not 3.1 (and 3.2 not checked) because 3.1 sees '\r' as
SyntaxError.

I started to respond that this is part of Py3 cleanup with newlines converted on input and back-compatibility with ancient Python not needed. Then I saw in 3.2 manual

"Changed in version 3.2: Allowed use of Windows and Mac newlines. ..."

However, above gives same error. Should "Allowed use of Windows and Mac newlines." be deleted? What else could it mean other than use of '\r' or '\r\n'?

The note was added in r76232 which is a forward port of r76230
"fix several compile() issues by translating newlines in the tokenizer"
by B. Peterson. Is Windows/Mac part just not applicable to 3.2?

----------
assignee: benjamin.peterson
components: Documentation
messages: 124872
nosy: benjamin.peterson, terry.reedy
priority: normal
severity: normal
status: open
title: Compile() and 'Windows/Mac newlines'
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 01:24:32 2010
From: report at bugs.python.org (Thorsten Behrens)
Date: Thu, 30 Dec 2010 00:24:32 +0000
Subject: [New-bugs-announce] [issue10793] hashlib.hash.digest()
	documentation incorrect re return	type
In-Reply-To: <1293668672.17.0.948063108001.issue10793@psf.upfronthosting.co.za>
Message-ID: <1293668672.17.0.948063108001.issue10793@psf.upfronthosting.co.za>


New submission from Thorsten Behrens :

The documentation for hashlib.hash.digest() states that digest() will "[r]eturn the digest of the data passed to the update() method so far. This is a bytes array of size digest_size[...]".

The returned object is of class 'bytes', not 'bytearray'. Documentation should reflect this.

----------
assignee: docs at python
components: Documentation
messages: 124892
nosy: docs at python, thorsten.behrens
priority: normal
severity: normal
status: open
title: hashlib.hash.digest() documentation incorrect re return type
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 01:51:27 2010
From: report at bugs.python.org (Mihai Rusu)
Date: Thu, 30 Dec 2010 00:51:27 +0000
Subject: [New-bugs-announce] [issue10794] Infinite recursion while garbage
	collecting loops	indefinitely
In-Reply-To: <1293670287.34.0.585233901325.issue10794@psf.upfronthosting.co.za>
Message-ID: <1293670287.34.0.585233901325.issue10794@psf.upfronthosting.co.za>


New submission from Mihai Rusu :

Hi

While working on some Python code I stumbled on a situation where the Python process seems to hang indefinitely. Further debugging points to the following conclusion: if there is a class that somehow manages to run into an infinite recursion (properly detected by Python which raises the corresponding RuntimeError) while Python is doing garbage collection (so the infinite recursion has to be triggered from __del__ somehow) then Python hangs into an infinite loop apparently retrying to call that __del__ indefinitely. The described behavior happens ONLY when an infinite recursion is detected (ie if I raise my own "RuntimeError" from __del__ then it just logs it and exits).

Program showing the problem:

class A(object):
  def __init__(self):
    raise Exception('init error')
    self.m = 'Hello world'

  def __del__(self):
    #raise RuntimeError('my runtime error')
    self.__del__()

def func():
  h = A()

func()

$ python pyloop.py

Traceback (most recent call last):
  File "pyloop.py", line 15, in 
    func()
  File "pyloop.py", line 13, in func
    h = A()
  File "pyloop.py", line 5, in __init__
    raise Exception('init error')
Exception: init error
Exception RuntimeError: 'maximum recursion depth exceeded' in > ignored
Exception RuntimeError: 'maximum recursion depth exceeded' in > ignored
Exception RuntimeError: 'maximum recursion depth exceeded' in > ignored
Exception RuntimeError: 'maximum recursion depth exceeded' in > ignored
...

If I uncomment the line raising my RuntimeError instance from __del__ then the exception is logged once and the program exits (as expected).

Please help, thanks.

----------
components: Interpreter Core
messages: 124896
nosy: Mihai.Rusu, gregory.p.smith
priority: normal
severity: normal
status: open
title: Infinite recursion while garbage collecting loops indefinitely
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 02:42:40 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Thu, 30 Dec 2010 01:42:40 +0000
Subject: [New-bugs-announce] [issue10795] standard library do not use ssl as
	recommended
In-Reply-To: <1293673360.75.0.570895204435.issue10795@psf.upfronthosting.co.za>
Message-ID: <1293673360.75.0.570895204435.issue10795@psf.upfronthosting.co.za>


New submission from Mads Kiilerich :

As discussed on issue1589 it is now possible to create decent ssl connections with the ssl module - assuming ca_certs is specified and it is checked that the certificates matches.

The standard library do however neither do that nor make it possible to do it in the places where it uses ssl. For example smtplib starttls do not make it possible at all to specify ca_certs.

I suggest all uses of ssl should be reviewed - and fixed if necessary. The documentation should also be improved to make it clear what is necessary to create "secure" connections.

----------
components: Library (Lib)
messages: 124898
nosy: kiilerix, pitrou
priority: normal
severity: normal
status: open
title: standard library do not use ssl as recommended
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 14:08:09 2010
From: report at bugs.python.org (rheise)
Date: Thu, 30 Dec 2010 13:08:09 +0000
Subject: [New-bugs-announce] [issue10796] readline completion flaw
In-Reply-To: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za>
Message-ID: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za>


New submission from rheise :

Python's readline library generates out of the choices provided by a custom completion function the wrong terminal input. Say, the completion function suggests 'foobar' and 'foobaz' as matching completion strings, readline should produce the characters 'fooba' to prompt and await further interaction by the user. 
This is the intended behaviour of readline and this works in Python as well. However this does nod work anymore as soon, as the suggestion 
list contains dashes `-' as input argument. 

A working as supposed example:

>>> import readline
>>> 
>>> def complete(text, state):
...   if (state == 0):
...     return "abc"
...   if (state == 1):
...     return "ade"
...   else:
...     return None
... 
>>> 
>>> readline.parse_and_bind("Tab: complete")
>>> readline.set_completer(complete)
>>> 
>>> raw_input()
a
abc  ade  
a
'a'
>>> 

remark: I entered a and hit tab. readline produces abc/ade as valid choices, stopping at the first ambiguous character. Now consider the following example:

>>> import readline
>>> 
>>> def complete(text, state):
...   if (state == 0):
...     return "a-bc"
...   if (state == 1):
...     return "a-de"
...   else:
...     return None
... 
>>> 
>>> readline.parse_and_bind("Tab: complete")
>>> readline.set_completer(complete)
>>> 
>>> raw_input()
a-a-a-
'a-a-a-'
>>> 

The intended behaviour is the very same as for the first example. Readline should produce 'a-' and offer a-bc and a-de as valid choices. Instead it produces an additional a- for every time I hit tab. 

Same for Python3.1:

$ python3.1
Python 3.1.2 (release31-maint, Sep 26 2010, 13:51:01) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> 
>>> def complete(text, state):
...   if (state == 0):
...     return "a-bc"
...   if (state == 1):
...     return "a-de"
...   else:
...     return None
... 
>>> 
>>> readline.parse_and_bind("Tab: complete")
>>> readline.set_completer(complete)
>>> 
>>> input()
a-a-a-a-a-
'a-a-a-a-a-'
>>> 


Other programming languages falling back to the GNU C-readline library don't have this problem. Consider the roughly equivalent example in Perl which works as expected:

use Term::ReadLine;

sub complete
{
        my ($text, $state) = @_;
        if ($state == 0)
        {
                return "a-bc";
        }
        elsif ($state == 1)
        {
                return "a-cd";
        }
        else
        {
                return undef;
        }
}

my $term = new Term::ReadLine 'sample';
my $attribs = $term->Attribs;

$term->parse_and_bind("Tab: complete");
$attribs->{completion_entry_function} = \&complete;

$term->readline();



Running it:

$ perl rl 
a-
a-bc  a-cd  
a-

----------
components: Library (Lib)
messages: 124917
nosy: rheise
priority: normal
severity: normal
status: open
title: readline completion flaw
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 21:09:34 2010
From: report at bugs.python.org (Miso.Kopera)
Date: Thu, 30 Dec 2010 20:09:34 +0000
Subject: [New-bugs-announce] [issue10797] Wrong detection of lines in
	readlines() function
In-Reply-To: <1293739774.28.0.868626171836.issue10797@psf.upfronthosting.co.za>
Message-ID: <1293739774.28.0.868626171836.issue10797@psf.upfronthosting.co.za>


New submission from Miso.Kopera :

bug in "file.readlines()" function. It doesn't detect end of the line when line is ending only with 0x0D byte. In python3.1 it works fine (as I expect). File in attachment should has 6 lines not only 1 as python2.7 returns.

----------
components: None
files: testFile
messages: 124932
nosy: Miso.Kopera
priority: normal
severity: normal
status: open
title: Wrong detection of lines in readlines() function
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20197/testFile

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 21:14:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Dec 2010 20:14:14 +0000
Subject: [New-bugs-announce] [issue10798] test_concurrent_futures fails on
	FreeBSD
In-Reply-To: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>
Message-ID: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>


New submission from Martin v. L?wis :

This is similar to #10348, but has a different scope; the attached patch disables the ProcessPoolExecutor if the system has too few POSIX semaphores.

To keep support for the ThreadPoolExecutor, I had the test cases stop using multiprocessing.Event in the threaded test cases. Unfortunately, this had two side effect that I think indicate a bug elsewhere: 

1. ThreadPoolWaitTests.test_all_completed_some_already_completed hangs
2. (sometimes) ThreadPoolWaitTests.test_first_exception fails:

    self.assertEqual(set([future1, future2]), finished)
AssertionError: Items in the first set but not the second:


I haven't been able to determine yet why it hangs. If the hanging test is disabled, the tests pass on both Linux and FreeBSD 7.3.

----------
files: fbsd.diff
keywords: patch
messages: 124933
nosy: bquinlan, loewis
priority: normal
severity: normal
status: open
title: test_concurrent_futures fails on FreeBSD
Added file: http://bugs.python.org/file20198/fbsd.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 31 04:47:31 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 03:47:31 +0000
Subject: [New-bugs-announce] [issue10799] Improve webbrowser.open doc (and,
	someday, behavior?)
In-Reply-To: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>
Message-ID: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>


New submission from Terry J. Reedy :

webbrowser.open (and two aliases):

1. document return value, which seems to be: True if a browser tab or window is opened, regardless of whether or not the url is found; False otherwise.

2. document that (on Windows, at least) the default browser only gets used if a non .htm(l) url starts with 'www' or 'http:'.

This is true because os.startfile(url) apparently only works if above is true, as required for the Start/Run box to recognize an entry as a url.

In particular, I have Firefox as default and 'www.google.com' and 'http://bugs.python.org' get opened in Firefox (new tab as requested). However, 'google.com' and 'bugs.python.org' open with IE after some delay. [Start/run either opens with Firefox or reports 'cannot find'.]
-----

In the longer run, what I would really like is for webbrowser to be better at using the default or finding executables.

I thought of adding 'http://' if not present but that would disable opening files in a file browser.

I suspect there is a registry entry but do not know what it is. That would also pick up new browswers like Chrome.

It seems to me that the current behavior is a 'limitation' in this code:

    # Detect some common Windows browsers, fallback to IE
    iexplore = os.path.join(os.environ.get("PROGRAMFILES", "C:\\Program Files"),
                            "Internet Explorer\\IEXPLORE.EXE")
    for browser in ("firefox", "firebird", "seamonkey", "mozilla",
                    "netscape", "opera", iexplore):
        if _iscommand(browser):
            register(browser, None, BackgroundBrowser(browser))

Firefox is not being recognized as a command because _iscommand('firefox') does not not see firefox.exe as an executable because it only checks _isexecutable() in the hodgepodge list of paths in PATH. At one time (but no longer), executables were ofter put in c:/windows, which by default is in PATH.

Since you hardcoded the default real path for iexplore (C:\\Program Files\\"Internet Explorer\\IEXPLORE.EXE"), you could do the same for other programs: 

firefox = os.path.join(os.environ.get("PROGRAMFILES", "C:\\Program Files"), "Mozilla Firefox\\firefox.exe")

----------
assignee: georg.brandl
components: Library (Lib)
messages: 124949
nosy: georg.brandl, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve webbrowser.open doc (and, someday, behavior?)
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 31 08:35:48 2010
From: report at bugs.python.org (bugs-python@vendor.thewrittenword.com)
Date: Fri, 31 Dec 2010 07:35:48 +0000
Subject: [New-bugs-announce] [issue10800] libffi build failure on HP-UX 11/PA
In-Reply-To: <1293780948.24.0.107395792812.issue10800@psf.upfronthosting.co.za>
Message-ID: <1293780948.24.0.107395792812.issue10800@psf.upfronthosting.co.za>


New submission from bugs-python at vendor.thewrittenword.com :

Python 3.1.3 fails to build on HP-UX/PA:
In file included from /opt/build/Python-3.1.3/Modules/_ctypes/libffi/src/dlmalloc.c:1156:
/opt/TWWfsw/gcc42/lib/gcc/hppa2.0-hp-hpux11.31/4.2/include/stdlib.h:577: error: redefinition of 'struct mallinfo'

Failed to build these modules:
_ctypes

 on HP-UX has a conflicting definition for struct mallinfo:
#ifndef _STRUCT_MALLINFO
#  define _STRUCT_MALLINFO

  /* structure filled by mallinfo */
  struct mallinfo  {
        int32_t arena;          /* total number of bytes in arena */
        int32_t ordblks;        /* number of ordinary blocks */
        int32_t smblks;         /* number of small blocks */
        int32_t hblks;          /* number of holding blocks */
        int32_t hblkhd;         /* number of bytes in holding block headers */
        int32_t usmblks;        /* number of bytes in small blocks in use */
        int32_t fsmblks;        /* number of bytes in free small blocks */
        int32_t uordblks;       /* number of bytes in ordinary blocks in use */
        int32_t fordblks;       /* number of bytes in free ordinary blocks */
        int32_t keepcost;       /* cost of enabling keep option */
  };    
#endif /* _STRUCT_MALLINFO */

----------
assignee: theller
components: ctypes
messages: 124956
nosy: bugs-python at vendor.thewrittenword.com, theller
priority: normal
severity: normal
status: open
title: libffi build failure on HP-UX 11/PA
type: compile error
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 31 14:38:39 2010
From: report at bugs.python.org (M. Z.)
Date: Fri, 31 Dec 2010 13:38:39 +0000
Subject: [New-bugs-announce] [issue10801] zipfile.ZipFile().extractall()
	header mismatch for	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>


New submission from M. Z. :

Trying to unpack a ZIP file where some packet files contain danish letters results in:

    zipfile.BadZipFile: File name in directory 'filename_with_?o?.txt'
    and header b'filename_with_\x91o\x86.txt' differ.

Using Py 3.2b2 on Win7.

Unpack the attached ZIP file and run the Py script, which will show the problem using the enclosed two ZIP files.

----------
components: Library (Lib)
files: bug_zipfile_extractall.zip
messages: 124964
nosy: M..Z.
priority: normal
severity: normal
status: open
title: zipfile.ZipFile().extractall() header mismatch for non-ASCII characters
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20204/bug_zipfile_extractall.zip

_______________________________________
Python tracker 

_______________________________________





 

%s
%s
%s


%s