From report at bugs.python.org Sat Jun 1 00:22:08 2013 From: report at bugs.python.org (Eric Wieser) Date: Fri, 31 May 2013 22:22:08 +0000 Subject: [New-bugs-announce] [issue18110] Nested set comprehensions in class scope fail Message-ID: <1370038928.9.0.337300237862.issue18110@psf.upfronthosting.co.za> New submission from Eric Wieser: This code: class Sudoku(dict): COLUMNS = [ {(x, y) for y in xrange(9)} for x in xrange(9) ] When run on Python 2.7.5, fails with this traceback: Traceback (most recent call last): File "", line 1, in class Sudoku(object): File "", line 3, in Sudoku {(x, y) for y in xrange(9)} for x in xrange(9) File "", line 3, in {(x, y) for y in xrange(9)} for x in xrange(9) NameError: global name 'x' is not defined Yet `x` is clearly not a global - it's defined in the comprehension. Running the comprehension outside of the class gives no error: >>> [ {(x, y) for y in xrange(9)} for x in xrange(9) ] [set([...]), ...] Nor does using `set`: class Sudoku(dict): COLUMNS = [ set((x, y) for y in xrange(9)) for x in xrange(9) ] ---------- components: Interpreter Core messages: 190420 nosy: Eric.Wieser priority: normal severity: normal status: open title: Nested set comprehensions in class scope fail type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 1 01:21:06 2013 From: report at bugs.python.org (Julian Berman) Date: Fri, 31 May 2013 23:21:06 +0000 Subject: [New-bugs-announce] [issue18111] Add a default argument to min & max Message-ID: <1370042466.03.0.969655883225.issue18111@psf.upfronthosting.co.za> New submission from Julian Berman: This has come up a number of times I'm aware, but no one has ever written a patch for it as far as a quick look uncovered. So here's one (written by Thomas Wouters but with permission to submit). Submitting without tests and docs, but those are incoming when I get a moment. The justification here is mostly related to being able to call min/max on an iterable of unknown length when there's a sensible default (which is usually going to be None, but that's not the default for backwards compat obviously). ---------- components: Interpreter Core messages: 190426 nosy: Julian, twouters priority: normal severity: normal status: open title: Add a default argument to min & max type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 1 01:35:53 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 31 May 2013 23:35:53 +0000 Subject: [New-bugs-announce] [issue18112] PEP 442 implementation Message-ID: <1370043353.45.0.859632508131.issue18112@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: Interpreter Core hgrepos: 194 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: PEP 442 implementation type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 1 04:35:55 2013 From: report at bugs.python.org (Atsuo Ishimoto) Date: Sat, 01 Jun 2013 02:35:55 +0000 Subject: [New-bugs-announce] [issue18113] Memory leak in curses.panel Message-ID: <1370054155.63.0.276234204482.issue18113@psf.upfronthosting.co.za> New submission from Atsuo Ishimoto: Objects associated to the panel with panel.set_userptr() are never DECREF()ed. Attached file is script to reproduce the leak. Confirmed with Python2.7/3.3. ---------- files: userptr-leak.py messages: 190433 nosy: ishimoto priority: normal severity: normal status: open title: Memory leak in curses.panel versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file30438/userptr-leak.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 1 05:13:19 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 01 Jun 2013 03:13:19 +0000 Subject: [New-bugs-announce] [issue18114] Update PyImport_ImportFrozenModuleObject() to use importlib Message-ID: <1370056399.99.0.692031308648.issue18114@psf.upfronthosting.co.za> New submission from Brett Cannon: _imp.init_frozen is not really necessary; you can implement imports entirely using the other frozen-related functions. Because of that it's probably better to simply rewrite PyImport_ImportFrozenModuleObject() to use importlib to make the code easier to maintain and help guarantee consistency with other code. ---------- assignee: brett.cannon components: Interpreter Core messages: 190434 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Update PyImport_ImportFrozenModuleObject() to use importlib type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 1 05:15:34 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 01 Jun 2013 03:15:34 +0000 Subject: [New-bugs-announce] [issue18115] Use importlib.util.module_to_load in all loaders in importlib Message-ID: <1370056534.07.0.17129637302.issue18115@psf.upfronthosting.co.za> New submission from Brett Cannon: BuiltinImporter, FrozenImporter, and ExtensionFileLoader all have their own custom code to manage clearing sys.modules if something goes wrong. Should see if any of them would break if they used importlib.util.module_to_load. And if they would break thanks to any pre-existing module in sys.modules, then add a keyword argument to suppress creating a new module. ---------- assignee: brett.cannon components: Library (Lib) keywords: easy messages: 190435 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Use importlib.util.module_to_load in all loaders in importlib type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 2 01:50:07 2013 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 01 Jun 2013 23:50:07 +0000 Subject: [New-bugs-announce] [issue18116] getpass.getpass() triggers ResourceWarning Message-ID: <1370130607.39.0.486408621645.issue18116@psf.upfronthosting.co.za> New submission from Nikolaus Rath: [0] nikratio at vostro:~/tmp$ cat bugme.py #!python import getpass import warnings warnings.simplefilter('default') getpass.getpass("What's up?") [0] nikratio at vostro:~/tmp$ python3 --version Python 3.3.2 [0] nikratio at vostro:~/tmp$ python3 bugme.py /usr/lib/python3.3/os.py:1043: ResourceWarning: unclosed file <_io.FileIO name=3 mode='rb+'> return io.open(fd, *args, **kwargs) What's up? ---------- components: Library (Lib) messages: 190458 nosy: Nikratio priority: normal severity: normal status: open title: getpass.getpass() triggers ResourceWarning type: resource usage versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 2 10:29:43 2013 From: report at bugs.python.org (Gavan Schneider) Date: Sun, 02 Jun 2013 08:29:43 +0000 Subject: [New-bugs-announce] [issue18117] Missing symlink:Currnet after Mac OS X 3.3.2 package installation Message-ID: <1370161783.39.0.437072519867.issue18117@psf.upfronthosting.co.za> New submission from Gavan Schneider: There is a missing symlink. Context: Installed package: with no apparent problems onto a 'clean' system, i.e., no other python packages other than OS X 10.8.3 defaults. Found the following in /Library/Frameworks/Python.framework: pendari:Python.framework postgres$ ls -las total 24 0 drwxr-xr-x 3 root wheel 204 14 May 06:49 . 0 drwxr-xr-x 8 root wheel 374 2 Jun 17:06 .. 8 lrwxr-xr-x 1 root wheel 24 2 Jun 17:06 Headers -> Versions/Current/Headers 8 lrwxr-xr-x 1 root wheel 23 2 Jun 17:06 Python -> Versions/Current/Python 8 lrwxr-xr-x 1 root wheel 26 2 Jun 17:06 Resources -> Versions/Current/Resources 0 drwxr-xr-x 3 root wheel 102 14 May 06:54 Versions However: pendari:Versions postgres$ ls -las total 0 0 drwxr-xr-x 3 root wheel 102 14 May 06:54 . 0 drwxr-xr-x 3 root wheel 204 14 May 06:49 .. 0 drwxrwxr-x 7 root admin 306 14 May 06:54 3.3 Specifically we are missing the following from .../Versions: 8 lrwxr-xr-x 1 root wheel 3 2 Jun 17:27 Current -> 3.3 to make all the other symlinks work as intended. This also implies the ~/.bash_profile patch would be improved if the existing: PATH="/Library/Frameworks/Python.framework/Versions/3.3/bin:${PATH}" was replaced by: PATH="/Library/Frameworks/Python.framework/Versions/Current/bin:${PATH}" Apologies if this has already been reported. It is my first report so I could easily have missed something: I searched with terms "installer mac". Regards Gavan Schneider ---------- assignee: ronaldoussoren components: Installation, Macintosh messages: 190474 nosy: gavan, ronaldoussoren priority: normal severity: normal status: open title: Missing symlink:Currnet after Mac OS X 3.3.2 package installation type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 2 12:14:02 2013 From: report at bugs.python.org (helmut) Date: Sun, 02 Jun 2013 10:14:02 +0000 Subject: [New-bugs-announce] [issue18118] curses utf8 output broken Message-ID: <1370168042.56.0.867946170074.issue18118@psf.upfronthosting.co.za> New submission from helmut: Consider the test case below. <<< #!/usr/bin/python # -*- encoding: utf8 -*- import curses def wrapped(screen): screen.addstr(0, 0, "?") screen.addstr(0, 1, "?") screen.addstr(0, 2, "?") screen.getch() if __name__ == "__main__": curses.wrapper(wrapped) >>> Expected output: "???" Output on py3.3: as expected Output on py2.7.3: "??" The actual bytes (as determined by strace) were "\303\303\303\274". Observe the inclusion of broken utf8 sequences. This issue was initially discovered on Debian sid, but independently confirmed on Arch Linux and two more unknown. ---------- components: Library (Lib) messages: 190479 nosy: helmut priority: normal severity: normal status: open title: curses utf8 output broken type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 2 12:22:10 2013 From: report at bugs.python.org (Shuhei Takahashi) Date: Sun, 02 Jun 2013 10:22:10 +0000 Subject: [New-bugs-announce] [issue18119] urllib.FancyURLopener does not treat URL fragments correctly Message-ID: <1370168530.11.0.609209040554.issue18119@psf.upfronthosting.co.za> New submission from Shuhei Takahashi: When urllib.FancyURLopener encounters 302 redirection to a URL with fragments, it sends wrong URL to servers. For example, if we run: urllib.urlopen('http://example.com/foo') and the server responds like following. HTTP/1.1 302 Found Location: /bar#test Then urllib tries next to fetch http://example.com/bar#test, instead of http://example.com/bar. Correctly, urllib should strip fragment part of URL before issuing requests. ---------- components: Library (Lib) messages: 190480 nosy: takahashi.shuhei priority: normal severity: normal status: open title: urllib.FancyURLopener does not treat URL fragments correctly type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 2 19:11:07 2013 From: report at bugs.python.org (spresse1) Date: Sun, 02 Jun 2013 17:11:07 +0000 Subject: [New-bugs-announce] [issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process Message-ID: <1370193067.61.0.466524662319.issue18120@psf.upfronthosting.co.za> New submission from spresse1: [Code demonstrating issue attached] When overloading multiprocessing.Process and using pipes, a reference to a pipe spawned in the parent is not properly garbage collected in the child. This causes the write end of the pipe to be held open with no reference to it in the child process, and therefore no way to close it. Therefore, it can never throw EOFError. Expected behavior: 1. Create a pipe with multiprocessing.Pipe(False) 2. Pass read end to a class which subclasses multiprocessing.Process 3. Close write end in parent process 4. Receive EOFError from read end Actual behavior: 1. Create a pipe with multiprocessing.Pipe(False) 2. Pass read end to a class which subclasses multiprocessing.Process 3. Close write end in parent process 4. Never receive EOFError from read end Examining the processes in /proc/[pid]/fds/ indicates that a write pipe is still open in the child process, though none should be. Additionally, no write pipe is open in the parent process. It is my belief that this is the write pipe spawned in the parent, and is remaining around incorrectly in the child, though there are no references to it. Tested on 2.7.3 and 3.2.3 ---------- components: Library (Lib) files: bugon.tar.gz messages: 190492 nosy: spresse1 priority: normal severity: normal status: open title: multiprocessing: garbage collector fails to GC Pipe() end when spawning child process versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file30448/bugon.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 2 20:18:54 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 02 Jun 2013 18:18:54 +0000 Subject: [New-bugs-announce] [issue18121] antigravity leaks subprocess.Popen object Message-ID: <1370197134.34.0.214224244916.issue18121@psf.upfronthosting.co.za> New submission from Christian Heimes: $ ./python Python 3.4.0a0 (default:801567d6302c+, May 23 2013, 14:22:00) [GCC 4.7.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> gc.set_debug(gc.DEBUG_UNCOLLECTABLE) >>> import antigravity >>> Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated. >>> gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc: uncollectable gc:0: ResourceWarning: gc: 1 uncollectable objects at shutdown [] platform: Ubuntu 12.10 AMD64 browser: Firefox 20.0 ---------- components: Library (Lib) messages: 190494 nosy: christian.heimes, pitrou priority: low severity: normal status: open title: antigravity leaks subprocess.Popen object type: resource usage versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 2 22:07:13 2013 From: report at bugs.python.org (Armin Rigo) Date: Sun, 02 Jun 2013 20:07:13 +0000 Subject: [New-bugs-announce] [issue18122] RuntimeError: not holding the import lock Message-ID: <1370203633.5.0.234026294285.issue18122@psf.upfronthosting.co.za> New submission from Armin Rigo: A new bug, introduced in recent Python 2.7 (2.7.3 passes, 2.7 trunk fails): With the attached x.py, running "python -c 'import x'" fails with RuntimeError: not holding the import lock. It occurs when doing a fork() while holding the import lock, if the child process imports more things (here distutils, could be anything) before finally trying to release the import lock (here by returning from the original 'import x'). ---------- files: x.py messages: 190498 nosy: arigo priority: normal severity: normal status: open title: RuntimeError: not holding the import lock versions: Python 2.7 Added file: http://bugs.python.org/file30450/x.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 2 22:08:23 2013 From: report at bugs.python.org (anatoly techtonik) Date: Sun, 02 Jun 2013 20:08:23 +0000 Subject: [New-bugs-announce] [issue18123] fnmatchicase for case insensitive file search Message-ID: <1370203703.41.0.79020240908.issue18123@psf.upfronthosting.co.za> New submission from anatoly techtonik: http://docs.python.org/2/library/glob.html and http://docs.python.org/2/library/fnmatch.html both lack ability to do case-insensitive search for filenames. Due to this difference, scripts that work ok on Windows start produce surprises on Linux. ---------- messages: 190499 nosy: techtonik priority: normal severity: normal status: open title: fnmatchicase for case insensitive file search versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 3 07:40:52 2013 From: report at bugs.python.org (Dmi Baranov) Date: Mon, 03 Jun 2013 05:40:52 +0000 Subject: [New-bugs-announce] [issue18124] Broken build on target machine with incorrect hostname (non-ascii) Message-ID: <1370238052.82.0.116613237858.issue18124@psf.upfronthosting.co.za> New submission from Dmi Baranov: As a part of issue #18109 $ echo h?t | sudo tee /proc/sys/kernel/hostname $ hostname #Yes, I know about RFC952;-) h?t $ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE=en_US.UTF-8 LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES=POSIX LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= $ make ... Consider setting $PYTHONHOME to [:] Traceback (most recent call last): File "/home/d9frog9n/workspace/cpython_default/Lib/runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/home/d9frog9n/workspace/cpython_default/Lib/runpy.py", line 73, in _run_code exec(code, run_globals) File "/home/d9frog9n/workspace/cpython_default/Lib/sysconfig.py", line 700, in _main() File "/home/d9frog9n/workspace/cpython_default/Lib/sysconfig.py", line 688, in _main _generate_posix_vars() File "/home/d9frog9n/workspace/cpython_default/Lib/sysconfig.py", line 391, in _generate_posix_vars pybuilddir = 'build/lib.%s-%s' % (get_platform(), sys.version[:3]) File "/home/d9frog9n/workspace/cpython_default/Lib/sysconfig.py", line 632, in get_platform osname, host, release, version, machine = os.uname() UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128) make: *** [pybuilddir.txt] Error 1 ---------- components: Installation, Unicode messages: 190516 nosy: dmi.baranov, ezio.melotti priority: normal severity: normal status: open title: Broken build on target machine with incorrect hostname (non-ascii) type: compile error versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 3 11:17:43 2013 From: report at bugs.python.org (Paul "TBBle" Hampson) Date: Mon, 03 Jun 2013 09:17:43 +0000 Subject: [New-bugs-announce] [issue18125] Out-of-tree build cannot regenerate Makefile.pre Message-ID: <1370251063.05.0.0234543553399.issue18125@psf.upfronthosting.co.za> New submission from Paul "TBBle" Hampson: Noticed in Python 2.7 but a quick look in the repository suggests this is also true in Python 3 releases. The Makefile rule for Makefile.pre in Makefile.pre.in is: # Build the toplevel Makefile Makefile.pre: Makefile.pre.in config.status CONFIG_FILES=Makefile.pre CONFIG_HEADERS= $(SHELL) config.status $(MAKE) -f Makefile.pre Makefile However, when built out-of-tree, Makefile.pre is in the build directory, as as config.status, but Makefile.pre.in is in the source directory. So the rule should be # Build the toplevel Makefile Makefile.pre: $(srcdir)/Makefile.pre.in config.status CONFIG_FILES=Makefile.pre CONFIG_HEADERS= $(SHELL) config.status $(MAKE) -f Makefile.pre Makefile Note that the recipe doesn't change, as config.status internally knows where Makefile.pre.in is found, so it's just the rule dependency that's wrong. This bug results in "No rule to create Makefile.pre.in" if Makefile.pre is somehow newer than Makefile or Modules/config.c in the build tree. ---------- components: Build messages: 190525 nosy: TBBle priority: normal severity: normal status: open title: Out-of-tree build cannot regenerate Makefile.pre versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 3 15:31:26 2013 From: report at bugs.python.org (Yury V. Zaytsev) Date: Mon, 03 Jun 2013 13:31:26 +0000 Subject: [New-bugs-announce] [issue18126] Update links to NumPy resources in documentation Message-ID: <1370266286.34.0.85536188421.issue18126@psf.upfronthosting.co.za> New submission from Yury V. Zaytsev: Hi, The links to NumPy sites and documentation are outdated. I replaced them with www.numpy.org, and also the canonical location for documentation (docs.scipy.org). I removed the explicit mention of the PDF file, because the documentation has been split in several guides, so I think it no longer makes sense, and it's better to link docs.scipy.org instead. Thanks! ---------- assignee: docs at python components: Documentation files: doc-numpy.patch keywords: patch messages: 190543 nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, zaytsev priority: normal severity: normal status: open title: Update links to NumPy resources in documentation type: enhancement Added file: http://bugs.python.org/file30455/doc-numpy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 3 21:38:11 2013 From: report at bugs.python.org (Poul-Henning Kamp) Date: Mon, 03 Jun 2013 19:38:11 +0000 Subject: [New-bugs-announce] [issue18127] Strange behaviour with default list argument Message-ID: <1370288291.84.0.212306741385.issue18127@psf.upfronthosting.co.za> New submission from Poul-Henning Kamp: I'd like to nominate this piece of code as candidate for the next round of "Most unexpected python behaviour" awards: def foo(a, x = []): x.append(a) return x print(foo(1)) print(foo(2)) I expected the output to be: [1] [2] but I get: [1] [1, 2] Bug? (If not, I'd *love* to read the rationale for this behaviour...) ---------- messages: 190557 nosy: bsdphk priority: normal severity: normal status: open title: Strange behaviour with default list argument type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 3 22:51:02 2013 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 03 Jun 2013 20:51:02 +0000 Subject: [New-bugs-announce] [issue18128] pygettext: non-standard timestamp format in POT-Creation-Date Message-ID: <1370292662.79.0.797202814422.issue18128@psf.upfronthosting.co.za> New submission from Jakub Wilk: pygettext uses non-standard timestamp format in the POT-Creation-Date field. For example: POT-Creation-Date: 2013-06-03 22:31+CEST whereas xgettext uses this format: POT-Creation-Date: 2013-06-03 22:31+0200 You could use this code to generate timestamps in the same format as xgettext: from time import time, localtime, strftime from calendar import timegm def gettext_timestamp(): now = int(time()) nowtuple = localtime(now) offset = timegm(nowtuple) - now sign = '-' if offset < 0 else '+' hour, minute = divmod(abs(offset) // 60, 60) return strftime('%Y-%m-%d %H:%M', nowtuple) + sign + '%02d%02d' % (hour, minute) ---------- messages: 190563 nosy: jwilk priority: normal severity: normal status: open title: pygettext: non-standard timestamp format in POT-Creation-Date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 4 00:18:52 2013 From: report at bugs.python.org (Oscar Benjamin) Date: Mon, 03 Jun 2013 22:18:52 +0000 Subject: [New-bugs-announce] [issue18129] Fatal Python error: Cannot recover from stack overflow. Message-ID: <1370297932.54.0.350896209872.issue18129@psf.upfronthosting.co.za> New submission from Oscar Benjamin: This is from a thread on python-list that started here: http://mail.python.org/pipermail/python-list/2013-May/647895.html There are situations in which the Python 3.2 and 3.3 interpreters crash with "Fatal Python error: Cannot recover from stack overflow." when I believe the correct response is a RuntimeError (as happens in 2.7). I've attached a file crash.py that demonstrates the problem. The following gives the same behaviour in 2.7, 3.2 and 3.3: $ cat tmp.py def loop(): loop() loop() $ py -3.2 tmp.py Traceback (most recent call last): File "tmp.py", line 4, in loop() File "tmp.py", line 2, in loop loop() File "tmp.py", line 2, in loop loop() File "tmp.py", line 2, in loop loop() File "tmp.py", line 2, in loop ... However the following leads to a RuntimeError in 2.7 but different fatal stack overflow errors in 3.2 and 3.3 (tested on Windows XP using 32-bit python.org installers): $ cat tmp.py def loop(): try: (lambda: None)() except RuntimeError: pass loop() loop() $ py -2.7 tmp.py Traceback (most recent call last): File "tmp.py", line 8, in loop() File "tmp.py", line 6, in loop loop() File "tmp.py", line 6, in loop loop() File "tmp.py", line 6, in loop loop() File "tmp.py", line 6, in loop ... RuntimeError: maximum recursion depth exceeded $ py -3.2 tmp.py Fatal Python error: Cannot recover from stack overflow. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. $ py -3.3 tmp.py Fatal Python error: Cannot recover from stack overflow. Current thread 0x000005c4: File "tmp.py", line 3 in loop File "tmp.py", line 6 in loop File "tmp.py", line 6 in loop File "tmp.py", line 6 in loop File "tmp.py", line 6 in loop File "tmp.py", line 6 in loop File "tmp.py", line 6 in loop ... Also tested on stock Python 3.2.3 on Ubuntu (2.7 gives RuntimeError): $ python3 tmp.py Fatal Python error: Cannot recover from stack overflow. Aborted (core dumped) I would expect this to give "RuntimeError: maximum recursion depth exceeded" in all cases. Oscar ---------- components: Interpreter Core files: crash.py messages: 190568 nosy: oscarbenjamin priority: normal severity: normal status: open title: Fatal Python error: Cannot recover from stack overflow. type: crash versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file30458/crash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 4 02:15:20 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 04 Jun 2013 00:15:20 +0000 Subject: [New-bugs-announce] [issue18130] idlelib.configSectionNameDialog: fix and add tests and mocks Message-ID: <1370304919.98.0.573433611159.issue18130@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The patch to configSectionNameDialog.py fixes the human test (adds required arg) so it runs, adds instructions to the test, fixes a bug in name_ok, removes redundant code, adds needed spaces, de-camelcases internal names, and changes the master for the two StringVars so they can be collected [sys:1: ResourceWarning: gc: 2 uncollectable objects at shutdown [, _______________________________________ From report at bugs.python.org Tue Jun 4 03:12:59 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 04 Jun 2013 01:12:59 +0000 Subject: [New-bugs-announce] [issue18131] Tkinter Variables require a proper master Message-ID: <1370308379.98.0.744218229266.issue18131@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The signature for tkinter class Variable and its subclasses StringVar, IntVar, DoubleVar, BooleanVar is def __init__(self, master=None, value=None, name=None): However, the None default is invalid because of self._tk = master.tk The preceding lines if not master: master = _default_root might suggest that None is acceptible. But _default_root is set to None at the top of the file, so that just replaces None with None. If Variables must have a gui widget parent, then they cannot be used in gui-free tests, even though they have no graphic representation. Moveover, not everything is a proper master. configSectionNameDialog.py . GetCfgSectionNameDialog(Toplevel) . Create.Widgets(self) has these lines: self.name = StringVar(self) self.fontSize = StringVar(self) However, these are not (always) garbage collectable. After fixing the dialog test at the bottom of the file, and running it with 3.3 python_d -m idlelib.configSectionNameDialog (#18130), and adding the gc flag, I repeatedly got [sys:1: ResourceWarning: gc: 2 uncollectable objects at shutdown [, _______________________________________ From report at bugs.python.org Tue Jun 4 15:46:45 2013 From: report at bugs.python.org (Jan Kanis) Date: Tue, 04 Jun 2013 13:46:45 +0000 Subject: [New-bugs-announce] [issue18132] buttons in turtledemo disappear on small screens Message-ID: <1370353605.18.0.929519765734.issue18132@psf.upfronthosting.co.za> New submission from Jan Kanis: If the window of the turtledemo is small enough, the start/stop/clear buttons disappear. This is specifically a problem when running on a netbook with a small screen, because the buttons are never shown. For a newcommer checking out the demo app this could be very confusing as there is no indication on what went wrong, and the notification area just says 'press start button'. ---------- messages: 190596 nosy: JanKanis priority: normal severity: normal status: open title: buttons in turtledemo disappear on small screens versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 4 19:10:34 2013 From: report at bugs.python.org (Joshua) Date: Tue, 04 Jun 2013 17:10:34 +0000 Subject: [New-bugs-announce] [issue18133] Modulus not calculating properly? Message-ID: <1370365834.5.0.461885033032.issue18133@psf.upfronthosting.co.za> New submission from Joshua: The Modulus doesn't seem to pull the proper remainder from simple calculations. Look at the difference below between the remainder of a regular division calculation and the modulus: Am I missing something??? >>> print (str(10.2 / 2)) 5.1 >>> print (str(10.2 % 2)) 0.1999999999999993 >>> ---------- components: Windows messages: 190606 nosy: pccreator25 priority: normal severity: normal status: open title: Modulus not calculating properly? type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 4 22:24:26 2013 From: report at bugs.python.org (Benedict Kwok) Date: Tue, 04 Jun 2013 20:24:26 +0000 Subject: [New-bugs-announce] [issue18134] zipfile extractall accepts wrong password Message-ID: <1370377466.33.0.877137256378.issue18134@psf.upfronthosting.co.za> New submission from Benedict Kwok: Steps to reproduce: 1) create a ssn.txt file with social security numbers of customers 2) create a zip file with a password: zip -P secret ssn ssn.txt 3) create a python script to extract the zipfile by: import=zipfile zFile=zipfile.ZipFile("ssn.zip") try: zFile.extractall(pwd="secret") except Exception, e: print e This will extract the ssn.txt into the directory by using the right password "secret"different 4) However, by using a wrong password "proa" this does not get the exception. Instead create a ssn.txt file which is corrupted. 5) Other wrong password will get the exception but not the one descripted in step 4. ---------- messages: 190610 nosy: benedictkwok priority: normal severity: normal status: open title: zipfile extractall accepts wrong password type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 4 23:34:39 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 04 Jun 2013 21:34:39 +0000 Subject: [New-bugs-announce] [issue18135] _ssl module: possible integer overflow for very long strings (+2^31 bytes) Message-ID: <1370381679.09.0.63930940174.issue18135@psf.upfronthosting.co.za> New submission from STINNER Victor: Our Windows 64-bit buildbot has interesting warnings: ..\Modules\_ssl.c(493): warning C4244: 'function' : conversion from 'SOCKET_T' to 'int', possible loss of data [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj] ..\Modules\_ssl.c(1304): warning C4244: 'function' : conversion from 'SOCKET_T' to 'int', possible loss of data [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj] ..\Modules\_ssl.c(1306): warning C4244: 'function' : conversion from 'SOCKET_T' to 'int', possible loss of data [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj] ..\Modules\_ssl.c(1360): warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj] ..\Modules\_ssl.c(1655): warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj] ..\Modules\_ssl.c(1659): warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj] ..\Modules\_ssl.c(2109): warning C4244: 'return' : conversion from 'Py_ssize_t' to 'int', possible loss of data [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj] http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/2042/steps/compile/logs/warnings%20%28532%29 It looks like the _ssl.c module does mix int and size_t types. Attached patch should fix 3 warnings. I didn't test my patch except running test_ssl (with success on my Linux x64 box). ---------- files: ssl_int.patch keywords: patch messages: 190614 nosy: haypo, pitrou priority: normal severity: normal status: open title: _ssl module: possible integer overflow for very long strings (+2^31 bytes) versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30464/ssl_int.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 4 23:41:30 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 04 Jun 2013 21:41:30 +0000 Subject: [New-bugs-announce] [issue18136] test_distutils failing under OS X 10.8 w/ clang Message-ID: <1370382090.88.0.902200330561.issue18136@psf.upfronthosting.co.za> New submission from Brett Cannon: I have not had test_distutils succeed in ages. It looks like various header files are not being passed to the compiler properly as all three test failures stem from PyModuleDef_HEAD_INIT supposedly not existing or some other macro. Below is an example failure test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ... /var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:341:5: error: use of undeclared identifier 'PyModuleDef_HEAD_INIT' PyModuleDef_HEAD_INIT, ^ /var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:340:27: error: variable has incomplete type 'struct PyModuleDef' static struct PyModuleDef xxmodule = { ^ /var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:340:15: note: forward declaration of 'struct PyModuleDef' static struct PyModuleDef xxmodule = { ^ /var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:370:9: warning: implicit declaration of function 'PyModule_Create' is invalid in C99 [-Wimplicit-function-declaration] m = PyModule_Create(&xxmodule); ^ /var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:392:5: error: void function 'PyInit_xx' should not return a value [-Wreturn-type] return m; ^ ~ /var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:395:5: error: void function 'PyInit_xx' should not return a value [-Wreturn-type] return NULL; ^ ~~~~ 1 warning and 4 errors generated. ERROR ---------- assignee: eric.araujo components: Distutils, Macintosh messages: 190615 nosy: brett.cannon, eric.araujo, tarek priority: normal severity: normal stage: needs patch status: open title: test_distutils failing under OS X 10.8 w/ clang type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 5 01:11:30 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 04 Jun 2013 23:11:30 +0000 Subject: [New-bugs-announce] [issue18137] format(float, str): integer overflow for huge precision Message-ID: <1370387490.7.0.925760036374.issue18137@psf.upfronthosting.co.za> New submission from STINNER Victor: format(1.2, ".%sf" % (2**32 + 2)) returns "1.20": the integer overflow is not catced. Attached patch fixes the issue. ---------- components: Interpreter Core files: float_format_precision.patch keywords: patch messages: 190629 nosy: haypo, mark.dickinson priority: normal severity: normal status: open title: format(float, str): integer overflow for huge precision versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30465/float_format_precision.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 5 03:50:33 2013 From: report at bugs.python.org (Christian Heimes) Date: Wed, 05 Jun 2013 01:50:33 +0000 Subject: [New-bugs-announce] [issue18138] ssl.SSLContext.add_cert() Message-ID: <1370397033.84.0.295479011719.issue18138@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch implements an add_cert(pem_or_der_data) method for the ssl.SSLContext() object. On success the method adds a trusted CA cert to the context's internal cert store. The CA certificate can either be an ASCII unicode string (PEM format) or buffer object (DER / ASN1 format). The patch also implements a get_cert_count() method for debugging. I'm going to remove that function eventually as it doesn't give correct answers when the object table contains CRLs, too. A correct implementation might be useful to verify set_default_verify_paths(). I've split up the functions so I can re-use _add_cert() in my upcoming patch for an interface to crypt32.dll on Windows. ---------- components: Extension Modules files: sslctx_add_cert.patch keywords: patch messages: 190637 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: ssl.SSLContext.add_cert() type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30466/sslctx_add_cert.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 5 06:35:54 2013 From: report at bugs.python.org (Kiran Bandla) Date: Wed, 05 Jun 2013 04:35:54 +0000 Subject: [New-bugs-announce] [issue18139] email module's add_header appends instead of inserting Message-ID: <1370406954.57.0.95690715483.issue18139@psf.upfronthosting.co.za> New submission from Kiran Bandla: This issue is in message.py in the email module. The add_header method should insert the new header on the top of the existing headers. The current function implementation appends the header at the end of the existing headers. ---------- components: Library (Lib) messages: 190641 nosy: kbandla priority: normal severity: normal status: open title: email module's add_header appends instead of inserting type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 5 11:45:03 2013 From: report at bugs.python.org (anh le) Date: Wed, 05 Jun 2013 09:45:03 +0000 Subject: [New-bugs-announce] [issue18140] urlparse.urlsplit confused to fragment when password include # Message-ID: <1370425503.35.0.436511643169.issue18140@psf.upfronthosting.co.za> New submission from anh le: >>> u = 'http://auser:secr#et at 192.168.0.1:8080/a/b/c.html' >>> urlparse.urlsplit(u) SplitResult(scheme='http', netloc='auser:secr', path='', query='', fragment='et at 192.168.0.1:8080/a/b/c.html') ---------- components: Library (Lib) messages: 190646 nosy: anh.le priority: normal severity: normal status: open title: urlparse.urlsplit confused to fragment when password include # type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 5 14:09:36 2013 From: report at bugs.python.org (Jan Kanis) Date: Wed, 05 Jun 2013 12:09:36 +0000 Subject: [New-bugs-announce] [issue18141] tkinter.Image.__del__ can throw an exception if module globals are destroyed in the wrong order Message-ID: <1370434176.62.0.932474289882.issue18141@psf.upfronthosting.co.za> New submission from Jan Kanis: While fixing #18132 I noticed that when closing the turtledemo window an exception is thrown (and ignored) because the __del__ tries to catch a TclError exception, but the TclError global has already been deleted and set to None. I could only reproduce this in my self built pydebug build, at least on revision dfcb64f51f7b, but not on the v3.3.2 tag. (compiled with --with-pydebug on linux x86-64) traceback: me at mymachine ~/d/cpython> ./python -m turtledemo BYE! Exception ignored in: > Traceback (most recent call last): File "~/devel/cpython/Lib/tkinter/__init__.py", line 3330, in __del__ TypeError: catching classes that do not inherit from BaseException is not allowed ---------- components: Tkinter messages: 190654 nosy: JanKanis priority: normal severity: normal status: open title: tkinter.Image.__del__ can throw an exception if module globals are destroyed in the wrong order versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 5 17:20:21 2013 From: report at bugs.python.org (Shlomi Fish) Date: Wed, 05 Jun 2013 15:20:21 +0000 Subject: [New-bugs-announce] [issue18142] Tests fail on Mageia Linux Cauldron x86-64 with some configure flags Message-ID: <1370445621.52.0.671437694015.issue18142@psf.upfronthosting.co.za> New submission from Shlomi Fish: After I build Python-3.3.2 from the .tar.xz using the following script (on Mageia Linux Cauldron x86-64): <<< #!/bin/bash ./configure --prefix="$HOME/apps/python3" --with-threads \ --enable-ipv6 --with-dbmliborder=gdbm \ --with-system-expat \ --with-system-ffi \ --enable-shared \ --with-valgrind shlomif at telaviv1:~/Download/unpack/prog/python/Python-3.3.2$ >>> I get many test failures in make test (in the file attached to this repository). Can you look into fixing them? This is a precursor for fixing this bug: https://bugs.mageia.org/show_bug.cgi?id=9395 Regards, -- Shlomi Fish ---------- components: Tests files: python-make-test-output.txt messages: 190665 nosy: shlomif priority: normal severity: normal status: open title: Tests fail on Mageia Linux Cauldron x86-64 with some configure flags versions: Python 3.3 Added file: http://bugs.python.org/file30471/python-make-test-output.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 5 17:44:20 2013 From: report at bugs.python.org (Christian Heimes) Date: Wed, 05 Jun 2013 15:44:20 +0000 Subject: [New-bugs-announce] [issue18143] ssl.get_default_verify_paths() Message-ID: <1370447060.67.0.813432963563.issue18143@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch implements a get_default_verify_paths() function for the ssl module. It returns the env vars and paths that are used by openssl's set_default_verify_paths() to load CA certs from default locations. I think it makes a useful addition for debugging purposes. On my system: >>> import ssl >>> ssl.get_default_verify_paths() (None, '/usr/lib/ssl/certs') >>> ssl.get_default_verify_paths(raw=True) ('SSL_CERT_FILE', '/usr/lib/ssl/cert.pem', 'SSL_CERT_DIR', '/usr/lib/ssl/certs') SSL_CTX_set_default_verify_paths() first tries the env var. If the env var is set the second element is ignored. ---------- files: sslverifypath.patch keywords: patch messages: 190669 nosy: christian.heimes, pitrou priority: normal severity: normal stage: patch review status: open title: ssl.get_default_verify_paths() type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30473/sslverifypath.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 5 21:10:23 2013 From: report at bugs.python.org (Claudio Freire) Date: Wed, 05 Jun 2013 19:10:23 +0000 Subject: [New-bugs-announce] [issue18144] FD leak in urllib2 Message-ID: <1370459423.62.0.313188871142.issue18144@psf.upfronthosting.co.za> New submission from Claudio Freire: While other issues already exist about this problem, this particular case is unlike other issues, and I didn't think it a good idea to merge with those. Under some very specific circumstances (sending a POST request with more data than an unknown threshold), at least one socket remains unclosed after calling close() on urllib2.urlopen's returned file object. While I marked the only versions I could confirm exhibit the issue, I believe this is an issue on all versions. This started in pypy[0], although it applies to CPython as well (albeit the reference counting GC is less likely to delay closing of the FD as much as in pypy). I'm attaching the same server used to trigger this issue in pypy, works the same with CPython. To trigger the leak, open an interpreter and do this (copypaste from pypy, CPython does not cause the leak because decref immediately closes the leak, but it will issue a wraning if ran with -Wall). See pypy's issue tracker[0] for detilas. >>>> import os, urllib2 >>>> req = """{"imp": [{"h": 50, "battr": ["9", "10", "12"], "api": 3, "w": 320, "instl": 0, "impid": "5d6dedf3-17bb-11e2-b5c0-1040f38b83e0"}]""" * 10 >>>> r = urllib2.Request("http://localhost:8000/bogus?src=1", req) >>>> u = urllib2.urlopen(r) >>>> v = u.read() >>>> u.close() >>>> os.system("ls -alh /proc/%d/fd/*" % os.getpid()) lrwx------ 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/0 -> /dev/pts/5 lrwx------ 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/1 -> /dev/pts/5 lrwx------ 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/2 -> /dev/pts/5 lrwx------ 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/3 -> socket:[2086998] lrwx------ 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/5 -> /dev/pts/5 lrwx------ 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/6 -> /dev/pts/5 0 >>>> [0] https://bugs.pypy.org/issue867 ---------- components: Library (Lib) files: bogus.py messages: 190687 nosy: Claudio.Freire priority: normal severity: normal status: open title: FD leak in urllib2 type: behavior versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file30477/bogus.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 5 21:17:53 2013 From: report at bugs.python.org (Antoine Pietri) Date: Wed, 05 Jun 2013 19:17:53 +0000 Subject: [New-bugs-announce] [issue18145] Strange behavior when importing internal modules in the __init__.py of a submodule Message-ID: <1370459873.38.0.323655253605.issue18145@psf.upfronthosting.co.za> New submission from Antoine Pietri: I just found a very strange bug today, and it took me like two hours to figure out the problem. We first create a package "package", which contains an __init__.py, which makes an absolute import of package/foo.py (import package.foo), which makes an absolute import of package/bar.py (import package.bar). Everything works fine as expected, the modules are imported correctly in the __init__.py and we can use them. Now, if we move everything in a subpackage, the behavior is complete nonsense. We then have package/subpackage/{foo,bar,__init__}.py and an empty package/__init__.py. We can import package.subpackage.foo and use it, but when we import package.subpackage.bar, the "import" statement works as expected but we CAN'T use the imported package: >>> import package.subpackage.bar # works fine >>> dir(package.subpackage.bar) # WAT AttributeError: 'module' object has no attribute 'subpackage' You can find a tarball attached to this bug report that contains the working case and the failing case: package1 ??? bar.py ??? foo.py ??? __init__.py package2 ??? subpackage ??? bar.py ??? foo.py ??? __init__.py $ python3 >>> import package1.foo __init__: importing package1.foo foo.py: importing package1.bar foo.py: package1.bar.__name__: package1.bar __init__: package1.foo.__name__: package1.foo >>> import package2.subpackage.foo __init__: importing package2.subpackage.foo foo.py: importing package2.subpackage.bar Traceback (most recent call last): File "", line 1, in File "./package2/subpackage/__init__.py", line 2, in import package2.subpackage.foo File "./package2/subpackage/foo.py", line 3, in print(' foo.py: package2.subpackage.bar.__name__:', package2.subpackage.bar.__name__) AttributeError: 'module' object has no attribute 'subpackage' tl;dr: you can use only relative imports to refer to modules of a package inside a module imported by the __init__.py of this package except if the package is not a subpackage. Else, the package will be successfully imported but trying to use it will lead to a weird AttributeError. (Wat.) ---------- components: Interpreter Core files: lolpython.tar.xz messages: 190688 nosy: seirl priority: normal severity: normal status: open title: Strange behavior when importing internal modules in the __init__.py of a submodule type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file30478/lolpython.tar.xz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 6 06:16:09 2013 From: report at bugs.python.org (hanks) Date: Thu, 06 Jun 2013 04:16:09 +0000 Subject: [New-bugs-announce] [issue18146] Document miss, Stats objects has no method called "print_results" Message-ID: <1370492169.32.0.572100165636.issue18146@psf.upfronthosting.co.za> New submission from hanks: link: http://docs.python.org/2/library/profile.html The example in this page: import cProfile, pstats, io pr = cProfile.Profile() pr.enable() ... do something ... pr.disable() s = io.StringIO() ps = pstats.Stats(pr, stream=s) ps.print_results() # actually Stats objects has no method called "print_results" ---------- assignee: docs at python components: Documentation messages: 190705 nosy: docs at python, hanks priority: normal severity: normal status: open title: Document miss, Stats objects has no method called "print_results" type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 6 12:19:29 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 06 Jun 2013 10:19:29 +0000 Subject: [New-bugs-announce] [issue18147] SSL: diagnostic functions to list loaded CA certs Message-ID: <1370513969.26.0.776855011912.issue18147@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch adds two methods to SSLContext which return information about loaded x509 certs, CRL and CAs. Example: >>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1) >>> ctx.load_verify_locations(SVN_PYTHON_ORG_ROOT_CERT) >>> ctx.cert_store_stats() {'crl': 0, 'x509': 1} >>> ctx.get_ca_list() [{'issuer': ((('organizationName', 'Root CA'),), (('organizationalUnitName', 'http://www.cacert.org'),), (('commonName', 'CA Cert Signing Authority'),), (('emailAddress', 'support at cacert.org'),)), 'notAfter': 'Mar 29 12:29:49 2033 GMT', 'notBefore': 'Mar 30 12:29:49 2003 GMT', 'serialNumber': '00', 'subject': ((('organizationName', 'Root CA'),), (('organizationalUnitName', 'http://www.cacert.org'),), (('commonName', 'CA Cert Signing Authority'),), (('emailAddress', 'support at cacert.org'),)), 'version': 3}] ---------- components: Extension Modules files: ssl_ca_stats.patch keywords: patch messages: 190709 nosy: brett.cannon, christian.heimes, pitrou priority: normal severity: normal stage: patch review status: open title: SSL: diagnostic functions to list loaded CA certs type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30481/ssl_ca_stats.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 6 14:49:37 2013 From: report at bugs.python.org (Donal Duane) Date: Thu, 06 Jun 2013 12:49:37 +0000 Subject: [New-bugs-announce] [issue18148] Make of Python 3.2.2 fails on Solaris SPARC Message-ID: <1370522977.23.0.850120192524.issue18148@psf.upfronthosting.co.za> New submission from Donal Duane: Hi, I am trying to configure/make/make install Python 3.2.2 on Solaris SPARC. The configure goes ok, but I am getting an error when doing make. I am using GCC 3.4.6. Error: make/usr/local/bin/gcc -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.cIn file included from Include/Python.h:50,from ./Modules/python.c:3:Include/pyport.h:257:13: #error "This platform's pyconfig.h needs to define PY_FORMAT_LONG_LONG"*** Error code 1make: Fatal error: Command failed for target `Modules/python.o' Regards, Donal ---------- components: Cross-Build messages: 190713 nosy: eeiddne priority: normal severity: normal status: open title: Make of Python 3.2.2 fails on Solaris SPARC type: compile error versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 6 16:07:35 2013 From: report at bugs.python.org (=?utf-8?q?Matej_Fr=C3=B6be?=) Date: Thu, 06 Jun 2013 14:07:35 +0000 Subject: [New-bugs-announce] [issue18149] filecmp.cmp() - cache invalidation fails when file modification times haven't changed Message-ID: <1370527655.93.0.14200399247.issue18149@psf.upfronthosting.co.za> New submission from Matej Fr?be: Example: with open('file1', 'w') as f: f.write('a') with open('file2', 'w') as f: f.write('a') print filecmp.cmp('file1', 'file2', shallow=False) # true with open('file2', 'w') as f: f.write('b') print filecmp.cmp('file1', 'file2', shallow=False) # true Because of the caching, both calls to filecmp.cmp() return true on my system. When retrieving value from cache, the function filecmp.cmp() checks the signatures of the files: s1 = _sig(os.stat(f1)) s2 = _sig(os.stat(f2)) ... outcome = _cache.get((f1, f2, s1, s2)) But the signatures in cache are the same, if the file sizes and times of modification (os.stat().st_mtime) haven't changed from the last call, even if the content has changed. The buffer is mentioned in the documentation, but there isn't any documented way to clear it. It also isn't nice IMO, that one has to worry about the file system's resolution of the file modification time when calling a simple file comparison. ---------- components: Library (Lib) messages: 190715 nosy: fbm priority: normal severity: normal status: open title: filecmp.cmp() - cache invalidation fails when file modification times haven't changed type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 6 17:18:12 2013 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 06 Jun 2013 15:18:12 +0000 Subject: [New-bugs-announce] [issue18150] Duplicate test inside TestSingleDispatch Message-ID: <1370531892.77.0.178198886311.issue18150@psf.upfronthosting.co.za> New submission from Vajrasky Kok: There is a duplicate test inside TestSingleDispatch in file Lib/test/test_functools.py. The method test_mro and test_classic_classes are not different at all. ---------- components: Tests files: duplicate_test_for_testsingledispatch.diff keywords: patch messages: 190717 nosy: lukasz.langa, vajrasky priority: normal severity: normal status: open title: Duplicate test inside TestSingleDispatch versions: Python 3.4 Added file: http://bugs.python.org/file30484/duplicate_test_for_testsingledispatch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 6 19:02:32 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 06 Jun 2013 17:02:32 +0000 Subject: [New-bugs-announce] [issue18151] Idlelib: update to "with open ... except OSError" (in 2.7, leave IOError) Message-ID: <1370538152.36.0.501706446334.issue18151@psf.upfronthosting.co.za> New submission from Terry J. Reedy: This issue is about uniformly updating the old idiom try: f = open('file') to the current idiom try: with open('file') as f: #16715 changed 'IOError' to 'OSError' everywhere in Lib/* for 3.4 only. I ran into this issue (again) because GrepDialog.Grepdialog.grep_it uses open without close. Consequently, with debug builds, 'Find in files' raises a ResourceWarning for each file opened. Because of the 3.4-only change, there will be a merge conflict. To avoid this, now and in the future, I plan to backport the idlelib subset of the Svetlov's patch to 3.3 (it applied with only one fix). Currently, all 3.x patches are being applied to both 3.3 and 3.4 and any 3.3 patch with 'IOError' will have a merge conflict. Any 3.4 patch with 'OSError' will not apply to 3.3. There is no longer an issue with breaking 3.2 to 3.3 merges. This change will break existing 3.3 patches with 'IOError', but they would break anyway on the merge. ---------- components: IDLE files: idle33.io2os.diff keywords: patch messages: 190718 nosy: Todd.Rovito, roger.serwy, terry.reedy priority: normal severity: normal stage: commit review status: open title: Idlelib: update to "with open ... except OSError" (in 2.7, leave IOError) type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30485/idle33.io2os.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 6 20:29:51 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 06 Jun 2013 18:29:51 +0000 Subject: [New-bugs-announce] [issue18152] Idle: add 2.7 backport script Message-ID: <1370543391.75.0.919797325796.issue18152@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Backporting Idle patches from 3.x to 2.7 would be easier with a canned edit script. Below are the substitutions I can think of immediately. Do any of you know of others? Easy (str.replace): tkinter -> Tkinter import tkinter.messagebox as tkMessageBox -> import tkMessageBox A bit tricky (but still use str.replace): OSError -> IOError This presumes that IOError become OSError in 3.3 as well as 3.4 (#18151). But there are a few existig OSErrors is 3.3 (and that pre-existed the change in 3.4). So there would would need to be a check that a changed line matched an existing 2.7 line. Harder (2to3 parser?): print(arglist) -> print arglist # but what if keyword args? Outputting "fix print on line nn" would be easiest. README needed (python -m) test -> (python -m) test.regrtest in the test instructions, but this should be the only place that occurs. I might put 'edit_patch' or whatever in idle_test. ---------- messages: 190719 nosy: Todd.Rovito, asvetlov, ned.deily, roger.serwy, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: add 2.7 backport script type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 02:20:42 2013 From: report at bugs.python.org (tahnoon pasha) Date: Fri, 07 Jun 2013 00:20:42 +0000 Subject: [New-bugs-announce] [issue18153] python imaplib - error 'unexpected repsonse' Message-ID: <1370564442.51.0.371517794914.issue18153@psf.upfronthosting.co.za> New submission from tahnoon pasha: Hi I've suddenly encountered an error using imaplib on some code that worked fine before. import imaplib m = imaplib.IMAP4('myserver','port') m.login(r'username','password') m.select() gives me the error Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/imaplib.py", line 649, in select typ, dat = self._simple_command(name, mailbox) File "/usr/lib/python2.7/imaplib.py", line 1070, in _simple_command return self._command_complete(name, self._command(name, *args)) File "/usr/lib/python2.7/imaplib.py", line 899, in _command_complete raise self.abort('command: %s => %s' % (name, val)) imaplib.abort: command: SELECT => unexpected response: '* 1520 EXISTS' I'm not sure what it means. Emails are otherwise coming through fine, and I'm using davmail as a server. The program in its entirety saves attachments with a certain name in a specific folder. I've stepped through it and its definitely the `m.select()` that is where its falling over. This same program worked absolutely fine until recently. What am I doing wrong, and how do I fix it? The log of activity is as follows >>> import imaplib >>> m = imaplib.IMAP4('server','port') >>> Debug=4 >>> m.debug 0 >>> m.debug=4 >>> m.debug 4 >>> m.login(r'username','password') 01:26.55 > HLFI1 LOGIN "username" "password" 01:30.76 < HLFI1 OK Authenticated ('OK', ['Authenticated']) >>> m.list() 01:56.33 > HLFI2 LIST "" * 02:00.04 < * LIST (\HasNoChildren) "/" "Trash/Sent Messages" 02:00.04 < * LIST (\HasNoChildren) "/" "Sync Issues/Server Failures" 02:00.04 < * LIST (\HasNoChildren) "/" "Sync Issues/Local Failures" 02:00.04 < * LIST (\HasNoChildren) "/" "Sync Issues/Conflicts" 02:00.04 < * LIST (\HasChildren) "/" "Sync Issues" 02:00.04 < * LIST (\HasNoChildren) "/" "Junk E-mail" 02:00.04 < * LIST (\HasNoChildren) "/" "Drafts" 02:00.04 < * LIST (\HasChildren) "/" "Trash" 02:00.04 < * LIST (\HasNoChildren) "/" "Sent" 02:00.04 < * LIST (\HasNoChildren) "/" "Outbox" 02:00.04 < * LIST (\HasNoChildren) "/" "INBOX" 02:00.04 < HLFI2 OK LIST completed ('OK', ['(\\HasNoChildren) "/" "Trash/Sent Messages"', '(\\HasNoChildren) "/" "Sync Issues/Server Failures"', '(\\HasNoChildren) "/" "Sync Issues/Local Failures"', '(\\HasNoChildren) "/" "Sync Issues/Conflicts"', '(\\HasChildren) "/" "Sync Issues"', '(\\HasNoChildren) "/" "Junk E-mail"', '(\\HasNoChildren) "/" "Drafts"', '(\\HasChildren) "/" "Trash"', '(\\HasNoChildren) "/" "Sent"', '(\\HasNoChildren) "/" "Outbox"', '(\\HasNoChildren) "/" "INBOX"']) >>> m.select() 02:21.37 > HLFI3 SELECT INBOX 02:30.87 < * 1548 EXISTS 02:30.87 last 4 IMAP4 interactions: 00:16.73 < * OK [CAPABILITY IMAP4REV1 AUTH=LOGIN MOVE] IMAP4rev1 DavMail 4.3.0-2125 server ready 00:16.73 > HLFI0 CAPABILITY 00:16.74 < * CAPABILITY IMAP4REV1 AUTH=LOGIN MOVE 00:16.77 < HLFI0 OK CAPABILITY completed Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/imaplib.py", line 649, in select typ, dat = self._simple_command(name, mailbox) File "/usr/lib/python2.7/imaplib.py", line 1070, in _simple_command return self._command_complete(name, self._command(name, *args)) File "/usr/lib/python2.7/imaplib.py", line 899, in _command_complete raise self.abort('command: %s => %s' % (name, val)) imaplib.abort: command: SELECT => unexpected response: '* 1548 EXISTS' I understand that this seems to be occurring because of the extra spaces in the final RETURN from a query on stack overflow http://stackoverflow.com/questions/16911238/python-imaplib-error-unexpected-repsonse and it was suggested I file an issue report. I'm using Davmail as the server on Ubuntu 13.04 and the server works fine with Thunderbird, Fetchmail and Evolution My first attempt at filing an issue so apologies if I've done something wrong. ---------- components: email messages: 190733 nosy: barry, r.david.murray, tahnoon priority: normal severity: normal status: open title: python imaplib - error 'unexpected repsonse' type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 10:08:37 2013 From: report at bugs.python.org (Palm Kevin) Date: Fri, 07 Jun 2013 08:08:37 +0000 Subject: [New-bugs-announce] [issue18154] make install failed on solaris Message-ID: <1370592517.54.0.994664040442.issue18154@psf.upfronthosting.co.za> New submission from Palm Kevin: On Solaris, make install fails on target altbininstall. This is due to the fact than on Solaris you man not create a symlink using `ln -sf` -> You have to use `ln -f -s`. (SunOS sol1 5.10 Generic_147440-09 sun4u sparc SUNW,Sun-Fire-V240) ---------- components: Build messages: 190738 nosy: palm.kevin priority: normal severity: normal status: open title: make install failed on solaris versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 13:09:19 2013 From: report at bugs.python.org (Dave Challis) Date: Fri, 07 Jun 2013 11:09:19 +0000 Subject: [New-bugs-announce] [issue18155] csv.Sniffer.has_header doesn't escape characters used in regex Message-ID: <1370603359.06.0.18660649496.issue18155@psf.upfronthosting.co.za> New submission from Dave Challis: When attempting to detect the presence of CSV headers, delimiters are passed to a regex function without escaping, which causes an exception if a delimiter which has meaning in a regex (e.g. '+', '*' etc.) is used. Code to reproduce: import csv s = csv.Sniffer() s.has_header('"x"+"y"') Trace: Traceback (most recent call last): File "t.py", line 4, in s.has_header('"x"+"y"') File "/usr/lib64/python3.3/csv.py", line 393, in has_header rdr = reader(StringIO(sample), self.sniff(sample)) File "/usr/lib64/python3.3/csv.py", line 183, in sniff self._guess_quote_and_delimiter(sample, delimiters) File "/usr/lib64/python3.3/csv.py", line 268, in _guess_quote_and_delimiter {'delim':delim, 'quote':quotechar}, re.MULTILINE) File "/home/dsc/venv/p3compat/lib64/python3.3/re.py", line 214, in compile return _compile(pattern, flags) File "/home/dsc/venv/p3compat/lib64/python3.3/re.py", line 281, in _compile p = sre_compile.compile(pattern, flags) File "/home/dsc/venv/p3compat/lib64/python3.3/sre_compile.py", line 494, in compile p = sre_parse.parse(p, flags) File "/home/dsc/venv/p3compat/lib64/python3.3/sre_parse.py", line 748, in parse p = _parse_sub(source, pattern, 0) File "/home/dsc/venv/p3compat/lib64/python3.3/sre_parse.py", line 360, in _parse_sub itemsappend(_parse(source, state)) File "/home/dsc/venv/p3compat/lib64/python3.3/sre_parse.py", line 696, in _parse p = _parse_sub(source, state) File "/home/dsc/venv/p3compat/lib64/python3.3/sre_parse.py", line 360, in _parse_sub itemsappend(_parse(source, state)) File "/home/dsc/venv/p3compat/lib64/python3.3/sre_parse.py", line 696, in _parse p = _parse_sub(source, state) File "/home/dsc/venv/p3compat/lib64/python3.3/sre_parse.py", line 360, in _parse_sub itemsappend(_parse(source, state)) File "/home/dsc/venv/p3compat/lib64/python3.3/sre_parse.py", line 569, in _parse raise error("nothing to repeat") sre_constants.error: nothing to repeat ---------- components: Library (Lib) messages: 190742 nosy: davechallis priority: normal severity: normal status: open title: csv.Sniffer.has_header doesn't escape characters used in regex type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 17:31:50 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 07 Jun 2013 15:31:50 +0000 Subject: [New-bugs-announce] [issue18156] Add an 'attr' attribute to AttributeError Message-ID: <1370619110.26.0.980030189702.issue18156@psf.upfronthosting.co.za> New submission from Brett Cannon: Much like ImportError now has 'name' and 'path', AttributeError should get an 'attr' attribute that can only be set through a keyword argument or after creating an instance. That would make the common ``try/except AttributeError`` uses much more robust by not accidentally swallowing an AttributeError that has nothing to do with the attribute in question:: try: cls.meth() except AttributeError as exc: if exc.attr != 'meth': raise ---------- components: Interpreter Core messages: 190754 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Add an 'attr' attribute to AttributeError type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 19:41:54 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 07 Jun 2013 17:41:54 +0000 Subject: [New-bugs-announce] [issue18157] remove usage of imp.load_module() from pydoc Message-ID: <1370626914.2.0.873203030907.issue18157@psf.upfronthosting.co.za> New submission from Brett Cannon: ---------- assignee: brett.cannon components: Library (Lib) messages: 190765 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: remove usage of imp.load_module() from pydoc type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 19:43:10 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 07 Jun 2013 17:43:10 +0000 Subject: [New-bugs-announce] [issue18158] Delete test_importhooks Message-ID: <1370626990.67.0.389270737108.issue18158@psf.upfronthosting.co.za> New submission from Brett Cannon: Tests don't serve much of a purpose with test_importlib covering the uses, plus the tests are old and are not worth updating. ---------- assignee: brett.cannon components: Tests messages: 190766 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Delete test_importhooks versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 19:43:50 2013 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Fri, 07 Jun 2013 17:43:50 +0000 Subject: [New-bugs-announce] [issue18159] ConfigParser getters not available on SectionProxy Message-ID: <1370627030.12.0.961792763365.issue18159@psf.upfronthosting.co.za> New submission from Jo?o Bernardo: The configparser.RawConfigParser class implements some `get` methods: get, getint, getfloat, getboolean but if any of these get overridden on a subclass(with other arguments) or new ones are added (e.g. getlist), there's no way a SectionProxy instance will be able to use them. class DemoParser(ConfigParser): def getlist(self, section, option): return self.get(section, option).split() parser = DemoParser() parser.read(some_file) # These 2 lines should be equivalent, like "getint", but the # second doesn't work because of the SectionProxy instance parser.getlist('some_section', 'foo') parser['some_section'].getlist('foo') Reading the code, for SectionProxy, it redefines all the get* methods from RawConfigParser, and that looks pretty bad... A more elegant approach would be to fetch the function on the parser instance and bound to the section name with `lambda` or `functools.partial`... Something like: class SectionProxy(...): ... def __getattr__(self, attr): if not attr.startswith('get'): raise AttributeError(attr) fn = getattr(self._parser, attr) return lambda *args, **kw: fn(self._name, *args, **kw) ---------- components: Library (Lib) messages: 190767 nosy: JBernardo priority: normal severity: normal status: open title: ConfigParser getters not available on SectionProxy type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 20:44:58 2013 From: report at bugs.python.org (=?utf-8?q?Tambet_V=C3=A4li?=) Date: Fri, 07 Jun 2013 18:44:58 +0000 Subject: [New-bugs-announce] [issue18160] Packaging more coherent Python Message-ID: <1370630698.76.0.469541388091.issue18160@psf.upfronthosting.co.za> New submission from Tambet V?li: Hello! First the issue: my usual way of installing programming environments, languages and platforms is to install all the available modules from standard repositories, or if there is some "all-good" or "batteries-included" metapackage, I sure install this. I surely favor installing Python packages through standard Linux repositories. In last year or so, the number of available libraries has grown 'exponentially' for Python in the Linux Mint (Debian) repositories. Some of them are not trivial to install - by simply installing python-prefixed packages, I got my Ubuntu broken, because Window Manager of this version of Linux won't display window borders, menus or anything to navigate around if it does not have OpenGL working - it just displays window content and one can do almost anything with it. I did not trust this installation anymore and I did install a new Linux, Debian Mint. To avoid this kind of problems, there should be python-prefixed metapackages, which contain library collections for different kinds of tasks (for example, web programming should interface me with all apache, mysql, postgres, etc., whereas game programming should give nice collection for sound and video). These collections should be safe and work well together, where possible, or be usable - because for good programming language, predefined set of good libraries is critical. So that I could choose all those metapackages, know that I can play around and still my system is safe. ---------- components: Installation messages: 190768 nosy: Tambet.V?li priority: normal severity: normal status: open title: Packaging more coherent Python type: enhancement versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 21:40:42 2013 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 07 Jun 2013 19:40:42 +0000 Subject: [New-bugs-announce] [issue18161] call fchdir if subprocess.Popen(cwd=integer|fileobject) Message-ID: <1370634042.31.0.748329507458.issue18161@psf.upfronthosting.co.za> New submission from ???? ?????????: Today, subprocess allow to change directory only by using its name. What if I have only file descriptor referring to that dir? It will be nice if such feture will be implemented. Now, I use preexc_fn to call os.fchdir() by hand. We should handle close_fds *AFTER* calling fchdir() :) ---------- components: Library (Lib) messages: 190770 nosy: mmarkk priority: normal severity: normal status: open title: call fchdir if subprocess.Popen(cwd=integer|fileobject) type: enhancement versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 22:51:00 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 07 Jun 2013 20:51:00 +0000 Subject: [New-bugs-announce] [issue18162] Add index attribute to IndexError Message-ID: <1370638259.99.0.240698145167.issue18162@psf.upfronthosting.co.za> New submission from Brett Cannon: Give IndexError an index attribute to store the index it was raised for. Since it is typically an integer there is no reason to worry about GC and thus using a regex. ---------- components: Interpreter Core messages: 190777 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Add index attribute to IndexError type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 22:51:56 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 07 Jun 2013 20:51:56 +0000 Subject: [New-bugs-announce] [issue18163] Add a 'key' attribute to KeyError Message-ID: <1370638316.1.0.167534610168.issue18163@psf.upfronthosting.co.za> New submission from Brett Cannon: KeyError could grow a 'key' attribute for the key that triggered the exception. Since keys are expected to be immutable (in order to be hashable) there is no GC issue to worry about. ---------- components: Interpreter Core messages: 190778 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Add a 'key' attribute to KeyError type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 22:52:24 2013 From: report at bugs.python.org (Ned Deily) Date: Fri, 07 Jun 2013 20:52:24 +0000 Subject: [New-bugs-announce] [issue18164] Embedding Python doc incorrectly refers to LINKFORSHARED Message-ID: <1370638344.32.0.268021495329.issue18164@psf.upfronthosting.co.za> New submission from Ned Deily: This is in reference to section 5.6 of the "Extending and Embedding Python" doc. This has come up recently where third-party projects are using LINKEDFORHARED instead of the results of python-config when linking an embedded Python into their projects. See discussion in Issue3588. Also, the updates to section 5.6 made for Python 3 should be backported to the Python 2.7 doc. http://docs.python.org/3/extending/embedding.html#compiling-and-linking-under-unix-like-systems http://docs.python.org/2/extending/embedding.html#linking-requirements ---------- assignee: ned.deily components: Documentation messages: 190779 nosy: ned.deily priority: normal severity: normal stage: needs patch status: open title: Embedding Python doc incorrectly refers to LINKFORSHARED versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 22:55:26 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 07 Jun 2013 20:55:26 +0000 Subject: [New-bugs-announce] [issue18165] Add 'unexpected_type' to TypeError Message-ID: <1370638526.17.0.473449662068.issue18165@psf.upfronthosting.co.za> New submission from Brett Cannon: TypeError could grow an 'unexpected_type' attribute to store the type of the argument that was used to trigger the exception. Since types are expected to not be deleted there is no GC worry. Having an 'expected' attribute makes no sense in the face of a union of types, etc. (unless the assumption of a frozenset is made for the attribute). Plus exceptions typically do not contain info on what would have been acceptable (although in this instance it may make sense). ---------- components: Interpreter Core messages: 190780 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Add 'unexpected_type' to TypeError type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 7 22:56:56 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 07 Jun 2013 20:56:56 +0000 Subject: [New-bugs-announce] [issue18166] 'value' attribute for ValueError Message-ID: <1370638616.72.0.719325929736.issue18166@psf.upfronthosting.co.za> New submission from Brett Cannon: A 'value attribute for ValueError could store a weakref to the value which triggered the exception. It should be a weakref so at to prevent accidental prevention of GC of the value. ---------- components: Interpreter Core messages: 190781 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: 'value' attribute for ValueError type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 8 02:46:59 2013 From: report at bugs.python.org (Chris AtLee) Date: Sat, 08 Jun 2013 00:46:59 +0000 Subject: [New-bugs-announce] [issue18167] cgi.FieldStorage fails to handle multipart/form-data when \r\n appears at end of 65535 bytes without other newlines Message-ID: <1370652419.33.0.211091292635.issue18167@psf.upfronthosting.co.za> New submission from Chris AtLee: cgi.FieldStorage uses fp.readline(1 << 16) to read in POSTed file data if no content length has been specified. All HTTP clients I've looked at terminate the file body with CRLF and then the final MIME boundary. If the file body is 65,535 bytes, and doesn't contain \n or \r\n, then fp.readline(1 << 16) will return the original 65,535 bytes of the file plus the \r from the final \r\n sequence before the final boundary string. Since \r isn't considered a line ending, it gets considered as part of the POSTed file data, and you end up with an extra \r at the end of the file data. ---------- components: Library (Lib) files: cgi-test-cpython.patch keywords: patch messages: 190784 nosy: catlee priority: normal severity: normal status: open title: cgi.FieldStorage fails to handle multipart/form-data when \r\n appears at end of 65535 bytes without other newlines type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file30502/cgi-test-cpython.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 8 05:52:16 2013 From: report at bugs.python.org (halfjuice) Date: Sat, 08 Jun 2013 03:52:16 +0000 Subject: [New-bugs-announce] [issue18168] plistlib output self-sorted dictionary Message-ID: <1370663536.42.0.663795573436.issue18168@psf.upfronthosting.co.za> New submission from halfjuice: Even with OrderedDict, the plistlib will still output the dict in its own order. Search for sorted(d.items()) in plistlib.py and you will know why. It is certainly warm-hearted to sort this before putting it into plist file but I think sometimes we just want a customized order. ---------- components: Library (Lib) messages: 190792 nosy: halfjuice priority: normal severity: normal status: open title: plistlib output self-sorted dictionary type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 8 21:22:48 2013 From: report at bugs.python.org (Roman Zeyde) Date: Sat, 08 Jun 2013 19:22:48 +0000 Subject: [New-bugs-announce] [issue18169] struct.pack() behaves strangely for 'L' on 64bit Linux Message-ID: <1370719368.01.0.165210926264.issue18169@psf.upfronthosting.co.za> New submission from Roman Zeyde: Reproduction: Python 2.7.4 (default, Apr 19 2013, 18:28:01) [GCC 4.7.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import struct >>> struct.pack('!L', 0x01020304) '\x01\x02\x03\x04' >>> struct.pack('>L', 0x01020304) '\x01\x02\x03\x04' >>> struct.pack('>> struct.pack('L', 0x01020304) '\x04\x03\x02\x01\x00\x00\x00\x00' ### WAT??? ### >>> As far as I see at the source code (http://hg.python.org/releasing/2.7.4/file/9290822f2280/Modules/_struct.c#l703), sizeof(long) is used as the size of 'L', which is equal to 8 at 64bit Linux... The problem is that the results of packing with 'L' returns 8 bytes, instead of 4 - as was expected from the documentation... ---------- components: Interpreter Core messages: 190817 nosy: Roman.Zeyde priority: normal severity: normal status: open title: struct.pack() behaves strangely for 'L' on 64bit Linux type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 9 01:54:59 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 08 Jun 2013 23:54:59 +0000 Subject: [New-bugs-announce] [issue18170] define built-in exceptions in Python code Message-ID: <1370735699.37.0.350073873785.issue18170@psf.upfronthosting.co.za> New submission from Brett Cannon: This quite possibly won't work because of performance, but I have been wondering how feasible it would be to define as many core exception types as possible in pure Python code and then freeze the module for loading. It would have the benefit of making maintenance easier (e.g. all of the PEP 3151 exceptions would have been simpler to add). It also would make it easier on other VMs by minimizing the number of exceptions that have to be written in their implementation language. Implementation-wise, it's probably easiest to start with leaf exceptions in the inheritance hierarchy and then slowly port more and more. Any exceptions ported to pure Python would have their PyExc_* variable set to their parent so that the variable is initialized to some exception before any Python code is touched. The real trick will come down to dealing with situations where some specific C API has been exposed (e.g. UnicodeError). Even if this experiment turns out to be feasible and reasonable in terms of simplifying C code, the other question is performance. If this costs more than a couple percent of overall performance (and quite possibly not even at that expense) this would not be worth it. ---------- components: Interpreter Core messages: 190837 nosy: brett.cannon priority: low severity: normal stage: needs patch status: open title: define built-in exceptions in Python code type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 9 12:51:10 2013 From: report at bugs.python.org (Pascal Garcia) Date: Sun, 09 Jun 2013 10:51:10 +0000 Subject: [New-bugs-announce] [issue18171] os.path.expanduser does not use the system encoding Message-ID: <1370775070.3.0.708484887412.issue18171@psf.upfronthosting.co.za> New submission from Pascal Garcia: The name of the user contains accents under windows. This error occurs when using the function. expaduser("~") UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 10: ordinal not in range(128) ascii is the default encoding as sys.getdefaultencoding() If in site.py "I enable Enable the support locale" then de defaultencoding become cp1252 and the function works. Expand user should use the encoding used by the system (may be locale.getdefaultlocale()) to decode path given by the system instead of the default encoding the should be the target encoding. I do beleave some other functions may be concerned by this problem. I detect the problem on Windows (WP and 7), but I do beleave the problem may happen on Linux also. ---------- components: Library (Lib) messages: 190850 nosy: plgarcia priority: normal severity: normal status: open title: os.path.expanduser does not use the system encoding versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 9 14:47:38 2013 From: report at bugs.python.org (flying sheep) Date: Sun, 09 Jun 2013 12:47:38 +0000 Subject: [New-bugs-announce] [issue18172] New easter egg: insecure string pickle Message-ID: <1370782058.78.0.671693022573.issue18172@psf.upfronthosting.co.za> New submission from flying sheep: the second meaning of the error message ?insecure string pickle? inspired at least two different people independently of drawing it. i?d wish for a link to one of those pics in the docstring or message of the error. picture: http://i.imgur.com/To3DQ6J.jpg thread: http://www.reddit.com/r/Python/comments/1fymy0/i_got_a_funny_error_trying_to_open_a_file_and/ we?d have to host the pic ourselves since imgur isn?t guaranteed to retain the picture (although that?d need many consecutive months of no one following the link) ---------- components: Library (Lib) messages: 190851 nosy: flying sheep priority: normal severity: normal status: open title: New easter egg: insecure string pickle type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 9 15:54:32 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 09 Jun 2013 13:54:32 +0000 Subject: [New-bugs-announce] [issue18173] Add MixedTypeKey to reprlib Message-ID: <1370786072.61.0.824503392112.issue18173@psf.upfronthosting.co.za> New submission from Nick Coghlan: Armin Ronacher pointed out that one downside of the removal of implicit cross-type comparisons in Python 3 is that it makes it harder to produce a stable repr for mixed-type containers. This seems like a valid point to me, so I propose adding a suitable "MixedTypeKey" definition to reprlib. Passing "key=reprlib.MixedTypeKey" would then reproduce the old Python 2. sorting behaviour. We can actually improve on the Python 2 approach by basing the fallback comparison on fully qualified type names rather than on the type id. Proposed implementation (see https://gist.github.com/ncoghlan/5743523): >>> class MixedTypeKey: ... """Sort key for mixed type lists in Python 3 ... ... >>> sorted([None, ..., 1, 1j, "", (), {}, []]) ... Traceback (most recent call last): ... File "", line 1, in ... TypeError: unorderable types: ellipsis() < NoneType() ... >>> sorted([None, ..., 1, 1j, "", (), {}, []], key=MixedTypeKey) ... [None, Ellipsis, 1, 1j, '', (), {}, []] ... """ ... def __init__(self, k): ... self._sort_key = k ... self._type_name = self._get_fully_qualified_name(k) ... def _get_fully_qualified_name(self, k): ... k_type = type(k) ... # Use __qualname__ if available, __name__ otherwise ... try: ... k_name = k_type.__qualname__ ... except AttributeError: ... k_name = k_type.__name__ ... return k_type.__module__ + "." + k_name ... def __lt__(self, other): ... # Try standard sorting first ... sort_key = self._sort_key ... try: ... other_sort_key = other._sort_key ... except AttributeError: ... other_sort_key = other ... try: ... return sort_key < other_sort_key ... except TypeError: ... pass ... # If that fails, sort by the fully qualified type names ... try: ... other_type_name = other._type_name ... except AttributeError: ... other_type_name = self._get_fully_qualified_name(other) ... return self._type_name < other_type_name ... >>> sorted([None, ..., 1, 1j, "", (), {}, []]) Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: ellipsis() < NoneType() >>> sorted([None, ..., 1, 1j, "", (), {}, []], key=MixedTypeKey) [None, 1j, {}, Ellipsis, 1, [], '', ()] >>> MixedTypeKey(None) < ... True The stdlib version could omit the fallback to __name__ (since it doesn't need to cope with old versions of Python) Support for other comparisons could theoretically be added, but I advise against it without a solid use case (sorting only needs __lt__). ---------- components: Library (Lib) messages: 190855 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Add MixedTypeKey to reprlib type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 9 21:47:53 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 09 Jun 2013 19:47:53 +0000 Subject: [New-bugs-announce] [issue18174] Make regrtest with --huntrleaks check for fd leaks Message-ID: <1370807273.91.0.83033499223.issue18174@psf.upfronthosting.co.za> New submission from Richard Oudkerk: regrtest already tests for refcount leaks and memory allocation leaks. It can also be made to check for file descriptor leaks (and perhaps also handles on Windows). Running with the attached patch makes it look like test_openpty, test_shutil, test_subprocess, test_uuid all leak fds on Linux, but I have not investigated: $ ./python -m test.regrtest -R 3:3 test_openpty test_shutil test_subprocess test_uuid [1/4] test_openpty 123456 ...... test_openpty leaked [2, 2, 2] fds, sum=6 [2/4/1] test_shutil beginning 6 repetitions 123456 ...... test_shutil leaked [4, 4, 4] fds, sum=12 [3/4/2] test_subprocess beginning 6 repetitions 123456 ...... test_subprocess leaked [5, 5, 5] fds, sum=15 [4/4/3] test_uuid beginning 6 repetitions 123456 ...... test_uuid leaked [1, 1, 1] fds, sum=3 4 tests failed: test_openpty test_shutil test_subprocess test_uuid ---------- files: fdleak.patch keywords: patch messages: 190871 nosy: sbt priority: normal severity: normal status: open title: Make regrtest with --huntrleaks check for fd leaks Added file: http://bugs.python.org/file30518/fdleak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 10 00:31:46 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 09 Jun 2013 22:31:46 +0000 Subject: [New-bugs-announce] [issue18175] os.listdir(fd) leaks fd on error Message-ID: <1370817106.33.0.219931679645.issue18175@psf.upfronthosting.co.za> New submission from Richard Oudkerk: If os.listdir() is used with an fd, but fdopendir() fails (e.g. if the the fd is a normal file) then a duplicated fd is leaked. This explains the leaks in test_shutil mentioned in #18174. ---------- messages: 190875 nosy: sbt priority: normal severity: normal status: open title: os.listdir(fd) leaks fd on error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 10 02:15:03 2013 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 10 Jun 2013 00:15:03 +0000 Subject: [New-bugs-announce] [issue18176] Builtins documentation refers to old version of UCD. Message-ID: <1370823303.7.0.563688972804.issue18176@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Reference to http://www.unicode.org/Public/6.0.0/ucd/extracted/DerivedNumericType.txt in http://docs.python.org/3.4/library/stdtypes.html#numeric-types-int-float-complex should be changed to http://www.unicode.org/Public/6.1.0/ucd/extracted/DerivedNumericType.txt for 3.3 and to http://www.unicode.org/Public/6.2.0/ucd/extracted/DerivedNumericType.txt for 3.4. Note that the change from 6.1 to 6.2 is immaterial because it did not involve the Nd category, but a change from 6.0 to 6.1 introduced several new ranges: +110F0..110F9 ; Decimal # Nd [10] SORA SOMPENG DIGIT ZERO..SORA SOMPENG DIGIT NINE +11136..1113F ; Decimal # Nd [10] CHAKMA DIGIT ZERO..CHAKMA DIGIT NINE +111D0..111D9 ; Decimal # Nd [10] SHARADA DIGIT ZERO..SHARADA DIGIT NINE +116C0..116C9 ; Decimal # Nd [10] TAKRI DIGIT ZERO..TAKRI DIGIT NINE ---------- messages: 190878 nosy: belopolsky priority: normal severity: normal status: open title: Builtins documentation refers to old version of UCD. versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 10 04:03:00 2013 From: report at bugs.python.org (icedream91) Date: Mon, 10 Jun 2013 02:03:00 +0000 Subject: [New-bugs-announce] [issue18177] Typo in Documents Message-ID: <1370829780.84.0.0627044566719.issue18177@psf.upfronthosting.co.za> New submission from icedream91: In library.pdf file(Release 3.3.2, June 09, 2013), I found a typo in page 149: I think the quotation marks are wrong in "datetime.isoformat(sep=?T?)" sentence, they should both be "'". But it's right in online documents (http://docs.python.org/3/library/datetime.html#datetime.datetime.isoformat). Thanks. ---------- assignee: docs at python components: Documentation messages: 190882 nosy: docs at python, icedream91 priority: normal severity: normal status: open title: Typo in Documents versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 10 10:11:18 2013 From: report at bugs.python.org (rm) Date: Mon, 10 Jun 2013 08:11:18 +0000 Subject: [New-bugs-announce] [issue18178] Redefinition of malloc(3) family of functions at build time Message-ID: <1370851878.25.0.593003779218.issue18178@psf.upfronthosting.co.za> New submission from rm: Hello. Marcel Moolenaar (marcel at FreeBSD.org) pointed this out after committing FreeBSD revision 250991 [1], that makes the malloc(3) family of functions weak symbols. I'm citing him, because (silly me) I don't understand all of this completely: """ After my commit to head that makes the malloc(3) family of functions weak symbols, a bug in what appears to be the Python build was exposed. The net effect of the bug is that _ctypes.so contains (strong) definitions of the malloc(3) family of functions and resulting in unintended symbol resolution. _ctypes.so incorporates the libffi functionality for what I presume is the basis for Python bindings. libffi includes dlmalloc.c, an open source allocator. dlmalloc.c is incuded by closures.c and closures.c defines USE_DL_PREFIX. On top of that closures.c makes all allocator functions static. This, therefore adds a memory allocator to libffi without exposure of standard symbols In short: dlmalloc.c never gets compiler separately or independently for this reason. The python build however compiles dlmalloc.c separately/independently. As such, dlmalloc.c now defines and exports the malloc(3) family of functions and it also get linked into _ctypes.so. Thus when libffi is built as part of the Python build, the set of symbols exported is different from when libffi is compiled as a port. The simplest test case is this (on a -current machines): 1. Build & install lang/python27 (unmodified; if needed) 2. try and build databases/py-sqlite3 The build of databases/py-sqlite3 fails because this: running config *** Signal 11 On amd64 I observed an assertion failure of FreeBSD's malloc, with the same effect. Manually triggering this: fbsdvm% pwd /usr/ports/databases/py-sqlite3/work/Python-2.7.5/Modules fbsdvm% /usr/local/bin/python2.7 setup.py config running config Segmentation fault But if symbols are resolved non-lazily, things change: fbsdvm% setenv LD_BIND_NOW yes fbsdvm% /usr/local/bin/python2.7 setup.py config running config This demonstrates how, after loading _ctypes.so, malloc(3) and friends get resolved differently and thus inconsistently from before. The publicly visible symbols in _ctypes.so, also show the problem: fbsdvm% nm /usr/local/lib/python2.7/lib-dynload/_ctypes.so | grep ' T ' | egrep '(alloc)|(free)' 0000c3f0 T _ctypes_alloc_callback 00005250 T _ctypes_alloc_format_string 00016d10 T calloc 000121e0 T ffi_closure_alloc 00013760 T ffi_closure_free 00016050 T free 000170c0 T independent_calloc 000172d0 T independent_comalloc 000148e0 T malloc 00017460 T malloc_footprint 00017480 T malloc_max_footprint 000175c0 T malloc_stats 00017440 T malloc_trim 000176e0 T malloc_usable_size 000173a0 T pvalloc 00016d90 T realloc 00017310 T valloc There are definitions of malloc(3) and friends that shouldn't be there. """ We have similar reports in our bug-tracker [2] and [3]. And the patch attached fixes this for post-r250991 versions of FreeBSD, and noop for earlier versions. The same patch applied to python2.7, python3.2, python3.3 and patched in FreeBSD ports tree locally. [1] http://svnweb.freebsd.org/changeset/base/250991 [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/179102 [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/179413 ---------- components: ctypes files: patch-Modules-_ctypes-libffi_fficonfig.py.in messages: 190892 nosy: cvs-src priority: normal severity: normal status: open title: Redefinition of malloc(3) family of functions at build time type: crash versions: Python 2.7 Added file: http://bugs.python.org/file30522/patch-Modules-_ctypes-libffi_fficonfig.py.in _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 10 12:24:28 2013 From: report at bugs.python.org (Jonas H.) Date: Mon, 10 Jun 2013 10:24:28 +0000 Subject: [New-bugs-announce] [issue18179] SMTP.local_hostname is undocumented Message-ID: <1370859868.96.0.822120662228.issue18179@psf.upfronthosting.co.za> New submission from Jonas H.: The Sphinx docs don't contain any explanation for `local_hostname`. ---------- assignee: docs at python components: Documentation messages: 190898 nosy: docs at python, jonash priority: normal severity: normal status: open title: SMTP.local_hostname is undocumented versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 10 13:54:25 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 10 Jun 2013 11:54:25 +0000 Subject: [New-bugs-announce] [issue18180] Refleak in test_imp on Windows Message-ID: <1370865265.03.0.501914398945.issue18180@psf.upfronthosting.co.za> New submission from Richard Oudkerk: Seems to be in error path of _PyImport_GetDynLoadWindows(). ---------- files: load_dynamic.patch keywords: patch messages: 190901 nosy: sbt priority: normal severity: normal status: open title: Refleak in test_imp on Windows Added file: http://bugs.python.org/file30524/load_dynamic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 10 15:15:53 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 10 Jun 2013 13:15:53 +0000 Subject: [New-bugs-announce] [issue18181] super vs. someclass.__getattribute__ Message-ID: <1370870153.93.0.646087371852.issue18181@psf.upfronthosting.co.za> New submission from Ronald Oussoren: Super() walks the MRO and looks for the looked-up attribute in the __dict__ of types on the MRO. This can cause problems when classes implement __getattribute__: a class on the MRO can implement a method that super() won't find because it isn't in the class __dict__ (yet). I'm running into this with PyObjC: the __dict__ for the Python proxies for Objective-C classes are filled lazily (*) by tp_getattro (__getattribute__ in Python) to speed up the bridge and because ObjC is almost as dynamic as Python and methods might appear during runtime (without there being a hook for detecting such changes). A possible solution to this: * Add a tp_getattro_super (**) slot to PyTypeObject, with the same signature as tp_getattro, but that only looks at this particular class (as opposed to tp_getattro that walks the entire MRO and looks in the object's __dict__) (***) * The tp_gettro of super calls tp_getattro_super of types of along the MRO when that slot is not NULL, and uses the current implementation (look in tp_dict) when the slot is NULL. Would such a change be acceptable? Open issues: * Does the new slot get exposed to Python code (and if so, under which name)? * Should PyObject_GenericGetAttr use the new slot as well? Footnotes: (*) The current release of PyObjC (2.5) eagerly tries to keep the proxy class __dict__ up to date, an upcoming major release will be as lazy as possible to speed up the bridge. The problem can with some effert be triggered with PyObjC 2.5, and triggering it is easy in the upcoming major release (**) Or some better name (***) I'm being very sloppy in my use of terminology here, hopefully my proposal is clear enough anyway. ---------- components: Interpreter Core messages: 190905 nosy: ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: super vs. someclass.__getattribute__ type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 10 15:59:13 2013 From: report at bugs.python.org (Alexander Tobias Heinrich) Date: Mon, 10 Jun 2013 13:59:13 +0000 Subject: [New-bugs-announce] [issue18182] xml.dom.createElement() does not take implicit namespaces into account Message-ID: <1370872753.13.0.359771001968.issue18182@psf.upfronthosting.co.za> New submission from Alexander Tobias Heinrich: First of all, I am not sure, if this is a bug in python itself - it could as well be a bug in the py-dom-xpath module (http://code.google.com/p/py-dom-xpath) or not a bug at all (but I find the latter to be highly unlikely). Consider an XML document such as: If one creates a new Chimp-element using the xml.dom.createElement() function and then appends it to the Compound element, then the xpath module will not find the element unless the whole document is saved and then re-parsed. Creating the element with xml.dom.createElementNS() and thus explicitly specifying its namespace works around the problem. I consider this to be a bug, because in both cases, xml.dom will create the same valid XML, so I believe xpath should produce the same results in both cases, too. My believe, that the bug is in xml.dom is just a feeling and I could be wrong. I imagine, that xml.dom.createElement() forgets about adding the new element to its inherited namespace and adds it to the null namespace instead. In consequence xpath doesn't find the new element. I originally posted a more verbose explanation of this issue to StackOverflow (see http://stackoverflow.com/questions/16980521/python-xpath-find-wont-find-new-elements-if-they-were-added-without-namespac ), because I was unsure about whether this is a bug or not - and if it was, then in which module. Because I did not receive any feedback on that post, I have now decided to file it here as a bug report. I attached a sample script that demonstrates the problem if (xpath dependency is installed). I tested it under Windows with Python 2.7.5 and 2.7.4. ---------- components: XML files: pydomprob.py messages: 190906 nosy: Alexander.Tobias.Heinrich priority: normal severity: normal status: open title: xml.dom.createElement() does not take implicit namespaces into account type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file30527/pydomprob.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 10 16:20:36 2013 From: report at bugs.python.org (Dave Challis) Date: Mon, 10 Jun 2013 14:20:36 +0000 Subject: [New-bugs-announce] [issue18183] Calling .lower() on certain unicode string raises SystemError Message-ID: <1370874036.73.0.39673641693.issue18183@psf.upfronthosting.co.za> New submission from Dave Challis: This occurred when attempting to decode invalid UTF-8 bytes using "errors='replace'", then attempting to lowercase the produced unicode string. This was also tested in python 2.7, but it doesn't occur there. Code to reproduce: x = b'\xe2\xb3\x99\xb3\xd1\x9f\xe0vjGd|\x12\xf2\x84\xac\xae&$\xa4\xae+\xa4sbtf$&fG\xfb\xe6?.\xe2sbv\x14\xcb\x89\x98\xda\xd9\x99\xda\xb9d9\x1bY\x99\xb7\xb3\x1b9\xa2y*B\xa3\xba\xefj&g\xe2\x92Et\x85~\xbf\x8a\xe3\x919\x8bvc\xfb#$$.\xber6D&b.#4\xa4.\x13RtI\x10\xed\x9c\xd0\x98\xb8\x18\x91\x99\\\nC\x13\x8dV\xccL\xf4\x89\x9c\x90' x = x.decode('utf-8', errors='replace') x.lower() Output: Traceback (most recent call last): File "", line 1, in SystemError: invalid maximum character passed to PyUnicode_New ---------- components: Unicode messages: 190907 nosy: davechallis, ezio.melotti priority: normal severity: normal status: open title: Calling .lower() on certain unicode string raises SystemError type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 10 23:00:13 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 10 Jun 2013 21:00:13 +0000 Subject: [New-bugs-announce] [issue18184] Add range check for %c in PyUnicode_FromFormat Message-ID: <1370898013.19.0.579439947433.issue18184@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently PyUnicode_FromFormat doesn't check an argument for %c and can raise SystemError only due maxchar check in PyUnicode_New. On 2.7 an error doesn't raised, but %c argument can be silently wrapped (on narrow build) or illegal Unicode string can be created (on wide build). The proposed patch adds explicit range check for %c argument. ---------- components: Interpreter Core, Unicode files: format_c.diff keywords: patch messages: 190935 nosy: ezio.melotti, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add range check for %c in PyUnicode_FromFormat type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30535/format_c.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 11 04:06:08 2013 From: report at bugs.python.org (Sye van der Veen) Date: Tue, 11 Jun 2013 02:06:08 +0000 Subject: [New-bugs-announce] [issue18185] Error in test_set.TestVariousIteratorArgs.test_inline_methods Message-ID: <1370916368.79.0.653461926178.issue18185@psf.upfronthosting.co.za> New submission from Sye van der Veen: I'm working with Python's test suite and noticed this error: http://hg.python.org/cpython/file/668aba845fb2/Lib/test/test_set.py#l1669 # etc... for g in (G, I, Ig, L, R): expected = meth(data) actual = meth(G(data)) # etc... I believe the assignment to actual should be using a lower-case 'g'. ---------- components: Tests messages: 190941 nosy: syeberman priority: normal severity: normal status: open title: Error in test_set.TestVariousIteratorArgs.test_inline_methods type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 11 11:01:10 2013 From: report at bugs.python.org (Daniel Farina) Date: Tue, 11 Jun 2013 09:01:10 +0000 Subject: [New-bugs-announce] [issue18186] 2.x subprocess contains set notation Message-ID: <1370941270.02.0.283113352418.issue18186@psf.upfronthosting.co.za> New submission from Daniel Farina: I was vendoring subprocess to pick up the change for #16327 when I noticed I could not import it on 2.6. The backwards compatibility claim at the top is 2.2. Included is a tiny patch that uses a semantically equivalent form. ---------- components: Library (Lib) files: old-set-notation-v1.patch keywords: patch messages: 190953 nosy: Daniel.Farina priority: normal severity: normal status: open title: 2.x subprocess contains set notation versions: Python 2.6 Added file: http://bugs.python.org/file30542/old-set-notation-v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 11 12:11:42 2013 From: report at bugs.python.org (Berker Peksag) Date: Tue, 11 Jun 2013 10:11:42 +0000 Subject: [New-bugs-announce] [issue18187] Fix broken link in Doc/library/venv.rst Message-ID: <1370945502.31.0.379254379799.issue18187@psf.upfronthosting.co.za> New submission from Berker Peksag: The correct location of the venv module is Lib/venv, not Lib/venv.py. Attaching a simple patch that fixes the location. ---------- assignee: docs at python components: Documentation files: venv-location.diff keywords: patch messages: 190958 nosy: berker.peksag, docs at python priority: normal severity: normal status: open title: Fix broken link in Doc/library/venv.rst versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30543/venv-location.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 11 12:32:08 2013 From: report at bugs.python.org (Shlomi Fish) Date: Tue, 11 Jun 2013 10:32:08 +0000 Subject: [New-bugs-announce] [issue18188] ERROR: test_no_optimize_flag on Mageia Linux Cauldron x86-64 with certain configure flags Message-ID: <1370946728.63.0.485742635949.issue18188@psf.upfronthosting.co.za> New submission from Shlomi Fish: After I build Python-3.3.2 from the .tar.xz using the following script (on Mageia Linux Cauldron x86-64): <<< #!/bin/bash ./configure --prefix="$HOME/apps/python3" --with-threads \ --enable-ipv6 --with-dbmliborder=gdbm \ --with-system-expat \ --with-system-ffi \ --enable-shared \ --with-valgrind shlomif at telaviv1:~/Download/unpack/prog/python/Python-3.3.2$ >>> then I get this test failure in the ?test_no_optimize_flag?: [ QUOTE ] ====================================================================== ERROR: test_no_optimize_flag (distutils.tests.test_bdist_rpm.BuildRpmTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shlomif/Download/unpack/prog/python/Python-3.3.2/Lib/distutils/tests/test_bdist_rpm.py", line 125, in test_no_optimize_flag cmd.run() File "/home/shlomif/Download/unpack/prog/python/Python-3.3.2/Lib/distutils/command/bdist_rpm.py", line 366, in run self.spawn(rpm_cmd) File "/home/shlomif/Download/unpack/prog/python/Python-3.3.2/Lib/distutils/cmd.py", line 366, in spawn spawn(cmd, search_path, dry_run=self.dry_run) File "/home/shlomif/Download/unpack/prog/python/Python-3.3.2/Lib/distutils/spawn.py", line 32, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/home/shlomif/Download/unpack/prog/python/Python-3.3.2/Lib/distutils/spawn.py", line 163, in _spawn_posix % (cmd[0], exit_status)) distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1 https://bugs.mageia.org/show_bug.cgi?id=9395 [ / QUOTE] More info can be found at http://bugs.python.org/issue18142 . Please look into fixing it. Regards, -- Shlomi Fish ---------- components: Tests messages: 190959 nosy: shlomif priority: normal severity: normal status: open title: ERROR: test_no_optimize_flag on Mageia Linux Cauldron x86-64 with certain configure flags versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 11 13:30:19 2013 From: report at bugs.python.org (R. Jayakrishnan) Date: Tue, 11 Jun 2013 11:30:19 +0000 Subject: [New-bugs-announce] [issue18189] IDLE Improvements: Unit test for Delegator.py Message-ID: <1370950219.82.0.574615156859.issue18189@psf.upfronthosting.co.za> New submission from R. Jayakrishnan: Continuing the IDLE unittest framework initiated in http://bugs.python.org/issue15392. A small unit test for IDLE Delegator.py module. This patch introduces a test module named test_delegator.py inside Lib/idlelib/idle_test, considering the points README file in idle_test. The test method test_setdelegate() simply passes a text widget to Delegator by calling setdelegate(), and test the widget returned by getdelegate() for the same. ---------- components: IDLE files: test_delegator.patch keywords: patch messages: 190960 nosy: JayKrish priority: normal severity: normal status: open title: IDLE Improvements: Unit test for Delegator.py type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30544/test_delegator.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 11 16:40:35 2013 From: report at bugs.python.org (Harry Bock) Date: Tue, 11 Jun 2013 14:40:35 +0000 Subject: [New-bugs-announce] [issue18190] RuntimeError raised with re.search + re.DOTALL on empty string Message-ID: <1370961635.12.0.751109303707.issue18190@psf.upfronthosting.co.za> New submission from Harry Bock: In Python 2.7.5, running re.search on regular expressions beginning with '.+' will raise RuntimeError if: * the string being matched is empty * the flags include re.DOTALL/re.S >>> re.search(".+a", "", flags=re.S) File "C:\Python27\lib\site-packages\IPython\core\interactiveshell.py", line 2731, in run_code exec code_obj in self.user_global_ns, self.user_ns File "", line 1, in myre.search("") RuntimeError: internal error in regular expression engine This does not occur if the input string is not empty, or if re.match is used instead of re.search, or if the re.S flag is omitted. The bug does not occur on previous versions of Python 2.x, including 2.7.4. ---------- components: Regular Expressions messages: 190966 nosy: ezio.melotti, hbock, mrabarnett priority: normal severity: normal status: open title: RuntimeError raised with re.search + re.DOTALL on empty string type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 11 16:44:39 2013 From: report at bugs.python.org (Julien Danjou) Date: Tue, 11 Jun 2013 14:44:39 +0000 Subject: [New-bugs-announce] [issue18191] urllib2/urllib.parse.splitport does not handle IPv6 correctly Message-ID: <1370961879.5.0.532150427937.issue18191@psf.upfronthosting.co.za> New submission from Julien Danjou: >>> import urllib.parse >>> urllib.parse.splitport("::1") (':', '1') This is obviously invalid. ---------- components: Library (Lib) messages: 190968 nosy: jd priority: normal severity: normal status: open title: urllib2/urllib.parse.splitport does not handle IPv6 correctly 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 Jun 11 22:44:04 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 11 Jun 2013 20:44:04 +0000 Subject: [New-bugs-announce] [issue18192] Move imp.get_magic() to importlib Message-ID: <1370983444.92.0.65091801701.issue18192@psf.upfronthosting.co.za> New submission from Brett Cannon: As part of deprecating imp, need to move imp.get_magic() to importlib where it now belongs. Will be exposed as an attribute instead of a function, though. ---------- components: Library (Lib) messages: 190981 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Move imp.get_magic() to importlib versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 11 22:45:11 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 11 Jun 2013 20:45:11 +0000 Subject: [New-bugs-announce] [issue18193] Move imp.reload() to importlib Message-ID: <1370983511.06.0.645112750282.issue18193@psf.upfronthosting.co.za> New submission from Brett Cannon: For convenience it should live directly off of importlib and not importlib.util. ---------- components: Library (Lib) messages: 190982 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Move imp.reload() to importlib versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 11 22:47:03 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 11 Jun 2013 20:47:03 +0000 Subject: [New-bugs-announce] [issue18194] Move imp.source_from_cache/cache_from_source to importlib Message-ID: <1370983623.04.0.860337452651.issue18194@psf.upfronthosting.co.za> New submission from Brett Cannon: To facilitate deprecating imp, need to move imp.source_from_cache() and cache_from_source() to importlib.util or as static methods on importlib.machinery.SourceLoader. ---------- components: Library (Lib) messages: 190983 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Move imp.source_from_cache/cache_from_source to importlib versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 12 00:45:32 2013 From: report at bugs.python.org (mrjbq7) Date: Tue, 11 Jun 2013 22:45:32 +0000 Subject: [New-bugs-announce] [issue18195] error when deep copying module is confusing Message-ID: <1370990732.59.0.654966118724.issue18195@psf.upfronthosting.co.za> New submission from mrjbq7: If you have a simple module (say "foo.py"): $ cat foo.py bar = 1 You get weird errors when trying to deep copy them (which I did by accident, not intentionally trying to deep copy modules): Python 2.7.2: >>> import foo >>> import copy >>> copy.deepcopy(foo) Traceback (most recent call last): File "", line 1, in File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 190, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 334, in _reconstruct state = deepcopy(state, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 163, in deepcopy y = copier(x, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 257, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 163, in deepcopy y = copier(x, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 257, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 190, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 329, in _reconstruct y = callable(*args) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy_reg.py", line 93, in __newobj__ return cls.__new__(cls, *args) TypeError: object.__new__(NotImplementedType) is not safe, use NotImplementedType.__new__() Python 3.3.2: >>> import foo >>> import copy >>> copy.deepcopy(foo) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.3/copy.py", line 174, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/usr/lib/python3.3/copy.py", line 301, in _reconstruct y.__dict__.update(state) AttributeError: 'NoneType' object has no attribute 'update' I'm not expecting to be able to deep copy a module, but it would be really great if it is not possible for the error message to say something like "deepcopy doesn't work for modules" rather than two different funky tracebacks that don't really explain the problem... Thanks, ---------- messages: 190996 nosy: mrjbq7 priority: normal severity: normal status: open title: error when deep copying module is confusing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 12 05:20:33 2013 From: report at bugs.python.org (Roger Serwy) Date: Wed, 12 Jun 2013 03:20:33 +0000 Subject: [New-bugs-announce] [issue18196] IDLE: forward apply patch for handling SystemExit Message-ID: <1371007233.82.0.0390159251256.issue18196@psf.upfronthosting.co.za> New submission from Roger Serwy: As a formality, I opened this issue to apply 872a3aca2120 to the 3.x branch. This addresses a concern brought up by Terry in msg187323 from issue5492. Here's the relevant part of the message: """ Without or with patch, quit() or exit brings up TK box (?) The program is still running! Do you want to kill it? [OK] [Cancel] Did this always happen? [Cancel] causes traceback (not good, regression?) Traceback (most recent call last): File "", line 1, in quit() File "D:\Python\dev\cpython\lib\site.py", line 356, in __call__ raise SystemExit(code) SystemExit: None """ ---------- assignee: roger.serwy components: IDLE files: catch_exit.patch keywords: patch messages: 191007 nosy: rhettinger, roger.serwy, terry.reedy priority: low severity: normal stage: patch review status: open title: IDLE: forward apply patch for handling SystemExit type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30551/catch_exit.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 12 08:25:59 2013 From: report at bugs.python.org (Max DeLiso) Date: Wed, 12 Jun 2013 06:25:59 +0000 Subject: [New-bugs-announce] [issue18197] insufficient error checking causes crash on windows Message-ID: <1371018359.58.0.123065301657.issue18197@psf.upfronthosting.co.za> New submission from Max DeLiso: hi. if you cross compile the mercurial native extensions against python 2.7.5 (x64) on 64 bit windows 7 and then try to clone something, it will crash. I believe the reason for this is that the c runtime functions in the microsoft crt will throw a win32 exception if they are given invalid parameters, and since the return value of fileno() is not checked in Objects/fileobject.c, if a file handle is passed to fileno and the result is not a valid file descriptor, that invalid decriptor will get passed to _fstat64i32, an invalid parameter exception will be raised, and the program will crash. here's the function with the alleged bug: static PyFileObject* dircheck(PyFileObject* f) { #if defined(HAVE_FSTAT) && defined(S_IFDIR) && defined(EISDIR) struct stat buf; if (f->f_fp == NULL) return f; if (fstat(fileno(f->f_fp), &buf) == 0 && // this line is the problem, fileno's return value never gets checked S_ISDIR(buf.st_mode)) { char *msg = strerror(EISDIR); PyObject *exc = PyObject_CallFunction(PyExc_IOError, "(isO)", EISDIR, msg, f->f_name); PyErr_SetObject(PyExc_IOError, exc); Py_XDECREF(exc); return NULL; } #endif return f; } here's the stack trace: > msvcr90.dll!_invalid_parameter () Unknown msvcr90.dll!_fstat64i32 () Unknown python27.dll!dircheck(PyFileObject * f) Line 127 C python27.dll!fill_file_fields(PyFileObject * f, _iobuf * fp, _object * name, char * mode, int (_iobuf *) * close) Line 183 C python27.dll!PyFile_FromFile(_iobuf * fp, char * name, char * mode, int (_iobuf *) * close) Line 484 C here's a dump summary: Dump Summary ------------ Process Name: python.exe : c:\Python27\python.exe Process Architecture: x64 Exception Code: 0xC0000417 Exception Information: Heap Information: Present about the patch: the attached patch fixes that behavior and doesn't break any test cases on windows or linux. it applies against the current trunk of cpython. the return value of fileno should get checked for correctness anyways, even on *nix. the extra overhead is tiny, (one comparison and a conditional jump and a few extra bytes of stack space), but you do catch some weird edge cases. here are the steps to reproduce: download the python 2.7.5 installer for windows download the mercurial 2.6.2 source release build the native extensions with 64 bit microsoft compilers try to hg clone any remote repo (it should crash) here are some version strings: Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on win32 Microsoft (R) C/C++ Optimizing Compiler Version 17.00.60315.1 for x64 mercurial 2.6.2 here are some links: in particular, read the bits about the invalid parameter exception: _fsta64i32: http://msdn.microsoft.com/en-US/library/221w8e43%28v=vs.80%29.aspx _fileno: http://msdn.microsoft.com/en-US/library/zs6wbdhx%28v=vs.80%29.aspx Please let me know if my patch needs work or if I missed something. Thanks! ---------- components: IO files: fileobject_fix.patch hgrepos: 199 keywords: patch messages: 191012 nosy: maxdeliso priority: normal severity: normal status: open title: insufficient error checking causes crash on windows type: crash versions: Python 2.7 Added file: http://bugs.python.org/file30552/fileobject_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 12 10:01:19 2013 From: report at bugs.python.org (vila) Date: Wed, 12 Jun 2013 08:01:19 +0000 Subject: [New-bugs-announce] [issue18198] unittest discover should provide a way to define discovery at package level Message-ID: <1371024079.21.0.947683959467.issue18198@psf.upfronthosting.co.za> New submission from vila: While most test suites are a tree with test_*.py files, there are cases where being able to define the discovery for a subtree in the package __init__.py file comes handy. A poc implementation is available at http://bazaar.launchpad.net/~canonical-isd-qa/selenium-simple-test/trunk/view/head:/src/sst/tests/test_loader.py http://bazaar.launchpad.net/~canonical-isd-qa/selenium-simple-test/trunk/view/head:/src/sst/loader.py It allows test writers to define their own discovery when needed (including a specific edge case for the project mentioned above: test scripts that should not be imported at load time). It also addresses http://bugs.python.org/issue16662 ---------- messages: 191015 nosy: vila priority: normal severity: normal status: open title: unittest discover should provide a way to define discovery at package level _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 12 17:24:41 2013 From: report at bugs.python.org (Daniel Sturm) Date: Wed, 12 Jun 2013 15:24:41 +0000 Subject: [New-bugs-announce] [issue18199] No long filename support for Windows Message-ID: <1371050681.12.0.381093438517.issue18199@psf.upfronthosting.co.za> New submission from Daniel Sturm: Python at the moment does not handle paths with more than MAX_PATH characters well under Windows. With Windows 7 x64, Python 3.3 32bit, the attached file fails with: Traceback (most recent call last): File ".\filename_bug.py", line 4, in os.makedirs(dir) File "C:\Python33\lib\os.py", line 269, in makedirs mkdir(name, mode) FileNotFoundError: [WinError 3] The system cannot find the path specified: './aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb' Same things apply to os.rmdir and probably other functions. The problem is that in posixmodule.c:path_converter (which is used to get the wchar_t* pathname that is expected by the Win32 API) we do have the following check: length = PyUnicode_GET_SIZE(unicode); if (length > 32767) { FORMAT_EXCEPTION(PyExc_ValueError, "%s too long for Windows"); Py_DECREF(unicode); return 0; } wide = PyUnicode_AsUnicode(unicode); but the documentation states: "The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path"." Source: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx The problem is that we never prepend "\\?\" to the pathname hence getting the old MAX_PATH limit. To fix this the easiest solution would be to change the unicode code path of the function to always return an absolute path (relative paths are always limited by MAX_PATH) with \\?\. For optimization we could only do this if the path is longer than 248 (CreateDir has another interesting exception there..) resp. MAX_CHAR characters. ---------- components: Unicode, Windows files: filename_bug.py messages: 191033 nosy: Voo, ezio.melotti priority: normal severity: normal status: open title: No long filename support for Windows Added file: http://bugs.python.org/file30563/filename_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 12 23:01:48 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Jun 2013 21:01:48 +0000 Subject: [New-bugs-announce] [issue18200] Update stdlib to use ModuleNotFoundError Message-ID: <1371070908.67.0.272178306242.issue18200@psf.upfronthosting.co.za> New submission from Brett Cannon: The common idiom:: try: import something except ImportError: pass should be updated to use ModuleNotFoundError instead to not accidentally swallow ImportError exceptions which signal actual errors. ---------- components: Library (Lib) keywords: easy messages: 191047 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Update stdlib to use ModuleNotFoundError versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 13 07:18:55 2013 From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=) Date: Thu, 13 Jun 2013 05:18:55 +0000 Subject: [New-bugs-announce] [issue18201] distutils write into symlinks instead of replacing them Message-ID: <1371100735.33.0.721782392161.issue18201@psf.upfronthosting.co.za> New submission from Micha? G?rny: We're doing heavy wrapping of Python scripts on Gentoo in order to efficiently support having multiple versions of Python installed. For that reason, every Python script installed using the package manager is renamed, and a symlink to a common wrapper binary is installed in its place. For example, setuptools install looks like: /usr/bin/easy_install -> python-exec /usr/bin/easy_install-python2.7 /usr/bin/easy_install-python3.2 Using the wrappers like this allow us to actively support user preference of Python version and map it to supported ones. Symlinking a common binary makes this more maintainable since there's just one place where wrapper needs to be updated. However, it seems that setup.py is failing hard in replacing symlinks. Whenever user upgrades any installed package, either externally or due to some tool like easy_install or pip, the relevant setup.py writes into /usr/bin/easy_install rather than properly replacing it with a new file. The effect, as you may imagine, is the wrapper being replaced with a random Python script and system-wide breakage. The proper thing to do would be to write into temporary file in the destination directory, then use os.rename() to atomically replace the destination with the temporary file. Since distutils is no longer maintained, I would be equally happy with simply os.remove() before writing the scripts. The problem may affect distutils2 as well. ---------- assignee: eric.araujo components: Distutils messages: 191057 nosy: eric.araujo, mgorny, tarek priority: normal severity: normal status: open title: distutils write into symlinks instead of replacing them versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 13 10:03:07 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 13 Jun 2013 08:03:07 +0000 Subject: [New-bugs-announce] [issue18202] Minor fixes for test_coding Message-ID: <1371110587.57.0.733906103611.issue18202@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which contains followed changes: * Use bytes in test_exec_valid_coding(). Encoding instruction is ignored in strings. * Use non-ascii data in test_exec_valid_coding() to check that encoding is working. * Use explicit file encoding in test_file_parse(). * Use with statement for file in test_file_parse(). * Modify sys.path after opening file in test_file_parse() and restore before other cleanups. * Cleanup '.pyo' file in test_file_parse(). Test can ran in optimized mode. * Add msg parameter for better failure reporting in test_error_from_string(). * Use unittest.main(). ---------- components: Tests files: test_coding.patch keywords: patch messages: 191066 nosy: lemburg, loewis, nnorwitz, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Minor fixes for test_coding type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30569/test_coding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 13 12:52:39 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 13 Jun 2013 10:52:39 +0000 Subject: [New-bugs-announce] [issue18203] Replace calls to malloc() with PyMem_Malloc() Message-ID: <1371120759.62.0.420345272246.issue18203@psf.upfronthosting.co.za> New submission from STINNER Victor: The issue #3329 proposes an API to replace memory allocator functions. But Python calls directly malloc(), realloc() and free() in some functions, so custom allocators would not be used there. Examples of functions calling malloc/realloc/free directly: _PySequence_BytesToCharpArray(), block_new() (of pyarena.c), find_key() (of thread.c), PyInterpreterState_New(), win32_wchdir(), posix_getcwd(), Py_Main(), etc. We have to be careful with the GIL: PyMem_*() functions can only be called when holding the GIL. ---------- messages: 191076 nosy: amaury.forgeotdarc, haypo, kristjan.jonsson, ncoghlan priority: normal severity: normal status: open title: Replace calls to malloc() with PyMem_Malloc() type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 13 21:41:38 2013 From: report at bugs.python.org (Matt Perry) Date: Thu, 13 Jun 2013 19:41:38 +0000 Subject: [New-bugs-announce] [issue18204] distutils error showing upload error message Message-ID: <1371152498.03.0.330361928353.issue18204@psf.upfronthosting.co.za> New submission from Matt Perry: Distutils attempts "r.read()" instead of "request.read()" when showing an upload error message. ---------- assignee: eric.araujo components: Distutils files: disutils_error_message.diff keywords: patch messages: 191088 nosy: eric.araujo, tarek, unshift priority: normal severity: normal status: open title: distutils error showing upload error message versions: Python 2.7 Added file: http://bugs.python.org/file30576/disutils_error_message.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 13 23:02:17 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 13 Jun 2013 21:02:17 +0000 Subject: [New-bugs-announce] [issue18205] PyOS_ReadlineFunctionPointer violates PyMem_Malloc() API: the GIL is not hold Message-ID: <1371157337.46.0.836983135269.issue18205@psf.upfronthosting.co.za> New submission from STINNER Victor: The callback PyOS_ReadlineFunctionPointer (used to read a line from the standard input) must return a buffer allocated by PyMem_Malloc(), but PyOS_Readline() releases the GIL before calling PyOS_ReadlineFunctionPointer. Simplified extract of PyOS_Readline(): Py_BEGIN_ALLOW_THREADS if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout))) rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt); else rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout, prompt); Py_END_ALLOW_THREADS tok_nextc() calls PyOS_Readline() and calls PyMem_FREE() to release its result. PyOS_ReadlineFunctionPointer should allocate memory using malloc(), not using PyMem_Malloc(). But PyOS_Readline() should copy the line into a buffer allocated by PyMem_Malloc() to keep backward compatibility. See also issue #18203 and #3329. ---------- components: Interpreter Core, Library (Lib) messages: 191089 nosy: haypo priority: normal severity: normal status: open title: PyOS_ReadlineFunctionPointer violates PyMem_Malloc() API: the GIL is not hold versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 00:29:20 2013 From: report at bugs.python.org (py.user) Date: Thu, 13 Jun 2013 22:29:20 +0000 Subject: [New-bugs-announce] [issue18206] There is no license.html on www.python.org Message-ID: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za> New submission from py.user: [guest at localhost ~]$ python3 Python 3.3.0 (default, Sep 29 2012, 22:07:38) [GCC 4.7.2 20120921 (Red Hat 4.7.2-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> license() See http://www.python.org/3.3/license.html >>> 404 answer from webmaster at python.org: Hello, When I use the version of Python distributed by python.org and type "license()" I get the full license text and not the url. It seems like this might be a change made by Red Hat? Either way, the proper place to discuss issues like this is on the Python bug tracker: http://bugs.python.org/ Feel free to report an issue there and the developers can look at it. This email address is actually for reporting problems with the Python.org website! All the best, Michael Foord in Lib/site.py: [guest at localhost cpython]$ sed -n '453,456p' Lib/site.py builtins.license = _Printer( "license", "See http://www.python.org/%.3s/license.html" % sys.version, ["LICENSE.txt", "LICENSE"], [os.path.join(here, os.pardir), here, os.curdir]) [guest at localhost cpython]$ ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 191095 nosy: docs at python, py.user priority: normal severity: normal status: open title: There is no license.html on www.python.org type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 01:58:14 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 13 Jun 2013 23:58:14 +0000 Subject: [New-bugs-announce] [issue18207] OpenSSL may ignore seconds in notAfter Message-ID: <1371167894.29.0.607710152237.issue18207@psf.upfronthosting.co.za> New submission from Christian Heimes: I'm doing some testing with old versions of OpenSSL. Some versions like 0.9.8i from 15 Sep 2008 ignore seconds in notAfter field: ./python -m test test_ssl test_hashlib [1/2] test_ssl test test_ssl failed -- Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 145, in test_parse_cert self.assertEqual(p['notAfter'], 'Oct 5 23:01:56 2020 GMT') AssertionError: 'Oct 5 23:01:00 2020 GMT' != 'Oct 5 23:01:56 2020 GMT' - Oct 5 23:01:00 2020 GMT ? ^^ + Oct 5 23:01:56 2020 GMT It's actually an issue in OpenSSL. I'm getting the same result with the openssl binary: $ ../openssl/0.9.8i/bin/openssl x509 -text -in Lib/test/https_svn_python_org_root.pem | grep GMT Not Before: Mar 30 12:29:00 2003 GMT Not After : Mar 29 12:29:00 2033 GMT $ ../openssl/0.9.8y/bin/openssl x509 -text -in Lib/test/https_svn_python_org_root.pem | grep GMT Not Before: Mar 30 12:29:49 2003 GMT Not After : Mar 29 12:29:49 2033 GMT I'd like to modify the test for a well-defined set of errnous OpenSSL versions. ---------- components: Extension Modules messages: 191099 nosy: christian.heimes, pitrou priority: normal severity: normal status: open title: OpenSSL may ignore seconds in notAfter versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 10:42:34 2013 From: report at bugs.python.org (Phil Connell) Date: Fri, 14 Jun 2013 08:42:34 +0000 Subject: [New-bugs-announce] [issue18208] Wrong bytecode generated for 'in' operation Message-ID: <1371199354.64.0.33010347301.issue18208@psf.upfronthosting.co.za> New submission from Phil Connell: The following two expressions should have the same value: Python 3.4.0a0 (default:fae92309c3be, Jun 14 2013, 09:29:54) [GCC 4.8.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 1 in [2] == False False >>> (1 in [2]) == False True It looks like this is a compiler issue - there shouldn't be a jump if the 'in' expression is false: >>> dis.dis("1 in [2] == False") 1 0 LOAD_CONST 0 (1) 3 LOAD_CONST 1 (2) 6 BUILD_LIST 1 9 DUP_TOP 10 ROT_THREE 11 COMPARE_OP 6 (in) 14 JUMP_IF_FALSE_OR_POP 24 17 LOAD_CONST 2 (False) 20 COMPARE_OP 2 (==) 23 RETURN_VALUE >> 24 ROT_TWO 25 POP_TOP 26 RETURN_VALUE >>> ---------- components: Interpreter Core messages: 191108 nosy: benjamin.peterson, brett.cannon, georg.brandl, isoschiz, ncoghlan, pconnell priority: normal severity: normal status: open title: Wrong bytecode generated for 'in' operation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 10:58:44 2013 From: report at bugs.python.org (Vincent Michel) Date: Fri, 14 Jun 2013 08:58:44 +0000 Subject: [New-bugs-announce] [issue18209] Bytearray type not supported as a mutable object in the fcntl.ioctl function Message-ID: <1371200324.57.0.0793560197908.issue18209@psf.upfronthosting.co.za> New submission from Vincent Michel: The Bytearray type is a mutable object that support the read-write buffer interface. The fcntl.ioctl() function is supposed to handle mutable object (such as array.array) for the system calls in order to pass object that are more than 1024 bytes long. The problem is that in Python 2.7, Bytearray type is not supported as a mutable object in the fcntl.ioctl function. In Python 3.2, it works perfectly. In the specific case where a large C structure is needed (more than 1024 bytes), the Bytearray type is extremely useful compare to the array.array type that is adapted for C arrays. Example : >>> file_handle = open('/dev/my_device') >>> arg = bytearray() >>> arg += pack('IL',1,2) >>> command = 0 >>> ioctl(file_handle,command,arg) Traceback (most recent call last): File "", line 1, in ioctl(file_handle,command,arg) TypeError: an integer is required ---------- components: IO messages: 191110 nosy: vxgmichel priority: normal severity: normal status: open title: Bytearray type not supported as a mutable object in the fcntl.ioctl function type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 11:43:21 2013 From: report at bugs.python.org (Aditya Atluri) Date: Fri, 14 Jun 2013 09:43:21 +0000 Subject: [New-bugs-announce] [issue18210] Problem creating extension in python3.3 with mingw32 Message-ID: <1371203001.41.0.920026348206.issue18210@psf.upfronthosting.co.za> New submission from Aditya Atluri: I am trying to build c extensions in windows using mingw32. The file hello.c works fine with 2.7 but, errors are poping up in 3.3. Attachments: [1] log.txt : The errors [2] hello.c : The C file [3] setup.py: The setup file The command I used in cmd is, "python setup.py build -c mingw32" ---------- assignee: eric.araujo components: Distutils, Extension Modules files: Build-Bug.zip messages: 191113 nosy: adityaatluri, eric.araujo, tarek priority: normal severity: normal status: open title: Problem creating extension in python3.3 with mingw32 versions: Python 3.3 Added file: http://bugs.python.org/file30582/Build-Bug.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 13:50:35 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 14 Jun 2013 11:50:35 +0000 Subject: [New-bugs-announce] [issue18211] -Werror=statement-after-declaration problem Message-ID: <1371210635.81.0.102822533543.issue18211@psf.upfronthosting.co.za> New submission from Ronald Oussoren: Changeset a3559c8c614b added -Werror=statement-after-declaration to the CFLAGS for compiler that support it. This new flags is fine for CPython itself (which is explicitly writting in C89 style to support older compilers and Microsoft Visual Studio), but the new flags also gets used when building 3th-party extensions using distutils and might cause problems there when that code uses C99. I don't have a good solution for this yet, the flag is useful to have when building CPython to avoid regressions in C89 support but shouldn't be used when building 3th-party extensions. ---------- assignee: eric.araujo components: Build, Distutils messages: 191119 nosy: benjamin.peterson, eric.araujo, ronaldoussoren, tarek priority: normal severity: normal stage: needs patch status: open title: -Werror=statement-after-declaration problem type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 15:25:45 2013 From: report at bugs.python.org (Ram Rachum) Date: Fri, 14 Jun 2013 13:25:45 +0000 Subject: [New-bugs-announce] [issue18212] No way to check whether Future is finished? Message-ID: <1371216345.77.0.119966223843.issue18212@psf.upfronthosting.co.za> New submission from Ram Rachum: I have a `Future` and I want to check whether it's in finished state. It seems like I don't have a method to do that, right? (I could emulate the existing methods for checking Future state, but that would mean fiddling with private variables.) Why not just expose the Future state in a property that automatically acquires `self._condition`? (Instead of a horde of methods.) ---------- components: Library (Lib) messages: 191126 nosy: cool-RR priority: normal severity: normal status: open title: No way to check whether Future is finished? type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 16:07:25 2013 From: report at bugs.python.org (Phil Muldoon) Date: Fri, 14 Jun 2013 14:07:25 +0000 Subject: [New-bugs-announce] [issue18213] py-bt errors on backtrace Message-ID: <1371218845.8.0.761231443863.issue18213@psf.upfronthosting.co.za> New submission from Phil Muldoon: (gdb) py-bt #2 Frame 0xef8180, for file , line 1, in () Python Exception (2, 'No such file or directory', ''): Error occurred in Python command: (2, 'No such file or directory', '') This is the actual raw frame data: #0 frapy_pc (self=, args=0x0) at ../../gdb/gdb/python/py-frame.c:223 #1 0x0000003edf4dcfd6 in call_function (oparg=, pp_stack=0x7fffffffd378) at /usr/src/debug/Python-2.7.3/Python/ceval.c:4082 #2 PyEval_EvalFrameEx (f=f at entry=Frame 0xef8180, for file , line 1, in (), throwflag=throwflag at entry=0) at /usr/src/debug/Python-2.7.3/Python/ceval.c:2740 #3 0x0000003edf4ddcbf in PyEval_EvalCodeEx ( During symbol reading, Multiple children of DIE 0x3904c refer to DIE 0x38d87 as their abstract origin. co=co at entry=0x7ffff1adb8b0, globals=globals at entry= {'g': , '__builtins__': , 'GdbRemoveReadlineFinder': , '__package__': None, 'sys': , 'gdb': , '__name__': '__main__', '__doc__': None}, locals=locals at entry= {'g': , '__builtins__': , 'GdbRemoveReadlineFinder': , '__package__': None, 'sys': , 'gdb': , '__name__': '__main__', '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at /usr/src/debug/Python-2.7.3/Python/ceval.c:3330 ---------- components: Demos and Tools messages: 191131 nosy: dmalcolm, pmuldoon priority: normal severity: normal status: open title: py-bt errors on backtrace type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 16:59:39 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 14 Jun 2013 14:59:39 +0000 Subject: [New-bugs-announce] [issue18214] Stop purging modules which are garbage collected before shutdown Message-ID: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za> New submission from Richard Oudkerk: Currently when a module is garbage collected its dict is purged by replacing all values except __builtins__ by None. This helps clear things at shutdown. But this can cause problems if it occurs *before* shutdown: if we use a function defined in a module which has been garbage collected, then that function must not depend on any globals, because they will have been purged. Usually this problem only occurs with programs which manipulate sys.modules. For example when setuptools and nose run tests they like to reset sys.modules each time. See for example http://bugs.python.org/issue15881 See also http://bugs.python.org/issue16718 The trivial patch attached prevents the purging behaviour for modules gc'ed before shutdown begins. Usually garbage collection will end up clearing the module's dict anyway. I checked the count of refs and blocks reported on exit when running a trivial program and a full regrtest (which will cause quite a bit of sys.modules manipulation). The difference caused by the patch is minimal. Without patch: do nothing: [20234 refs, 6582 blocks] full regrtest: [92713 refs, 32597 blocks] With patch: do nothing: [20234 refs, 6582 blocks] full regrtest: [92821 refs, 32649 blocks] ---------- files: prevent-purge-before-shutdown.patch keywords: patch messages: 191135 nosy: sbt priority: normal severity: normal status: open title: Stop purging modules which are garbage collected before shutdown versions: Python 3.4 Added file: http://bugs.python.org/file30583/prevent-purge-before-shutdown.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 18:00:42 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 14 Jun 2013 16:00:42 +0000 Subject: [New-bugs-announce] [issue18215] Script to test multiple versions of OpenSSL Message-ID: <1371225642.81.0.592691190065.issue18215@psf.upfronthosting.co.za> New submission from Christian Heimes: I have created a little script that automates downloading, compiling and testing multiple versions of OpenSSL. It's a bit of a hack but it suits its purpose. Maybe somebody likes to take it from here and turn it into a proper tool for Python's Tools/ directory. >From the doc string of the script: The script (1) downloads OpenSSL tar bundle (2) extracts it to ../openssl/src/openssl-VERSION/ (3) compiles OpenSSL (4) installs OpenSSL into ../openssl/VERSION/ (5) forces a recompilation of Python modules using the header and library files from ../openssl/VERSION/ (6) runs Python's test suite The script must be run with Python's build directory as current working directory. The script uses LD_RUN_PATH, LD_LIBRARY_PATH, CPPFLAGS and LDFLAGS to bend search paths for header files and shared libraries. It's known to work on Linux with GCC 4.x. Tested with OpenSSL 0.9.7m, 0.9.8y, 1.0.0k and 1.0.1e. ---------- components: Demos and Tools files: multissl.py messages: 191139 nosy: christian.heimes, gregory.p.smith, pitrou priority: low severity: normal status: open title: Script to test multiple versions of OpenSSL type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30584/multissl.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 22:34:41 2013 From: report at bugs.python.org (Jakub Wilk) Date: Fri, 14 Jun 2013 20:34:41 +0000 Subject: [New-bugs-announce] [issue18216] gettext doesn't check MO versions Message-ID: <1371242081.43.0.507366610452.issue18216@psf.upfronthosting.co.za> New submission from Jakub Wilk: The MO file format specification[0] reads: "A program seeing an unexpected major revision number should stop reading the MO file entirely" But Python doesn't pay attention to versions at all. As a test-case I attached a MO file with a bogus major revision number. msgunfmt correcly rejects such a file: $ msgunfmt messages.mo msgunfmt: file "messages.mo" is not in GNU .mo format Yet Python opens it happily: >>> import gettext >>> t = gettext.GNUTranslations(open("messages.mo", "rb")) >>> t.gettext("foo") 'bar' [0] http://www.gnu.org/software/gettext/manual/html_node/MO-Files.html ---------- components: Library (Lib) files: messages.mo messages: 191151 nosy: jwilk priority: normal severity: normal status: open title: gettext doesn't check MO versions Added file: http://bugs.python.org/file30587/messages.mo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 14 22:36:49 2013 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 14 Jun 2013 20:36:49 +0000 Subject: [New-bugs-announce] [issue18217] Deprecate and remove gettext.install Message-ID: <1371242209.86.0.435124148843.issue18217@psf.upfronthosting.co.za> New submission from Alex Gaynor: There's a myriad of reasons it's a bad idea: * Makes code harder to read * Doesn't play nicely with multiple projects using gettext * Defeats any attempt at static analysis * etc... ---------- messages: 191152 nosy: alex priority: normal severity: normal status: open title: Deprecate and remove gettext.install _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 15 06:29:37 2013 From: report at bugs.python.org (py.user) Date: Sat, 15 Jun 2013 04:29:37 +0000 Subject: [New-bugs-announce] [issue18218] In itertools.count() clarify the starting point Message-ID: <1371270577.83.0.291953378937.issue18218@psf.upfronthosting.co.za> New submission from py.user: http://docs.python.org/3/library/itertools.html#itertools.count "itertools.count(start=0, step=1) Make an iterator that returns evenly spaced values starting with n." starting with start ---------- assignee: docs at python components: Documentation files: issue.patch keywords: patch messages: 191196 nosy: docs at python, py.user priority: normal severity: normal status: open title: In itertools.count() clarify the starting point type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30596/issue.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 15 07:12:39 2013 From: report at bugs.python.org (Mikhail Traskin) Date: Sat, 15 Jun 2013 05:12:39 +0000 Subject: [New-bugs-announce] [issue18219] csv.DictWriter is slow when writing files with large number of columns Message-ID: <1371273159.09.0.766674685212.issue18219@psf.upfronthosting.co.za> New submission from Mikhail Traskin: _dict_to_list method of the csv.DictWriter objects created with extrasaction="raise" uses look-up in the list of field names to check if current row has any unknown fields. This results in O(n^2) execution time and is very slow if there are a lot of columns in a CSV file (in hundreds or thousands). Replacing look-up in a list with a look-up in a set solves the issue (see the attached patch). ---------- components: Library (Lib) files: csvdictwriter.patch keywords: patch messages: 191197 nosy: mtraskin priority: normal severity: normal status: open title: csv.DictWriter is slow when writing files with large number of columns type: performance Added file: http://bugs.python.org/file30598/csvdictwriter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 15 08:29:33 2013 From: report at bugs.python.org (py.user) Date: Sat, 15 Jun 2013 06:29:33 +0000 Subject: [New-bugs-announce] [issue18220] In itertools.islice() make prototype like in help() Message-ID: <1371277773.13.0.969293608974.issue18220@psf.upfronthosting.co.za> New submission from py.user: http://docs.python.org/3/library/itertools.html#itertools.islice " itertools.islice(iterable, stop) itertools.islice(iterable, start, stop[, step])" >>> print(itertools.islice.__doc__) islice(iterable, [start,] stop [, step]) --> islice object ... ---------- assignee: docs at python components: Documentation files: issue.patch keywords: patch messages: 191199 nosy: docs at python, py.user priority: normal severity: normal status: open title: In itertools.islice() make prototype like in help() type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30599/issue.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 15 14:38:02 2013 From: report at bugs.python.org (Jeremy Gray) Date: Sat, 15 Jun 2013 12:38:02 +0000 Subject: [New-bugs-announce] [issue18221] abspath strips trailing spaces on win32 Message-ID: <1371299882.82.0.523042534705.issue18221@psf.upfronthosting.co.za> New submission from Jeremy Gray: The behavior of os.path.abspath differs between Mac OS X and Windows. It seems like a bug that, on Windows, abspath strips trailing whitespace: Windows: >>> from os.path import abspath >>> abspath('start ') + 'END' 'c:\Users\jgray\code\startEND' ^ Mac: >>> from os.path import abspath >>> abspath('start ') + 'END' '/Users/jgray/code/start END' ^^ I have only tested with python 2.7.3 (Enthought distribution), 32-bit, and only Mac 10.8.2 and Windows 7. ---------- components: Windows messages: 191202 nosy: Jeremy.Gray priority: normal severity: normal status: open title: abspath strips trailing spaces on win32 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 15 14:40:14 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Balcerzak?=) Date: Sat, 15 Jun 2013 12:40:14 +0000 Subject: [New-bugs-announce] [issue18222] os.path.abspath should accept multiple path parts and join them Message-ID: <1371300014.52.0.302689191901.issue18222@psf.upfronthosting.co.za> New submission from ?ukasz Balcerzak: In projects I work on I constantly end up creating something like: abspath = lambda *p: os.path.abspath(os.path.join(*p)) This could be easily avoided by allowing abspath to accept multiple arguments. This would be: 1. Backward compatibile (calls with single argument would remain the same) 2. Very simple to fix (just join given path parts before doing anything else) I can document this, do most of the coding and test on Mac and linux, however would not be able to test on other platforms. Let me know if this is acceptable. Attaching a diff with posixpath update. ---------- components: Library (Lib) files: abspath-with-joins.diff keywords: patch messages: 191203 nosy: ?ukasz.Balcerzak priority: normal severity: normal status: open title: os.path.abspath should accept multiple path parts and join them type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file30600/abspath-with-joins.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 15 16:18:34 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 15 Jun 2013 14:18:34 +0000 Subject: [New-bugs-announce] [issue18223] Refactor test_tarfile Message-ID: <1371305914.88.0.406502768054.issue18223@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: test_tarfile already use parametric classes approach for constructing different tests. The proposed patch extends this approach to generating tests for different compression types. In additional this patch: * Makes test_tarfile discoverable. * Uses more special tests (i.e. assertEqual, assertIs) instead of assertTrue. * Adds explicit test skips instead of reporting skipped tests as passed. * Wraps long lines. ---------- components: Tests files: test_tarfile.patch keywords: patch messages: 191209 nosy: ezio.melotti, lars.gustaebel, michael.foord, pitrou, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: Refactor test_tarfile type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30601/test_tarfile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 15 16:27:14 2013 From: report at bugs.python.org (Peter Santoro) Date: Sat, 15 Jun 2013 14:27:14 +0000 Subject: [New-bugs-announce] [issue18224] pyvenv pydoc.py script causing AttributeErrors on Windows Message-ID: <1371306434.01.0.246562250059.issue18224@psf.upfronthosting.co.za> New submission from Peter Santoro: I've recently hit an issue with pyvenv in Python 3.3.2 that is causing AttributeErrors in other packages on Windows (see https://groups.google.com/forum/?fromgroups#!topic/pylons-discuss/FpOSMDpdvy4). Here's what I believe is going on: On Windows, the pyvenv pydoc script has a .py extension - so import finds it instead of the system's pydoc module. On Linux, the pyvenv pydoc script doesn't have an extension - so import finds the system's pydoc module. I believe the Windows pyvenv pydoc.py script should be renamed to something like pydocs.py to prevent AttributeErrors. ---------- components: Windows messages: 191210 nosy: peter at psantoro.net priority: normal severity: normal status: open title: pyvenv pydoc.py script causing AttributeErrors on Windows type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 15 18:42:24 2013 From: report at bugs.python.org (Tomer Levi) Date: Sat, 15 Jun 2013 16:42:24 +0000 Subject: [New-bugs-announce] [issue18225] ctypes Structure data size is incorrect Message-ID: <1371314544.05.0.0841863678451.issue18225@psf.upfronthosting.co.za> New submission from Tomer Levi: Whenever you create a ctypes.Structure with mixed ctypes, the size of all components is calculated by the size of largest one. This is especially irritating when trying to use Structure on bytearray. The problem repeated for me in Python2.6 and 2.7 (both 32bit and 64bit versions) [My computer is 64bit] Example: #Creating a Structure that should take up 5 bytes class Test(ctypes.Structure): _fields_ = [("test", ctypes.c_byte), ("test2", ctypes.c_uint32),] #Initiating the Structure Test.from_buffer(bytearray(5)) --- OUTPUT ---- Traceback (most recent call last): File "", line 1, in Test.from_buffer(bytearray(5)) ValueError: Buffer size too small (5 instead of at least 8 bytes) ---------- components: ctypes messages: 191213 nosy: Tomer.Levi priority: normal severity: normal status: open title: ctypes Structure data size is incorrect type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 16 00:33:56 2013 From: report at bugs.python.org (Todd Rovito) Date: Sat, 15 Jun 2013 22:33:56 +0000 Subject: [New-bugs-announce] [issue18226] IDLE Unit test for FormatParagrah.py Message-ID: <1371335636.99.0.534048602964.issue18226@psf.upfronthosting.co.za> New submission from Todd Rovito: Continuing the IDLE unittest framework initiated in http://bugs.python.org/issue15392. A small unit test for IDLE FormatParagraph.py. This patch introduces a test module named test_format_paragraph.py inside Lib/idlelib/idle_test, considering the guidance in README file from idle_test. I should have a patch uploaded by Monday 6/17/2013 night. ---------- messages: 191242 nosy: Todd.Rovito, philwebster, terry.reedy priority: normal severity: normal status: open title: IDLE Unit test for FormatParagrah.py type: enhancement versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 16 01:27:49 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 15 Jun 2013 23:27:49 +0000 Subject: [New-bugs-announce] [issue18227] Use Python memory allocators in external libraries like zlib or OpenSSL Message-ID: <1371338869.58.0.00725626403199.issue18227@psf.upfronthosting.co.za> New submission from STINNER Victor: With the PEP 445 and the issue #3329, Python will get an API to setup custom memory allocators. To be able to configure how memory is handled in external libraries, some libraries allow to setup a custom allocator too. New functions PyMem_RawMalloc(), PyMem_GetRawAllocators() PyMem_SetRawAllocators() can be used for that. The safest option is to only reuse custom allocators if a library allows to setup them for a specfic function call or a specific object, and not replace the memory allocators globally. For example, the lzma library allows to set memory allocators only for one compressor object: LzmaEnc_Create(&SzAllocForLzma); We might change the global allocators of a library if Python is not embedded, but Python *is* the application (the standard "python" program). I don't know yet if it is safe to reuse custom memory allocators. Windows has for example a special behaviour: each DLL (dynamic library) has its own heap, memory allocator in a DLL cannot be released from another DLL. Would this issue introduce such bug? ---------- components: Interpreter Core messages: 191248 nosy: christian.heimes, haypo priority: normal severity: normal status: open title: Use Python memory allocators in external libraries like zlib or OpenSSL versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 16 06:03:15 2013 From: report at bugs.python.org (David Edelsohn) Date: Sun, 16 Jun 2013 04:03:15 +0000 Subject: [New-bugs-announce] [issue18228] AIX locale parsing failure Message-ID: <1371355395.07.0.213079327558.issue18228@psf.upfronthosting.co.za> New submission from David Edelsohn: All tests are failing for 3.x on AIX due to an error parsing the locale. This is not failing on 3.3 branch. File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/regrtest.py", line 1292, in runtest_inner with saved_test_environment(test, verbose, quiet) as environment: File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/regrtest.py", line 1256, in __enter__ in self.resource_info()) File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/regrtest.py", line 1255, in self.saved_values = dict((name, get()) for name, get, restore File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/regrtest.py", line 1239, in get_locale pairings.append((lc, locale.getlocale(lc))) File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/locale.py", line 524, in getlocale return _parse_localename(localename) File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/locale.py", line 433, in _parse_localename raise ValueError('unknown locale: %s' % localename) ValueError: unknown locale: C en_US C C C C ---------- components: Library (Lib) messages: 191257 nosy: David.Edelsohn priority: normal severity: normal status: open title: AIX locale parsing failure type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 16 11:59:21 2013 From: report at bugs.python.org (Jordan Szubert) Date: Sun, 16 Jun 2013 09:59:21 +0000 Subject: [New-bugs-announce] [issue18229] attribute headers of http.server.BaseHTTPRequestHandler sometimes does not exists Message-ID: <1371376761.5.0.41138715811.issue18229@psf.upfronthosting.co.za> New submission from Jordan Szubert: it seems that problem is someone connecting to port 8080 with non-http client, could not find warning in documentation ---fragment of `less access.log`------------ 81.172.30.254 - - [16/Jun/2013 11:36:58] "^SBitTorrent protocol^@^@^@^@^@^X^@^Ej 81.172.30.254 - - [16/Jun/2013 11:38:11] "^N^@f????Q;?xb^C^H?A7 81.172.30.254 - - [16/Jun/2013 11:39:22] "^SBitTorrent protocol^@^@^@^@^@^X^@^Ej 81.172.30.254 - - [16/Jun/2013 11:40:35] "??0?zzr^D2]WQ Exception happened during processing of request from ('81.172.30.254', 63650) Traceback (most recent call last): File "c:\Python33\lib\socketserver.py", line 306, in _handle_request_noblock self.process_request(request, client_address) File "c:\Python33\lib\socketserver.py", line 332, in process_request self.finish_request(request, client_address) File "c:\Python33\lib\socketserver.py", line 345, in finish_request self.RequestHandlerClass(request, client_address, self) File "c:\Python33\lib\socketserver.py", line 666, in __init__ self.handle() File "c:\Python33\lib\http\server.py", line 400, in handle self.handle_one_request() File "c:\Python33\lib\http\server.py", line 380, in handle_one_request if not self.parse_request(): File "c:\Python33\lib\http\server.py", line 283, in parse_request self.send_error(400, "Bad request version (%r)" % version) File "c:\Python33\lib\http\server.py", line 428, in send_error self.send_response(code, message) File "c:\Python33\lib\http\server.py", line 443, in send_response self.log_request(code) File "c:\Users\joru\Dropbox\programowanie\demoniszcze\server\_lowerHTTP.py", line 30, in log_request xff=req.headers.get('X-Forwarded-For') AttributeError: '_HNDL_3' object has no attribute 'headers' # _HNLD_3 derives from http.server.BaseHTTPRequestHandler ---------- assignee: docs at python components: Documentation messages: 191264 nosy: docs at python, joru priority: normal severity: normal status: open title: attribute headers of http.server.BaseHTTPRequestHandler sometimes does not exists type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 16 17:17:40 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 16 Jun 2013 15:17:40 +0000 Subject: [New-bugs-announce] [issue18230] test_builtin fails/hangs when run after test_getopt Message-ID: <1371395860.64.0.905722760068.issue18230@psf.upfronthosting.co.za> New submission from Brett Cannon: If you run test_builtin after test_getopt it will hang. If you run test_getopt test_socket test_builtin it will fail in all tty-related tests for input(). Not sure if this is related to issue #17734 or #13886. ---------- components: Library (Lib) messages: 191270 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: test_builtin fails/hangs when run after test_getopt type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 16 20:10:53 2013 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 16 Jun 2013 18:10:53 +0000 Subject: [New-bugs-announce] [issue18231] What's new in Python should explain what's new in UCD Message-ID: <1371406253.35.0.589040711268.issue18231@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: At the minimum, we should refer to unicode.org: http://www.unicode.org/versions/Unicode6.1.0/#Database_Changes (for Python 3.3), http://www.unicode.org/versions/Unicode6.2.0/#Database_Changes (for Python 3.4). We may also want to highlight changes that directly affect python programs. For example addition of new characters accepted as decimal digits in UCD 6.1.0. ---------- assignee: docs at python messages: 191278 nosy: belopolsky, docs at python priority: normal severity: normal status: open title: What's new in Python should explain what's new in UCD versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 16 21:32:39 2013 From: report at bugs.python.org (Robert Collins) Date: Sun, 16 Jun 2013 19:32:39 +0000 Subject: [New-bugs-announce] [issue18232] running a suite with no tests is not an error Message-ID: <1371411159.89.0.919313216558.issue18232@psf.upfronthosting.co.za> New submission from Robert Collins: In bug https://bugs.launchpad.net/subunit/+bug/586176 I recorded a user request - that if no tests are found, tools consuming subunit streams should be able to consider that an error. There is an analogous situation though, which is that if discover returns without error, running the resulting suite is worthless, as it has no tests. This is a bit of a sliding slope - what if discover finds one test when there should be 1000's ? Anyhow, filing this because there's been a few times when things have gone completely wrong that it would have helped CI systems detect that. (For instance, the tests package missing entirely, but tests were being scanned in the whole source tree, so no discover level error occurred). I'm thinking I'll add a '--min-tests=X' parameter to unittest.main, with the semantic that if there are less than X tests executed, the test run will be considered a failure, and folk can set this to 1 for the special case, or any arbitrary figure that they want for larger suites. ---------- messages: 191282 nosy: michael.foord, rbcollins priority: normal severity: normal status: open title: running a suite with no tests is not an error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 16 22:39:55 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 16 Jun 2013 20:39:55 +0000 Subject: [New-bugs-announce] [issue18233] SSLSocket.getpeercertchain() Message-ID: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch implements a method getpeercertchain() on a SSLSocket. It returns the peer's certificate chain from the leaf cert to the root cert if available. It wraps SSL_get_peer_cert_chain(). SSL_get_peer_cert_chain() doesn't have to pull any additional data from the peer. The information is already exchanged for cert validation. ---------- files: ssl_peerchertchain.patch keywords: patch messages: 191287 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: SSLSocket.getpeercertchain() type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30611/ssl_peerchertchain.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 02:24:18 2013 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Jun 2013 00:24:18 +0000 Subject: [New-bugs-announce] [issue18234] Unicodedata module should provide access to codepoint aliases Message-ID: <1371428658.79.0.833817613364.issue18234@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Python is aware of unicode codepoint aliases, but unicodedata does not provide a way to find aliases of a given codepoint: >>> ucd.lookup('ESCAPE') == '\N{ESCAPE}' True >>> ucd.lookup('RS') == '\N{RS}' True but >>> ucd.name('\N{ESCAPE}') Traceback (most recent call last): File "", line 1, in ValueError: no such name >>> ucd.name('\N{RS}') Traceback (most recent call last): File "", line 1, in ValueError: no such name ---------- messages: 191300 nosy: belopolsky priority: normal severity: normal status: open title: Unicodedata module should provide access to codepoint aliases type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 02:33:21 2013 From: report at bugs.python.org (David Edelsohn) Date: Mon, 17 Jun 2013 00:33:21 +0000 Subject: [New-bugs-announce] [issue18235] _sysconfigdata.py wrong on AIX installations Message-ID: <1371429201.94.0.372851990361.issue18235@psf.upfronthosting.co.za> New submission from David Edelsohn: _sysconfigdata.py includes information about how to build extension modules. On AIX this requires a wrapper script to build shared libraries. The file includes definitions like: 'BLDSHARED': './Modules/ld_so_aix gcc -pthread -bI:./Modules/python.exp', 'LDSHARED': './Modules/ld_so_aix gcc -pthread -bI:./Modules/python.exp', 'LINKCC': './Modules/makexp_aix Modules/python.exp . libpython3.4dm.a; gcc ' '-pthread', 'MAKESETUP': './Modules/makesetup', which is correct in the build directory, but is not correct for the install directory. The paths do not correspond to the installed location of ld_so_aix and makexp_aix in lib/pythonX.Y/config . ---------- components: Extension Modules messages: 191301 nosy: David.Edelsohn priority: normal severity: normal status: open title: _sysconfigdata.py wrong on AIX installations type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 03:06:30 2013 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Jun 2013 01:06:30 +0000 Subject: [New-bugs-announce] [issue18236] int() and float() do not accept strings with trailing separators Message-ID: <1371431190.78.0.117337167573.issue18236@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: ASCII information separators, hex codes 1C through 1F are classified as space: >>> all(c.isspace() for c in '\N{FS}\N{GS}\N{RS}\N{US}') True but int()/float() do not accept strings with leading or trailing separators: >>> int('123\N{RS}') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: '123\x1e' This is probably because corresponding bytes values are not classified as whitespace: >>> any(c.encode().isspace() for c in '\N{FS}\N{GS}\N{RS}\N{US}') False ---------- messages: 191303 nosy: belopolsky priority: normal severity: normal status: open title: int() and float() do not accept strings with trailing separators type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 03:34:57 2013 From: report at bugs.python.org (Jeff Tratner) Date: Mon, 17 Jun 2013 01:34:57 +0000 Subject: [New-bugs-announce] [issue18237] unittest.assertRaisesRegex(p) example is wrong in docs Message-ID: <1371432897.82.0.367432880569.issue18237@psf.upfronthosting.co.za> New submission from Jeff Tratner: One of the examples for assertRaisesRegex(p) is wrong by one character. Current is: self.assertRaisesRegexp(ValueError, 'invalid literal for.*XYZ$', int, 'XYZ') The $ at the end is wrong because the actual error message is "ValueError: invalid literal for int() with base 10: 'XYZ'" (with a ``'`` at the end). Two options for fixing. Option 1 - remove $ self.assertRaisesRegexp(ValueError, 'invalid literal for.*XYZ', int, 'XYZ') Option 2 - add ' self.assertRaisesRegexp(ValueError, 'invalid literal for.*XYZ\'$', int, 'XYZ') Same example is shown for assertRaisesRegex, so applies to both. And for completeness...here's something you can run to see the error [couldn't figure out how to attach two files]: import unittest class MyTest(unittest.TestCase): def test_example(self): # this fails self.assertRaisesRegexp(ValueError, 'invalid literal for.*XYZ$', int, 'XYZ') def test_option1(self): self.assertRaisesRegexp(ValueError, 'invalid literal for.*XYZ', int, 'XYZ') def test_option2(self): self.assertRaisesRegexp(ValueError, 'invalid literal for.*XYZ\'$', int, 'XYZ') unittest.main() ---------- assignee: docs at python components: Documentation files: unittest.patch keywords: patch messages: 191306 nosy: docs at python, jtratner priority: normal severity: normal status: open title: unittest.assertRaisesRegex(p) example is wrong in docs versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file30615/unittest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 04:12:37 2013 From: report at bugs.python.org (David Edelsohn) Date: Mon, 17 Jun 2013 02:12:37 +0000 Subject: [New-bugs-announce] [issue18238] test_signal.py wait_helper hangs on AIX Message-ID: <1371435157.92.0.303179116379.issue18238@psf.upfronthosting.co.za> New submission from David Edelsohn: test_signal.py wait_helper hangs on AIX. Please skip the test on AIX for now to allow all other tests to run to completion. diff -r bdd60bedf933 Lib/test/test_signal.py --- a/Lib/test/test_signal.py Sun Jun 16 18:37:53 2013 -0400 +++ b/Lib/test/test_signal.py Mon Jun 17 00:10:01 2013 -0700 @@ -593,6 +593,7 @@ """ assert_python_ok('-c', code) + @unittest.skipIf(sys.platform == "aix7", "Test hangs on AIX") @unittest.skipUnless(hasattr(signal, 'pthread_sigmask'), 'need signal.pthread_sigmask()') def wait_helper(self, blocked, test): ---------- components: Tests messages: 191310 nosy: David.Edelsohn priority: normal severity: normal status: open title: test_signal.py wait_helper hangs on AIX type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 09:04:25 2013 From: report at bugs.python.org (py.user) Date: Mon, 17 Jun 2013 07:04:25 +0000 Subject: [New-bugs-announce] [issue18239] In itertools docstring update arguments in count() example Message-ID: <1371452665.1.0.633243797151.issue18239@psf.upfronthosting.co.za> New submission from py.user: >>> print(itertools.__doc__) Functional tools for creating and using iterators. Infinite iterators: count([n]) --> n, n+1, n+2, ... ... ---------- assignee: docs at python components: Documentation, Library (Lib) files: issue.patch keywords: patch messages: 191317 nosy: docs at python, py.user priority: normal severity: normal status: open title: In itertools docstring update arguments in count() example type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30617/issue.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 12:38:28 2013 From: report at bugs.python.org (=?utf-8?q?Jonas_Borgstr=C3=B6m?=) Date: Mon, 17 Jun 2013 10:38:28 +0000 Subject: [New-bugs-announce] [issue18240] hmac unnecessarily restricts input to "bytes" Message-ID: <1371465508.71.0.540084524464.issue18240@psf.upfronthosting.co.za> New submission from Jonas Borgstr?m: Problem: In hmac.py there's a type check that verifies that the msg parameter is of type bytes(). if not isinstance(msg, bytes): raise TypeError("expected bytes, but got %r" % type(msg).__name__) That is incorrect. The hmac module should also work with other data types as long as they are supported by the underlying hashlib module, for example bytearray() and memoryview(). Suggestion: Remove that type check. hashlib will make sure str() and other invalid data types raises a TypeError. ---------- components: Library (Lib) messages: 191321 nosy: jborg priority: normal severity: normal status: open title: hmac unnecessarily restricts input to "bytes" type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 16:44:02 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 17 Jun 2013 14:44:02 +0000 Subject: [New-bugs-announce] [issue18241] Add unique option to heapq functions Message-ID: <1371480242.24.0.0078060677529.issue18241@psf.upfronthosting.co.za> New submission from Antoine Pitrou: In one application, I would like to use a heap as an allocation pool. I also want to check that a given value isn't released twice, therefore that the heap contains unique values. My use case would be solved nicely if heappush() took an optional "unique=False" parameter. Note that I haven't checked if doing so is possible while maintaining the O(log n) complexity :-) ---------- messages: 191341 nosy: pitrou, rhettinger priority: low severity: normal status: open title: Add unique option to heapq functions type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 16:59:20 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Jun 2013 14:59:20 +0000 Subject: [New-bugs-announce] [issue18242] IDLE should not be replacing warnings.formatwarning Message-ID: <1371481160.56.0.0975578809817.issue18242@psf.upfronthosting.co.za> New submission from Brett Cannon: Both idlelib.run and idlelib.PyShell replace warning.formatwarning which is a no-no. Only warning.showwarning is design to be replaced in any way. The proper solution is to replace warnings.showwarning with code that calls whatever formatting function you provide. ---------- components: IDLE messages: 191344 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: IDLE should not be replacing warnings.formatwarning type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 17:24:02 2013 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 17 Jun 2013 15:24:02 +0000 Subject: [New-bugs-announce] [issue18243] mktime_tz documentation out-of-date Message-ID: <1371482642.16.0.49381484414.issue18243@psf.upfronthosting.co.za> New submission from Jakub Wilk: email.utils.mktime_tz documentations says: "Minor deficiency: mktime_tz() interprets the first 8 elements of tuple as a local time and then compensates for the timezone difference. This may yield a slight error around changes in daylight savings time, though not worth worrying about for common use." But now that issue #14653 is fixed, this is no longer true. ---------- assignee: docs at python components: Documentation messages: 191346 nosy: docs at python, jwilk priority: normal severity: normal status: open title: mktime_tz documentation out-of-date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 19:34:28 2013 From: report at bugs.python.org (Edward Catmur) Date: Mon, 17 Jun 2013 17:34:28 +0000 Subject: [New-bugs-announce] [issue18244] singledispatch: When virtual-inheriting ABCs at distinct points in MRO, composed MRO is dependent on haystack ordering Message-ID: <1371490468.22.0.590624884808.issue18244@psf.upfronthosting.co.za> New submission from Edward Catmur: Suppose we have a class C with MRO (C, B, A, object). C virtual-inherits an ABC V, while B virtual-inherits an unrelated ABC W: object / | \ A W | | .` / B` V | .` C` Recalling that per PEP 443 singledispatch prefers concrete bases to virtual bases, we would expect the following composed MRO: C, B, V, A, W, object However what actually happens is the composed MRO depends on the order of the haystack; if W is processed first the result is correct, but if V is processed first then (because V does not subclass W) W is inserted in the MRO *before* V: C, B, A, object C, B, V, A, object C, B, W, V, A, object This results in ambiguity between V and W. Suggested fix is a slight change to the MRO composition algorithm, considering whether the items already placed in the MRO are concrete base classes. ---------- components: Extension Modules hgrepos: 200 messages: 191350 nosy: ecatmur priority: normal severity: normal status: open title: singledispatch: When virtual-inheriting ABCs at distinct points in MRO, composed MRO is dependent on haystack ordering versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 20:33:25 2013 From: report at bugs.python.org (py.user) Date: Mon, 17 Jun 2013 18:33:25 +0000 Subject: [New-bugs-announce] [issue18245] In itertools.groupby() make data plural Message-ID: <1371494005.37.0.121371971068.issue18245@psf.upfronthosting.co.za> New submission from py.user: http://en.wiktionary.org/wiki/data "data (uncountable) or plural noun" ---------- assignee: docs at python components: Documentation files: issue.diff keywords: patch messages: 191354 nosy: docs at python, py.user priority: normal severity: normal status: open title: In itertools.groupby() make data plural versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30624/issue.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 17 22:04:58 2013 From: report at bugs.python.org (Friedrich Spee von Langenfeld) Date: Mon, 17 Jun 2013 20:04:58 +0000 Subject: [New-bugs-announce] [issue18246] tkinter.Text() add a newline to the content - bug? Message-ID: <1371499498.11.0.831187493791.issue18246@psf.upfronthosting.co.za> New submission from Friedrich Spee von Langenfeld: Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> from tkinter import* >>> root = Tk() >>> text = Text() >>> text.pack() >>> text.insert(1.0, "Hello") >>> text.get(1.0, END) 'Hello\n' The tkinter.Text() widget add a newline (\n) to its content. Is this behavior a bug? ---------- components: Tkinter messages: 191370 nosy: Friedrich.Spee.von.Langenfeld priority: normal severity: normal status: open title: tkinter.Text() add a newline to the content - bug? versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 01:41:45 2013 From: report at bugs.python.org (py.user) Date: Mon, 17 Jun 2013 23:41:45 +0000 Subject: [New-bugs-announce] [issue18247] Add Lib/test/data/ to .gitignore Message-ID: <1371512505.36.0.839773102972.issue18247@psf.upfronthosting.co.za> New submission from py.user: have a git repository: http://docs.python.org/devguide/faq.html#i-already-know-how-to-use-git-can-i-use-that-instead git clone git://github.com/akheron/cpython after running tests by "make test" they created some files in "Lib/test/data/" [guest at localhost cpython]$ git st # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: Doc/library/itertools.rst # # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: Modules/itertoolsmodule.c # # Untracked files: # (use "git add ..." to include in what will be committed) # # Lib/test/data/BIG5.TXT # Lib/test/data/BIG5HKSCS-2004.TXT # Lib/test/data/CP932.TXT # Lib/test/data/CP936.TXT # Lib/test/data/CP949.TXT # Lib/test/data/CP950.TXT # Lib/test/data/EUC-CN.TXT # Lib/test/data/EUC-JISX0213.TXT # Lib/test/data/EUC-JP.TXT # Lib/test/data/EUC-KR.TXT # Lib/test/data/JOHAB.TXT # Lib/test/data/NamedSequences.txt # Lib/test/data/NormalizationTest.txt # Lib/test/data/SHIFTJIS.TXT # Lib/test/data/SHIFT_JISX0213.TXT # Lib/test/data/gb-18030-2000.xml [guest at localhost cpython]$ ---------- components: Build, Devguide messages: 191380 nosy: ezio.melotti, py.user priority: normal severity: normal status: open title: Add Lib/test/data/ to .gitignore type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 02:20:24 2013 From: report at bugs.python.org (David Edelsohn) Date: Tue, 18 Jun 2013 00:20:24 +0000 Subject: [New-bugs-announce] [issue18248] fficonfig.py.in wrong for AIX Message-ID: <1371514824.57.0.542380875815.issue18248@psf.upfronthosting.co.za> New submission from David Edelsohn: fficonfig.py.in incorrectly mixes source files intended for Linux with source files intended for AIX, causing a build failure. AIX uses ffi_darwin.c not ffi.c diff -r f6f70f1ab124 Modules/_ctypes/libffi.diff --- a/Modules/_ctypes/libffi.diff Mon Jun 17 22:02:14 2013 +0200 +++ b/Modules/_ctypes/libffi.diff Mon Jun 17 22:18:44 2013 -0700 @@ -135,7 +135,7 @@ + 'M32R': ['src/m32r/sysv.S', 'src/m32r/ffi.c'], + 'M68K': ['src/m68k/ffi.c', 'src/m68k/sysv.S'], + 'POWERPC': ['src/powerpc/ffi.c', 'src/powerpc/sysv.S', 'src/powerpc/ppc_closure.S', 'src/powerpc/linux64.S', 'src/powerpc/linux64_closure.S'], -+ 'POWERPC_AIX': ['src/powerpc/ffi.c', 'src/powerpc/aix.S', 'src/powerpc/aix_closure.S'], ++ 'POWERPC_AIX': ['src/powerpc/ffi_darwin.c', 'src/powerpc/aix.S', 'src/powerpc/aix_closure.S'], + 'POWERPC_FREEBSD': ['src/powerpc/ffi.c', 'src/powerpc/sysv.S', 'src/powerpc/ppc_closure.S'], + 'ARM': ['src/arm/sysv.S', 'src/arm/ffi.c'], + 'LIBFFI_CRIS': ['src/cris/sysv.S', 'src/cris/ffi.c'], diff -r f6f70f1ab124 Modules/_ctypes/libffi/fficonfig.py.in --- a/Modules/_ctypes/libffi/fficonfig.py.in Mon Jun 17 22:02:14 2013 +0200 +++ b/Modules/_ctypes/libffi/fficonfig.py.in Mon Jun 17 22:18:44 2013 -0700 @@ -16,7 +16,7 @@ 'M32R': ['src/m32r/sysv.S', 'src/m32r/ffi.c'], 'M68K': ['src/m68k/ffi.c', 'src/m68k/sysv.S'], 'POWERPC': ['src/powerpc/ffi.c', 'src/powerpc/sysv.S', 'src/powerpc/ppc_closure.S', 'src/powerpc/linux64.S', 'src/powerpc/linux64_closure.S'], - 'POWERPC_AIX': ['src/powerpc/ffi.c', 'src/powerpc/aix.S', 'src/powerpc/aix_closure.S'], + 'POWERPC_AIX': ['src/powerpc/ffi_darwin.c', 'src/powerpc/aix.S', 'src/powerpc/aix_closure.S'], 'POWERPC_FREEBSD': ['src/powerpc/ffi.c', 'src/powerpc/sysv.S', 'src/powerpc/ppc_closure.S'], 'ARM': ['src/arm/sysv.S', 'src/arm/ffi.c'], 'LIBFFI_CRIS': ['src/cris/sysv.S', 'src/cris/ffi.c'], ---------- components: Extension Modules messages: 191381 nosy: David.Edelsohn priority: normal severity: normal status: open title: fficonfig.py.in wrong for AIX type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 02:55:10 2013 From: report at bugs.python.org (Dave Angel) Date: Tue, 18 Jun 2013 00:55:10 +0000 Subject: [New-bugs-announce] [issue18249] Incorrect and incomplete help docs for close() method Message-ID: <1371516910.55.0.109427807192.issue18249@psf.upfronthosting.co.za> New submission from Dave Angel: Python 3.3.0 (default, Mar 7 2013, 00:24:38) [GCC 4.6.3] on linux q = open('/dev/null') help(q.close) the entire output is: ------------------------------- Help on built-in function close: close(...) (END) ------------------------------- But close() is NOT a built-in, it's a method. (In Python 2.7.* the output is: ------------------------------- Help on built-in function close: close(...) close() -> None or (perhaps) an integer. Close the file. Sets data attribute .closed to True. A closed file cannot be used for further I/O operations. close() may be called more than once without error. Some kinds of file objects (for example, opened by popen()) may return an exit status upon closing. (END) ------------------------------- which is only partially wrong. ---------- assignee: docs at python components: Documentation messages: 191382 nosy: DaveA, docs at python priority: normal severity: normal status: open title: Incorrect and incomplete help docs for close() method _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 03:16:44 2013 From: report at bugs.python.org (py.user) Date: Tue, 18 Jun 2013 01:16:44 +0000 Subject: [New-bugs-announce] [issue18250] In itertools.repeat() object shadows object() Message-ID: <1371518204.34.0.993952678875.issue18250@psf.upfronthosting.co.za> New submission from py.user: >>> object >>> ---------- assignee: docs at python components: Documentation files: issue.diff keywords: patch messages: 191384 nosy: docs at python, py.user priority: normal severity: normal status: open title: In itertools.repeat() object shadows object() type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30630/issue.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 09:46:10 2013 From: report at bugs.python.org (Sowmya) Date: Tue, 18 Jun 2013 07:46:10 +0000 Subject: [New-bugs-announce] [issue18251] test_subprocess_jy fails when Argument has embedded quote Message-ID: <1371541570.75.0.3271595345.issue18251@psf.upfronthosting.co.za> New submission from Sowmya: test_subprocess_jy fails with below error: test test_subprocess_jy failed -- Traceback (most recent call last): File \'L:\\apps\\ascii\\jython\\70files\\current\\win\\Lib\\test\\test_subprocess_jy.py\', line 13, in testDefaultEnvIsInherited p1 = Popen([sys.executable, \'-c\', File \'L:\\apps\\ascii\\jython\\70files\\current\\win\\Lib\\subprocess.py\', line 755, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File \'L:\\apps\\ascii\\jython\\70files\\current\\win\\Lib\\subprocess.py\', line 1269, in _execute_child raise OSError(e.getMessage() or e) OSError: Argument has embedded quote, use the explicit CMD.EXE call. Solution : This testcase needs to be changed to suit the changes mentioned in Oracle 7u21 - (http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html#jruntime). Python code needs to be modified to use "Cmd.exe" while running commands that contains quotes in it ---------- files: test_subclasses_jy.py messages: 191389 nosy: sowmyalakkappa priority: normal severity: normal status: open title: test_subprocess_jy fails when Argument has embedded quote type: enhancement versions: Python 2.6 Added file: http://bugs.python.org/file30632/test_subclasses_jy.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 11:25:07 2013 From: report at bugs.python.org (icedream91) Date: Tue, 18 Jun 2013 09:25:07 +0000 Subject: [New-bugs-announce] [issue18252] timeit makes code run faster? Message-ID: <1371547507.86.0.372750088046.issue18252@psf.upfronthosting.co.za> New submission from icedream91: I used Python 3.3.2 to try this problem: http://projecteuler.net/problem=23 , and I got a correct answer. When I wanted to check how long it took, I found something strange: When I ran 23.py directly, it showed that it took about 13s. But if I use timeit module, it showed that it only took about 9s! I have tried these for some times, in both Ubuntu 12.10 and Windows 8, I don't understand why timeit will make the same code run faster. Thanks. ---------- components: Benchmarks files: 23.py messages: 191390 nosy: icedream91 priority: normal severity: normal status: open title: timeit makes code run faster? versions: Python 3.3 Added file: http://bugs.python.org/file30633/23.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 11:53:11 2013 From: report at bugs.python.org (Friedrich Spee von Langenfeld) Date: Tue, 18 Jun 2013 09:53:11 +0000 Subject: [New-bugs-announce] [issue18253] make standard library PEP8 compliant Message-ID: <1371549191.92.0.460978933788.issue18253@psf.upfronthosting.co.za> New submission from Friedrich Spee von Langenfeld: The modules in the standard library aren?t PEP( compliant. I?ve written a script to change this. It uses autopep8.py (must be in the path) and is written for Windows users. ---------- components: Library (Lib) files: autopepframework.py messages: 191392 nosy: Friedrich.Spee.von.Langenfeld priority: normal severity: normal status: open title: make standard library PEP8 compliant type: enhancement Added file: http://bugs.python.org/file30635/autopepframework.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 12:21:45 2013 From: report at bugs.python.org (Archard Lias) Date: Tue, 18 Jun 2013 10:21:45 +0000 Subject: [New-bugs-announce] [issue18254] Accessing attr dict at definition time of a class from a metaclass results in changed type. Message-ID: <1371550905.79.0.414140838637.issue18254@psf.upfronthosting.co.za> New submission from Archard Lias: Accessing (just iterating or accessing in any way) the dict_proxy to the attribute dictionary in the `MessageMeta` metaclass, results in a change of "type" in any metaclass inheriting class definitions. Reproducible in CPython versions (tested so far): 3.2.2 3.2.3 Works as of, or at least behaves as I subjectively intended to use it (only version tested) 3.3.2 ---------- components: Interpreter Core files: bugreport_cpython3.2.3.py messages: 191394 nosy: archardlias priority: normal severity: normal status: open title: Accessing attr dict at definition time of a class from a metaclass results in changed type. versions: Python 3.2 Added file: http://bugs.python.org/file30636/bugreport_cpython3.2.3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 15:13:06 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 18 Jun 2013 13:13:06 +0000 Subject: [New-bugs-announce] [issue18255] CPython setup.py problems Message-ID: <1371561186.46.0.280107378589.issue18255@psf.upfronthosting.co.za> New submission from Ronald Oussoren: While working on a fix for #18211 I noticed two problems with the setup.py that's used to build the stdlib extensions. 1) setup.py uses sysconfig instead of distutils.sysconfig. The sematics of the two modules a slighty different. 2) The block of code starting with the this text is not necessary because distutils.sysconfig (which is used by the build_ext command) already does the right thing for environment variables: # When you run "make CC=altcc" or something similar, you really want # those environment variables passed into the setup.py phase. Here's # a small set of useful ones. ---------- components: Build files: setup-update.txt messages: 191406 nosy: ronaldoussoren priority: normal severity: normal stage: patch review status: open title: CPython setup.py problems type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30640/setup-update.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 15:58:41 2013 From: report at bugs.python.org (David Edelsohn) Date: Tue, 18 Jun 2013 13:58:41 +0000 Subject: [New-bugs-announce] [issue18256] thread_pthread.h fixes for AIX Message-ID: <1371563921.33.0.845649909744.issue18256@psf.upfronthosting.co.za> New submission from David Edelsohn: Recent releases of AIX do not need to call pthread_init(). The function is provided in libpthread.a for backward compatibility, but not declared in any header. This patch adds a declaration, or it can be removed completely because AIX 4.x no longer is supported. The patch also adds uses of "error" to two functions to silence warnings, in a similar manner to other functions in the file. diff -r f6f70f1ab124 Python/thread_pthread.h --- a/Python/thread_pthread.h Mon Jun 17 22:02:14 2013 +0200 +++ b/Python/thread_pthread.h Tue Jun 18 11:54:50 2013 -0700 @@ -170,6 +170,7 @@ PyThread__init_thread(void) { #if defined(_AIX) && defined(__GNUC__) + extern void pthread_init(void); pthread_init(); #endif } @@ -444,6 +445,7 @@ pthread_lock *thelock = (pthread_lock *)lock; int status, error = 0; + (void) error; /* silence unused-but-set-variable warning */ dprintf(("PyThread_free_lock(%p) called\n", lock)); /* some pthread-like implementations tie the mutex to the cond @@ -530,6 +532,7 @@ pthread_lock *thelock = (pthread_lock *)lock; int status, error = 0; + (void) error; /* silence unused-but-set-variable warning */ dprintf(("PyThread_release_lock(%p) called\n", lock)); status = pthread_mutex_lock( &thelock->mut ); ---------- components: Build messages: 191410 nosy: David.Edelsohn priority: normal severity: normal status: open title: thread_pthread.h fixes for AIX type: compile error versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 17:04:32 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 18 Jun 2013 15:04:32 +0000 Subject: [New-bugs-announce] [issue18257] Two copies of python-config Message-ID: <1371567872.42.0.116049773773.issue18257@psf.upfronthosting.co.za> New submission from Ronald Oussoren: Changeset c0370730b364 introduced a shell-script implementation of python-config (see issue #16235). The older python implementation is still present in $(srcdir)/Misc and generated by Makefile.pre.in. ---------- messages: 191416 nosy: doko, ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: Two copies of python-config type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 18 23:16:03 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 18 Jun 2013 21:16:03 +0000 Subject: [New-bugs-announce] [issue18258] Fix test discovery for test_codecmaps*.py Message-ID: <1371590163.56.0.716538742533.issue18258@psf.upfronthosting.co.za> New submission from Zachary Ware: The test package is almost to the point where I can run `PCbuild\python_d.exe -m unittest discover Lib/test/ "test_*.py"` and get a useful result, the only thing that still blows up is multibytecodec_support.py. I had not previously noticed this problem due to the way support.open_urlresource works, requiring the 'urlfetch' resource if and only if the requested file has not already been fetched before and stored in the Lib/test/data dir. multibytecodec_support.TestBase_Mapping blows things up because it uses __init__ instead of setUp to try opening the needed file, which causes ResourceDenied to be raised at class creation time rather than test run time, which unittest can't handle. The attached patch fixes this (at the expense of opening and closing the file once per test method, rather than once per class) as well as converting the test_codecmaps* scripts from test_main to unittest.main. ---------- components: Tests files: test_codecmaps_discovery.diff keywords: patch messages: 191434 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_codecmaps*.py type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30644/test_codecmaps_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 19 00:25:52 2013 From: report at bugs.python.org (David Edelsohn) Date: Tue, 18 Jun 2013 22:25:52 +0000 Subject: [New-bugs-announce] [issue18259] Declare sethostname in socketmodule.c for AIX Message-ID: <1371594352.51.0.0927804743578.issue18259@psf.upfronthosting.co.za> New submission from David Edelsohn: AIX provides sethostname() but it is not declared in any useful header. Fixed as follows: diff -r 626a8e49f2a9 Modules/socketmodule.c --- a/Modules/socketmodule.c Tue Jun 18 23:28:18 2013 +0200 +++ b/Modules/socketmodule.c Tue Jun 18 20:17:37 2013 -0700 @@ -4066,6 +4066,10 @@ Py_buffer buf; int res, flag = 0; +#ifdef _AIX +extern int sethostname(const char *, size_t); +#endif + if (!PyArg_ParseTuple(args, "S:sethostname", &hnobj)) { PyErr_Clear(); if (!PyArg_ParseTuple(args, "O&:sethostname", It seemed best to declare it inside the function. I placed it below the other declarations, not immediately before the function use. ---------- components: Build messages: 191439 nosy: David.Edelsohn, haypo priority: normal severity: normal status: open title: Declare sethostname in socketmodule.c for AIX type: compile error versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 19 06:18:08 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 19 Jun 2013 04:18:08 +0000 Subject: [New-bugs-announce] [issue18260] configparser: TypeError occurs when handling errors in files with binary names Message-ID: <1371615488.35.0.189174506667.issue18260@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: TypeError occurs when handling errors in files with binary names. configparser.* exceptions are expected. This regression was introduced in Python 3.2. $ cat /tmp/test1 [section] [section] $ cat /tmp/test2 [section] option = value option = value $ python3.1 -c 'import configparser; configparser.ConfigParser().readfp(open("/tmp/test1"))' $ python3.1 -c 'import configparser; configparser.ConfigParser().readfp(open("/tmp/test2"))' $ python3.1 -c 'import configparser; configparser.ConfigParser().readfp(open(b"/tmp/test1"))' $ python3.1 -c 'import configparser; configparser.ConfigParser().readfp(open(b"/tmp/test2"))' $ python3.4 -c 'import configparser; configparser.ConfigParser().read_file(open("/tmp/test1"))' Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.4/configparser.py", line 708, in read_file self._read(f, source) File "/usr/lib64/python3.4/configparser.py", line 1061, in _read lineno) configparser.DuplicateSectionError: While reading from /tmp/test1 [line 2]: section 'section' already exists $ python3.4 -c 'import configparser; configparser.ConfigParser().read_file(open("/tmp/test2"))' Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.4/configparser.py", line 708, in read_file self._read(f, source) File "/usr/lib64/python3.4/configparser.py", line 1087, in _read fpname, lineno) configparser.DuplicateOptionError: While reading from /tmp/test2 [line 3]: option 'option' in section 'section' already exists $ python3.4 -c 'import configparser; configparser.ConfigParser().read_file(open(b"/tmp/test1"))' Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.4/configparser.py", line 708, in read_file self._read(f, source) File "/usr/lib64/python3.4/configparser.py", line 1061, in _read lineno) File "/usr/lib64/python3.4/configparser.py", line 202, in __init__ Error.__init__(self, "".join(msg)) TypeError: sequence item 1: expected str instance, bytes found $ python3.4 -c 'import configparser; configparser.ConfigParser().read_file(open(b"/tmp/test2"))' Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.4/configparser.py", line 708, in read_file self._read(f, source) File "/usr/lib64/python3.4/configparser.py", line 1087, in _read fpname, lineno) File "/usr/lib64/python3.4/configparser.py", line 228, in __init__ Error.__init__(self, "".join(msg)) TypeError: sequence item 1: expected str instance, bytes found ---------- assignee: lukasz.langa components: Library (Lib) keywords: 3.2regression messages: 191443 nosy: Arfrever, lukasz.langa priority: normal severity: normal status: open title: configparser: TypeError occurs when handling errors in files with binary names versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 19 07:29:27 2013 From: report at bugs.python.org (Emcisq Zhao) Date: Wed, 19 Jun 2013 05:29:27 +0000 Subject: [New-bugs-announce] [issue18261] Confusing description in Minimal DOM implementation Message-ID: <1371619767.63.0.501848749792.issue18261@psf.upfronthosting.co.za> New submission from Emcisq Zhao: Visit http://docs.python.org/2.7/library/xml.dom.minidom.html, please notice the first paragraph. The last sentence is " should consider using the xml.etree.ElementTree module for their XML processing instead". Shouldn't it be " should consider using the xml.dom.minidom module for their XML processing instead"? ---------- assignee: docs at python components: Documentation messages: 191444 nosy: docs at python, zhjweizhjwei priority: normal severity: normal status: open title: Confusing description in Minimal DOM implementation type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 19 08:19:22 2013 From: report at bugs.python.org (anatoly techtonik) Date: Wed, 19 Jun 2013 06:19:22 +0000 Subject: [New-bugs-announce] [issue18262] ZipInfo.external_attr are not documented Message-ID: <1371622762.23.0.278457180872.issue18262@psf.upfronthosting.co.za> New submission from anatoly techtonik: zipfile doesn't restore file attributes when extracting. Documentation should at least contain example how to do this manually, because the ony way to do this - through ZipInfo.external_attr is too cryptic. ---------- assignee: docs at python components: Documentation messages: 191447 nosy: docs at python, techtonik priority: normal severity: normal status: open title: ZipInfo.external_attr are not documented versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 19 14:58:45 2013 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 19 Jun 2013 12:58:45 +0000 Subject: [New-bugs-announce] [issue18263] python.man: no documentation for -b, -X Message-ID: <1371646726.0.0.233284633234.issue18263@psf.upfronthosting.co.za> New submission from Jakub Wilk: The -b and -X options are not documented in Misc/python.man. ---------- assignee: docs at python components: Documentation messages: 191463 nosy: docs at python, jwilk priority: normal severity: normal status: open title: python.man: no documentation for -b, -X _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 19 15:45:41 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 19 Jun 2013 13:45:41 +0000 Subject: [New-bugs-announce] [issue18264] enum.IntEnum is not compatible with JSON serialisation Message-ID: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za> New submission from Nick Coghlan: Replacing an integer constant with the current incarnation of enum.IntEnum breaks JSON serialisation: >>> from enum import Enum >>> from enum import Enum, IntEnum >>> class Example(IntEnum): ... x = 1 ... >>> import json >>> json.dumps(1) '1' >>> json.loads(json.dumps(1)) 1 >>> json.dumps(Example.x) 'Example.x' >>> json.loads(json.dumps(Example.x)) Traceback (most recent call last): File "", line 1, in File "/home/ncoghlan/devel/py3k/Lib/json/__init__.py", line 316, in loads return _default_decoder.decode(s) File "/home/ncoghlan/devel/py3k/Lib/json/decoder.py", line 344, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/home/ncoghlan/devel/py3k/Lib/json/decoder.py", line 362, in raw_decode raise ValueError(errmsg("Expecting value", s, err.value)) from None ValueError: Expecting value: line 1 column 1 (char 0) It breaks for floats as well, but in a slightly different way: >>> class FloatExample(float, Enum): ... x = 1.0 ... >>> json.dumps(FloatExample.x) '' Allowing __str__ to be inherited from Enum rather than from the concrete type will similarly break any serialisation protocol that relies on str() to handle integers. The float case is even trickier, since failing to inherit __repr__ would rather miss the point of the whole exercise... We're going to have to be *very* careful with swapping out existing constants with enums, and we should be warning about the pitfalls in the docs too (where we can't change enum to avoid them). ---------- components: Library (Lib) messages: 191467 nosy: ncoghlan priority: normal severity: normal status: open title: enum.IntEnum is not compatible with JSON serialisation versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From barry at python.org Wed Jun 19 15:57:59 2013 From: barry at python.org (Barry Warsaw) Date: Wed, 19 Jun 2013 09:57:59 -0400 Subject: [New-bugs-announce] [issue18264] enum.IntEnum is not compatible with JSON serialisation In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za> References: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za> Message-ID: <20130619095759.7855f9bc@anarchist> On Jun 19, 2013, at 01:45 PM, Nick Coghlan wrote: >Allowing __str__ to be inherited from Enum rather than from the concrete type >will similarly break any serialisation protocol that relies on str() to >handle integers. The float case is even trickier, since failing to inherit >__repr__ would rather miss the point of the whole exercise... Serialization isn't the only issue - you have to know how to deserialize as well. I use JSON extensively in Mailman's REST API. For enums I always encode them to just the member name, because I always know what enum class will be used to deserialize them. (TBH, I wish the json module had better hooks for extending both serialization and deserialization of non-basic types.) From report at bugs.python.org Wed Jun 19 17:09:23 2013 From: report at bugs.python.org (David Edelsohn) Date: Wed, 19 Jun 2013 15:09:23 +0000 Subject: [New-bugs-announce] [issue18265] typedef lookupfunc defined by not used Message-ID: <1371654563.07.0.94509759313.issue18265@psf.upfronthosting.co.za> New submission from David Edelsohn: Objects/setobject.c:217:25: warning: typedef 'lookupfunc' locally defined but not used [-Wunused-local-typedefs] This was fixed in trunk (changeset 84208:626a8e49f2a9) and should be backported to 3.3 branch. This is a warning found by GCC 4.8. ---------- components: Build messages: 191483 nosy: David.Edelsohn priority: normal severity: normal status: open title: typedef lookupfunc defined by not used type: compile error versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 19 23:00:54 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 19 Jun 2013 21:00:54 +0000 Subject: [New-bugs-announce] [issue18266] Fix test discovery for test_largefile.py Message-ID: <1371675654.81.0.262540951411.issue18266@psf.upfronthosting.co.za> New submission from Zachary Ware: This one is another inheritance issue. The patch removes unittest.TestCase as a base for LargeFileTest and converts test_main into setUpModule, load_tests, and tearDownModule. This seems like the way to go due to the fact that the order of test execution matters: test_seek must be first and test_truncate must be last. The only way around that restriction would be to create a new copy of the file for test_truncate, which would make the test take even longer and use even more resources. Also, the programmatic creation of the C and Py variants of the test has been changed from creating an empty subclass of LargeFileTest which is then renamed and assigned an 'open' attr, to using the three-arg form of type to create a subclass of LargeFileTest and unittest.TestCase with name set and an 'open' attr pointing to the correct function. Lastly, the superfluous check on whether f.truncate is available that had been in test_main is now removed so that the test is properly marked as skipped if skipped. ---------- components: Tests files: test_largefile_discovery.diff keywords: patch messages: 191494 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_largefile.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30651/test_largefile_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 19 23:03:25 2013 From: report at bugs.python.org (Bernhard Reiter) Date: Wed, 19 Jun 2013 21:03:25 +0000 Subject: [New-bugs-announce] [issue18267] xmlrpc.client documentation multicall example missleading for division behaviour of python3 Message-ID: <1371675805.26.0.18697522409.issue18267@psf.upfronthosting.co.za> New submission from Bernhard Reiter: http://docs.python.org/3.4/library/xmlrpc.client.html as of 2013-06-19 20:35 UTC has a divide example and the output can misslead the learning reader towards the new behaviour of python3 with the '/' binary operator for division. server code: def divide(x, y): return x/y client code: multicall.divide(7,3) [..] print("7+3=%d, 7-3=%d, 7*3=%d, 7/3=%d" % tuple(result)) The client call results into: python3 client.py 7+3=10, 7-3=4, 7*3=21, 7/3=2 This is missleading because '7/3' is now resulting to a float in python3 (see PEP238).The example probably was copied over from the python2 documentation where '7/3' result to int. The implicit conversion from float to int is done in the string formatting. Proposal replace the print line with print("7+3=%d, 7-3=%d, 7*3=%d, 7/3=%g" % tuple(result)) to get 7+3=10, 7-3=4, 7*3=21, 7/3=2.33333 or print(repr(tuple(result))) to get (10, 4, 21, 2.3333333333333335) ---------- assignee: docs at python components: Documentation messages: 191495 nosy: ber, docs at python priority: normal severity: normal status: open title: xmlrpc.client documentation multicall example missleading for division behaviour of python3 versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 19 23:21:54 2013 From: report at bugs.python.org (Brendan O'Connor) Date: Wed, 19 Jun 2013 21:21:54 +0000 Subject: [New-bugs-announce] [issue18268] ElementTree.fromstring non-deterministically gives unicode text data Message-ID: <1371676914.3.0.530507394222.issue18268@psf.upfronthosting.co.za> New submission from Brendan O'Connor: (This is Python 2.7 so I'm using string vs unicode terminology.) When I use ElementTree.fromstring(), and use the .text field on nodes, the value is usually a string object, but in rare cases it's a unicode object. I'm parsing many XML documents of newspaper text [1]; on one subset of the data, out of 5 million nodes, ~200 of them have a unicode object for the .text field. I think this is all related to http://bugs.python.org/issue11033 but I can't figure out how, exactly. I'm passing in strings to ElementTree.fromstring() like you're supposed to. The workaround is to defensively convert the .text value to unicode [3]. [1] data is http://www.ldc.upenn.edu/Catalog/catalogEntry.jsp?catalogId=LDC2012T21 [2] my processing code is https://github.com/brendano/gigaword_conversion/blob/master/annogw2justsent.py [3] def convert_to_unicode(mystr): if isinstance(mystr, unicode): return mystr if isinstance(mystr, str): return mystr.decode('utf8') ---------- messages: 191496 nosy: Brendan.OConnor priority: normal severity: normal status: open title: ElementTree.fromstring non-deterministically gives unicode text data type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 20 08:24:57 2013 From: report at bugs.python.org (anatoly techtonik) Date: Thu, 20 Jun 2013 06:24:57 +0000 Subject: [New-bugs-announce] [issue18269] Clarify which integer is required in os.chmod() exception Message-ID: <1371709497.35.0.24521044136.issue18269@psf.upfronthosting.co.za> New submission from anatoly techtonik: (, '0755') (, '0644') Traceback (most recent call last): File "./tools/bootstrap.py", line 185, in extract_zip os.fchmod(outfile, unixperm) TypeError: an integer is required Here the integer that is required is not `unixperm`, but `outfile`. ---------- assignee: docs at python components: Documentation messages: 191502 nosy: docs at python, techtonik priority: normal severity: normal status: open title: Clarify which integer is required in os.chmod() exception versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 20 16:40:02 2013 From: report at bugs.python.org (Dennis Backhaus) Date: Thu, 20 Jun 2013 14:40:02 +0000 Subject: [New-bugs-announce] [issue18270] AttributeError: 'NoneType' object has no attribute 'interp' Message-ID: <1371739202.98.0.896833417364.issue18270@psf.upfronthosting.co.za> New submission from Dennis Backhaus: It just worked fine yesterday, but when I start IDLE (with and without trying to open a file at the same time) I get this error. Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/bin/idle", line 5, in main() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 1560, in main shell.interp.runcommand(''.join(("print('", tkversionwarning, "')"))) AttributeError: 'NoneType' object has no attribute 'interp' ---------- components: IDLE messages: 191518 nosy: dbackhaus priority: normal severity: normal status: open title: AttributeError: 'NoneType' object has no attribute 'interp' versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 20 17:39:02 2013 From: report at bugs.python.org (Marko Lalic) Date: Thu, 20 Jun 2013 15:39:02 +0000 Subject: [New-bugs-announce] [issue18271] get_payload method returns bytes which cannot be decoded using the message's charset Message-ID: <1371742742.04.0.192610725927.issue18271@psf.upfronthosting.co.za> New submission from Marko Lalic: When the message's Content-Transfer-Encoding is set to 8bit, the get_payload(decode=True) method returns the payload encoded using raw-unicode-escape. This means that it is impossible to decode the returned bytes using the content charset obtained by the get_content_charset method. It seems this should be fixed so that get_payload returns the bytes as found in the payload when Content-Transfer-Encoding is 8bit, exactly like Python2.7 handles it. >>> from email import message_from_string >>> message = message_from_string("""MIME-Version: 1.0 ... Content-Type: text/plain; charset=utf-8 ... Content-Disposition: inline ... Content-Transfer-Encoding: 8bit ... ... ?nic?de data..""") >>> message.get_content_charset() 'utf-8' >>> message.get_payload(decode=True) b'\xfcnic\xf6de data..' >>> message.get_payload(decode=True).decode(message.get_content_charset()) Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfc in position 0: invalid start byte >>> message.get_payload(decode=True).decode('raw-unicode-escape') '?nic?de data..' ---------- components: email messages: 191526 nosy: barry, mlalic, r.david.murray priority: normal severity: normal status: open title: get_payload method returns bytes which cannot be decoded using the message's charset type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 20 20:35:46 2013 From: report at bugs.python.org (py.user) Date: Thu, 20 Jun 2013 18:35:46 +0000 Subject: [New-bugs-announce] [issue18272] In itertools recipes there is a typo in __builtins__ Message-ID: <1371753346.0.0.321196012203.issue18272@psf.upfronthosting.co.za> New submission from py.user: http://docs.python.org/3/library/itertools.html#itertools-recipes "Like __builtin__.iter(func, sentinel)" ---------- assignee: docs at python components: Documentation files: issue.diff keywords: patch messages: 191530 nosy: docs at python, py.user priority: normal severity: normal status: open title: In itertools recipes there is a typo in __builtins__ type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30656/issue.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 20 22:30:20 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 20 Jun 2013 20:30:20 +0000 Subject: [New-bugs-announce] [issue18273] Simplify calling and discovery of json test package Message-ID: <1371760220.13.0.623339240586.issue18273@psf.upfronthosting.co.za> New submission from Zachary Ware: Technically, test discovery already works for test_json.py / json_tests, but not the way really expected (each test file is discovered individually), and not as simply as it could. The attached patch does the following: - remove test_json.py - rename json_tests to test_json (to match all other tests, following the example of test_email and test_importlib) - remove main() and 'if __name__ == "__main__"' stanza from __init__.py - rename test_suite() to load_tests(*args) - Add test_json/__main__.py, which calls unittest.main I believe this is the simplest, cleanest way to convert the json tests from test_main to unittest.main(). The patch is against 3.3; there are changes in 3.4 that make a patch against it not apply to 3.3. It merges forward easily, though. ---------- components: Tests files: test_json_discovery-3.3.diff keywords: patch messages: 191537 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Simplify calling and discovery of json test package type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30658/test_json_discovery-3.3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 21 03:08:08 2013 From: report at bugs.python.org (William Moreno) Date: Fri, 21 Jun 2013 01:08:08 +0000 Subject: [New-bugs-announce] [issue18274] python: not found Message-ID: <1371776888.26.0.530837339341.issue18274@psf.upfronthosting.co.za> New submission from William Moreno: mklib: Making FreeBSD static library: librtasm.a gmake[4]: Leaving directory `/usr/ports/graphics/libGL/work/Mesa-7.6.1/src/gallium/auxiliary/rtasm' gmake[4]: Entering directory `/usr/ports/graphics/libGL/work/Mesa-7.6.1/src/gallium/auxiliary/util' python u_format_access.py u_format.csv > u_format_access.c python u_format_table.py u_format.csv > u_format_table.c python: not found python: not found gmake[4]: *** No rule to make target `u_format_access.c', needed by `depend'. Stop. gmake[4]: Leaving directory `/usr/ports/graphics/libGL/work/Mesa-7.6.1/src/gallium/auxiliary/util' gmake[3]: *** [default] Error 1 gmake[3]: Leaving directory `/usr/ports/graphics/libGL/work/Mesa-7.6.1/src/gallium/auxiliary' gmake[2]: *** [default] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/libGL/work/Mesa-7.6.1/src/gallium' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/usr/ports/graphics/libGL/work/Mesa-7.6.1/src' gmake: *** [default] Error 1 *** [do-build] Error code 1 Stop in /usr/ports/graphics/libGL. ---------- components: Build messages: 191545 nosy: wmoreno3 priority: normal severity: normal status: open title: python: not found type: compile error versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 21 03:33:23 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 21 Jun 2013 01:33:23 +0000 Subject: [New-bugs-announce] [issue18275] Make isinstance() work with super type instances Message-ID: <1371778403.78.0.702907758656.issue18275@psf.upfronthosting.co.za> New submission from Brett Cannon: class A: pass class B(A): pass sup = super(B, B()) isinstance(sup, A) # returns False Why is that? Is there an explicit reason to prevent that isinstance check from working? How about just for ABCs? Either way it's annoying that at least for ABCs you can't check against a super object. ---------- components: Interpreter Core messages: 191550 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Make isinstance() work with super type instances type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 21 13:12:42 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Jun 2013 11:12:42 +0000 Subject: [New-bugs-announce] [issue18276] posixpath.c:_fd_converter() should use PyObject_AsFileDescriptor() Message-ID: <1371813162.19.0.902104537883.issue18276@psf.upfronthosting.co.za> New submission from Christian Heimes: I suggest that posixpath.c:_fd_converter() should PyObject_AsFileDescriptor() to convert a Python object to a fd integer. With PyObject_AsFileDescriptor() functions such as os.chmod() can be called with an opened file as first argument: Now: with open("somefile") as f: os.chmod(f.fileno(), 0o644) With PyObject_AsFileDescriptor(): with open("somefile") as f: os.chmod(f, 0o644) _fd_converter() also has more elaborate overflow checks. These checks should be added to PyObject_AsFileDescriptor(), too. ---------- messages: 191563 nosy: christian.heimes priority: normal severity: normal stage: needs patch status: open title: posixpath.c:_fd_converter() should use PyObject_AsFileDescriptor() type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 21 13:30:16 2013 From: report at bugs.python.org (shwouchk) Date: Fri, 21 Jun 2013 11:30:16 +0000 Subject: [New-bugs-announce] [issue18277] Queue is empty right after put from the same process/thread Message-ID: <1371814216.9.0.944814100336.issue18277@psf.upfronthosting.co.za> New submission from shwouchk: Consider this: $ python Python 2.7.4 (default, Apr 19 2013, 18:28:01) [GCC 4.7.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import multiprocessing as mp >>> q = mp.Queue() >>> while True: q.put(1) q.get_nowait() Traceback (most recent call last): File "", line 3, in File "/usr/lib/python2.7/multiprocessing/queues.py", line 152, in get_nowait return self.get(False) File "/usr/lib/python2.7/multiprocessing/queues.py", line 134, in get raise Empty Queue.Empty I believe that similar behavior could be seen in cPython 2.7.3 with the Queue.Queue implementation, but I can't reproduce it now and don't have the old version to test. And it is irrelevant anyway since it work "correctly" now. I think this behavior is counter intuitive and hampers the development of code that performs stuff with queues in a generic way and works in both single and multi-process environments. ---------- components: IO, Interpreter Core messages: 191566 nosy: shwouchk priority: normal severity: normal status: open title: Queue is empty right after put from the same process/thread type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 21 19:31:21 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 21 Jun 2013 17:31:21 +0000 Subject: [New-bugs-announce] [issue18278] Clarify the loader requirements for importlib.machinery.FileFinder Message-ID: <1371835881.83.0.662808557913.issue18278@psf.upfronthosting.co.za> New submission from Brett Cannon: Should specify the loader needs to be a callable which accepts two arguments: module name and found file path. ---------- assignee: brett.cannon components: Documentation messages: 191599 nosy: brett.cannon priority: low severity: normal stage: needs patch status: open title: Clarify the loader requirements for importlib.machinery.FileFinder versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 22 00:37:53 2013 From: report at bugs.python.org (Phil Webster) Date: Fri, 21 Jun 2013 22:37:53 +0000 Subject: [New-bugs-announce] [issue18279] IDLE Unit test for RstripExtension.py Message-ID: <1371854273.68.0.541594598967.issue18279@psf.upfronthosting.co.za> New submission from Phil Webster: This is a single test for RstripExtension.py, following from #15392. I also added a mock EditorWindow module with a Text widget for testing. test_rstripextension.py seems to run fine inside IDLE and produces the following output: >>> test_do_rstrip (__main__.Test_rstripextension) ... ok ---------------------------------------------------------------------- Ran 1 test in 0.100s OK However, when I run via the command line, I get the following output: philwebster at ubuntu:~/Dev/cpython$ ./python -m test -ugui test_idle [1/1] test_idle Warning -- warnings.showwarning was modified by test_idle 1 test altered the execution environment: test_idle I attempted to replicate the results from #18189, but saw the same message. Any thoughts? ---------- components: IDLE messages: 191618 nosy: JayKrish, philwebster priority: normal severity: normal status: open title: IDLE Unit test for RstripExtension.py type: enhancement versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 22 10:28:34 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Jun 2013 08:28:34 +0000 Subject: [New-bugs-announce] [issue18280] Documentation is too personalized Message-ID: <1371889714.5.0.753258621658.issue18280@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Some documentation files contain a number of I/my/me. Looks like they grew from personal modules and personal articles. Perhaps the official documentation needs more depersonalized style. Here is full list of such files: Doc/c-api/exceptions.rst Doc/c-api/long.rst Doc/distutils/builtdist.rst Doc/extending/extending.rst Doc/extending/windows.rst Doc/howto/argparse.rst Doc/howto/curses.rst Doc/howto/functional.rst Doc/howto/regex.rst Doc/howto/sockets.rst Doc/howto/urllib2.rst Doc/install/index.rst Doc/library/audioop.rst Doc/library/ctypes.rst Doc/library/doctest.rst Doc/library/heapq.rst Doc/library/numbers.rst Doc/library/ossaudiodev.rst Doc/library/tk.rst Doc/library/unittest.mock-examples.rst Doc/library/unittest.mock.rst Doc/reference/introduction.rst Doc/tutorial/classes.rst The list doesn't include FAQs where it may be appropriate and whatsnew files. Andrew Kuchling recently has fixed Doc/howto/unicode.rst for this issue (as part of issue4153). ---------- assignee: docs at python components: Documentation messages: 191636 nosy: akuchling, docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka priority: normal severity: normal status: open title: Documentation is too personalized versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 22 16:41:18 2013 From: report at bugs.python.org (Christian Heimes) Date: Sat, 22 Jun 2013 14:41:18 +0000 Subject: [New-bugs-announce] [issue18281] tarfile defines stat constants Message-ID: <1371912078.43.0.227039082522.issue18281@psf.upfronthosting.co.za> New submission from Christian Heimes: The tarfile module defines a bunch of stat constants: http://hg.python.org/cpython/file/4465f273a8a4/Lib/tarfile.py#l142 These constants aren't documented but they look like public API constants. I would like to replace them with values from the stat module: TUREAD = stat.S_IRUSR ---------- components: Library (Lib) messages: 191641 nosy: christian.heimes priority: low severity: normal stage: needs patch status: open title: tarfile defines stat constants type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 22 16:54:24 2013 From: report at bugs.python.org (Sworddragon) Date: Sat, 22 Jun 2013 14:54:24 +0000 Subject: [New-bugs-announce] [issue18282] Ugly behavior of binary and unicode handling on reading unknown encoded files Message-ID: <1371912864.83.0.123376262998.issue18282@psf.upfronthosting.co.za> New submission from Sworddragon: Currently Python 3 has some problems of handling files with an unknown encoding. In this example we have a file encoded as ISO-8859-1 with the content "?" which should be tried to be read. Lets see what Python 3 can currently do here: 1. We can simply open the file and try to read the content. The encoding will be set in my case automatically to UTF-8. But the read() operation will throw an exception: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 0: unexpected end of data 2. Now lets look a little more into the arguments of open(): We will find an errors argument which could maybe be useful: 2.1. "strict" is the default behavior which was already tested. 2.2. "ignore" will not throw any exception but delete any character which can't be read. This would be problematic in many cases. 2.3. "replace" will replace any character which can't be read which will be problematic in many cases too. 2.4. "surrogateescape" can throw exceptions too: UnicodeEncodeError: 'utf-8' codec can't encode character '\udce4' in position 0: surrogates not allowed 2.5. "xmlcharrefreplace" and "backslashreplace" are not used for reading. 3. Since trying to decode the file will make many problems we can try to read the file as binary content. This will work in all cases but causing another problem: Any unicode string that must be concatenated with the content of the file must be converted to a binary string too (like b'some_unicode_content' or some_unicode_variable.encode()). The same happens for unicode strings that must be concatenated somewhere else with the newly converted unicode_to_binary variable even if they doesn't touch the file content. This behavior can affect the maintainability in a bad way. As you can see all current solutions of Python 3 have big disadvantages. If I'm overlooking something feel free to correct me. Currently I have developed my own solution in Python which solved the problem: A function that autodetects the encoding of the file. Maybe there could also be a native way to do this on open() or maybe there could be another way found to solve this problem. ---------- components: IO messages: 191643 nosy: Sworddragon priority: normal severity: normal status: open title: Ugly behavior of binary and unicode handling on reading unknown encoded files type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 22 17:29:11 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 22 Jun 2013 15:29:11 +0000 Subject: [New-bugs-announce] [issue18283] shutil.which() should support bytes Message-ID: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: shutil.which() should support bytes. Some other functions in shutil module support bytes. >>> shutil.which("echo") '/bin/echo' >>> shutil.which(b"echo") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/shutil.py", line 1126, in which name = os.path.join(dir, thefile) File "/usr/lib64/python3.3/posixpath.py", line 92, in join "components.") from None TypeError: Can't mix strings and bytes in path components. >>> shutil.which("echo", path="/bin") '/bin/echo' >>> shutil.which("echo", path=b"/bin") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/shutil.py", line 1098, in which path = path.split(os.pathsep) TypeError: Type str doesn't support the buffer API >>> shutil.which(b"echo", path=b"/bin") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/shutil.py", line 1098, in which path = path.split(os.pathsep) TypeError: Type str doesn't support the buffer API ---------- components: Library (Lib) messages: 191644 nosy: Arfrever, hynek, tarek priority: normal severity: normal status: open title: shutil.which() should support bytes versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 22 20:44:35 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Jun 2013 18:44:35 +0000 Subject: [New-bugs-announce] [issue18284] Doc make html: KeyError: 'howto/advocacy' Message-ID: <1371926675.0.0.253994093951.issue18284@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Win 7, make html, 2.7 and 3.3. writing output... [ 20%] howto/advocacy Exception occurred: File "F:\Python\dev\py33\Doc\tools\sphinx\environment.py", line 1063, in get_toc_for toc = self.tocs[docname].deepcopy() KeyError: 'howto/advocacy' and process stops. Since update did not change the sphinx install that worked when I last tried this (April), I presume error is in our sources rather than Sphinx. ---------- assignee: docs at python components: Documentation files: sphinx-err-xoinkq.log messages: 191654 nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, terry.reedy priority: normal severity: normal status: open title: Doc make html: KeyError: 'howto/advocacy' type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30668/sphinx-err-xoinkq.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 22 20:55:09 2013 From: report at bugs.python.org (py.user) Date: Sat, 22 Jun 2013 18:55:09 +0000 Subject: [New-bugs-announce] [issue18285] In itertools.product() add argument repeat to the docstring Message-ID: <1371927309.79.0.490510498207.issue18285@psf.upfronthosting.co.za> New submission from py.user: >>> import itertools >>> print(itertools.product.__doc__) product(*iterables) --> product object Cartesian product of input iterables. Equivalent to nested for-loops. ... ---------- assignee: docs at python components: Documentation messages: 191658 nosy: docs at python, py.user priority: normal severity: normal status: open title: In itertools.product() add argument repeat to the docstring versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 22 21:14:48 2013 From: report at bugs.python.org (Jon Irenicus) Date: Sat, 22 Jun 2013 19:14:48 +0000 Subject: [New-bugs-announce] [issue18286] Python 3.3 - Slowing down computer Message-ID: <1371928488.87.0.904340213253.issue18286@psf.upfronthosting.co.za> New submission from Jon Irenicus: Python's really slowing my computer down. After running my script, the computer grinds to a halt and it's performance drops. Even after a reboot, the problem still persists. ---------- components: Windows messages: 191661 nosy: jon_irenicus priority: normal severity: normal status: open title: Python 3.3 - Slowing down computer type: performance versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 23 17:12:52 2013 From: report at bugs.python.org (Niklas Koep) Date: Sun, 23 Jun 2013 15:12:52 +0000 Subject: [New-bugs-announce] [issue18287] PyType_Ready() should sanity-check the tp_name field Message-ID: <1372000372.42.0.425313116494.issue18287@psf.upfronthosting.co.za> New submission from Niklas Koep: I noticed that defining a new type where the tp_name field is NULL causes segfaults, for instance, when calling pydoc on the extension module. This particular segfault traces back to type_module() in Objects/typeobject.c where tp_name is passed to strrchr(). Raising an appropriate exception from PyType_Ready() seems sensible to avoid this kind of issue. The field is also used in two calls to PyErr_Format() in PyType_Ready() itself where it'll cause segfaults if not handled properly. While we're on the subject, pydoc doesn't list the type documentation if the tp_name string does not have a dot in it. I didn't research this any further as omitting dots seems to be valid according to the docs. However, at the very least it seems like this side effect should be mentioned in the documentation to avoid confusion when someone omits/forgets the package..module.type hierarchy in the field definition. I attached a tiny patch which just jumps to PyType_Ready()'s error label if the field is NULL. I also added a comment about pydoc in the two places of the documentation I could think of where tp_name is mentioned. ---------- components: Interpreter Core files: patch messages: 191705 nosy: nkoep priority: normal severity: normal status: open title: PyType_Ready() should sanity-check the tp_name field type: crash versions: Python 3.5 Added file: http://bugs.python.org/file30678/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 23 21:10:49 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 23 Jun 2013 19:10:49 +0000 Subject: [New-bugs-announce] [issue18288] Idle 2.7: Run Module does not set __file__ Message-ID: <1372014649.46.0.451507262065.issue18288@psf.upfronthosting.co.za> New submission from Terry J. Reedy: This is a 2.7 only bug. F:\Python\mypy\tem2.py ---- print (__file__) __file__ should be set to relative or absolute path. >From command line: F:\Python\mypy> c:/programs/python27/python.exe tem2.py tem2.py F:\Python\mypy> c:/programs/python27/python.exe -m tem2 F:\Python\mypy\tem2.py 3.3 gives same results. >From Idle editor window with Run Module (F5): 3.3: >>> F:\Python\mypy\tem2.py # same as python -m above, and same as when file is imported. 2.7: >>> Traceback (most recent call last): File "F:\Python\mypy\tem2.py", line 1, in print (__file__) NameError: name '__file__' is not defined This is the bug to be fixed, if reasonably possible. Both 2.7 and 3.3 set __file__ on regular import (or rather, Idle does not disable this). >>> import tem2 F:\Python\mypy\tem2.py I think the first step should be to try this on non-Windows systems. ---------- components: IDLE messages: 191721 nosy: Todd.Rovito, roger.serwy, terry.reedy priority: normal severity: normal stage: test needed status: open title: Idle 2.7: Run Module does not set __file__ type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 24 06:08:37 2013 From: report at bugs.python.org (Max Kaye) Date: Mon, 24 Jun 2013 04:08:37 +0000 Subject: [New-bugs-announce] [issue18289] Segmentation Fault using round() Message-ID: <1372046917.43.0.988841016926.issue18289@psf.upfronthosting.co.za> New submission from Max Kaye: Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> print round(1.123456, 3) 1.123 >>> print round(1.123756, 3) Segmentation fault: 11 This doesn't happen if you just do the second round, only if you do both. `python -c "print round(1.123456, 3); print round(1.123756, 3)"` doesn't segfault. Doesn't segfault on brew's python: Python 2.7.3 (default, May 19 2013, 04:22:38) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.51)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> print round(1.123456, 3) 1.123 >>> print round(1.123756, 3) 1.124 >>> Doesn't segfault on another box: Python 2.7.2+ (default, Jul 20 2012, 22:12:53) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print round(1.123456, 3) 1.123 >>> print round(1.123756, 3) 1.124 >>> OSX Log File: (goes to EOF) Process: Python [5423] Path: /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: 2.7.3 (2.7.3) Code Type: X86-64 (Native) Parent Process: bash [1219] Responsible: iTerm [442] User ID: 501 Date/Time: 2013-06-24 13:55:56.871 +1000 OS Version: Mac OS X 10.9 (13A476u) Report Version: 11 Anonymous UUID: D8CE5653-35DD-5963-C8C9-E5012E41FDEE Sleep/Wake UUID: 9C40804C-F025-4E16-A61A-D1E9D9F68DD3 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 VM Regions Near 0: --> __TEXT 0000000100000000-0000000100001000 [ 4K] r-x/rwx SM=COW /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 readline.so 0x00000001002eff97 call_readline + 647 1 org.python.python 0x0000000100008852 PyOS_Readline + 274 2 org.python.python 0x000000010000a0a8 tok_nextc + 104 3 org.python.python 0x000000010000a853 PyTokenizer_Get + 147 4 org.python.python 0x000000010000544a parsetok + 218 5 org.python.python 0x00000001000e7722 PyParser_ASTFromFile + 146 6 org.python.python 0x00000001000e8983 PyRun_InteractiveOneFlags + 243 7 org.python.python 0x00000001000e8c6e PyRun_InteractiveLoopFlags + 78 8 org.python.python 0x00000001000e9451 PyRun_AnyFileExFlags + 161 9 org.python.python 0x000000010010006d Py_Main + 3085 10 org.python.python 0x0000000100000f14 0x100000000 + 3860 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x0000000100600000 rcx: 0x0000000100600000 rdx: 0x0000000000002800 rdi: 0x0000000000000000 rsi: 0x00000001002f0254 rbp: 0x00007fff5fbff620 rsp: 0x00007fff5fbff550 r8: 0x0000000100600000 r9: 0x0000000000000000 r10: 0x0000000000000007 r11: 0x0000000000000001 r12: 0x0000000000000001 r13: 0x0000000000000018 r14: 0x00007fff5fbff5e0 r15: 0x00007fff5fbff560 rip: 0x00000001002eff97 rfl: 0x0000000000010206 cr2: 0x0000000000000000 Logical CPU: 4 Error Code: 0x00000004 Trap Number: 14 Binary Images: 0x100000000 - 0x100000fff +org.python.python (2.7.3 - 2.7.3) /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python 0x100003000 - 0x10016dff7 +org.python.python (2.7.3, [c] 2004-2012 Python Software Foundation. - 2.7.3) <4F9EF48A-7D0C-0C1A-670B-3BF4E72C8696> /Library/Frameworks/Python.framework/Versions/2.7/Python 0x1002ee000 - 0x1002f0fff +readline.so (???) /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/readline.so 0x1004f0000 - 0x10050effb libedit.2.dylib (39) <24343EDB-E64F-34DC-8632-68C9E44E0FF7> /usr/lib/libedit.2.dylib 0x7fff66a19000 - 0x7fff66a4c987 dyld (236) /usr/lib/dyld 0x7fff8201f000 - 0x7fff82026ff3 libcopyfile.dylib (103) <7925E83E-6C96-38AD-9E53-AA9AE7C9E406> /usr/lib/system/libcopyfile.dylib 0x7fff82062000 - 0x7fff82063ff7 libsystem_blocks.dylib (63) /usr/lib/system/libsystem_blocks.dylib 0x7fff823cd000 - 0x7fff823f4ff3 libsystem_info.dylib (449) <6080681C-A561-3458-AA51-4DBE6D4E36B2> /usr/lib/system/libsystem_info.dylib 0x7fff82460000 - 0x7fff82466fef libsystem_platform.dylib (20.0.0.0.1) /usr/lib/system/libsystem_platform.dylib 0x7fff82514000 - 0x7fff8251bff7 liblaunch.dylib (841) <0554A59B-30EE-3E01-A5F6-3676F4B060B2> /usr/lib/system/liblaunch.dylib 0x7fff826d3000 - 0x7fff826d3ff7 libkeymgr.dylib (28) /usr/lib/system/libkeymgr.dylib 0x7fff829d4000 - 0x7fff829d5ffb libremovefile.dylib (33) /usr/lib/system/libremovefile.dylib 0x7fff83972000 - 0x7fff839b4ff7 libauto.dylib (185.4) <4B2CABC5-1F75-3225-81B4-882AEAE31ADC> /usr/lib/libauto.dylib 0x7fff84188000 - 0x7fff8418ffff libcompiler_rt.dylib (35) <9348DDF4-A5A7-3FDA-95E8-5018F88DC3AE> /usr/lib/system/libcompiler_rt.dylib 0x7fff84190000 - 0x7fff84191fff libunc.dylib (28) <34E818C3-373C-3564-8941-D9161473FD8A> /usr/lib/system/libunc.dylib 0x7fff8478c000 - 0x7fff8478ffff libsystem_stats.dylib (91.0.0.1.5) /usr/lib/system/libsystem_stats.dylib 0x7fff84790000 - 0x7fff847b7ff7 libsystem_network.dylib (241.2) <377DF6DA-A545-3146-A2B0-69B7D4492FB2> /usr/lib/system/libsystem_network.dylib 0x7fff85ae6000 - 0x7fff85ae9ff7 libdyld.dylib (236) <35641DC4-9D32-302F-BBE4-2B2E8A3D1D6B> /usr/lib/system/libdyld.dylib 0x7fff86229000 - 0x7fff8624afff libc++abi.dylib (41) /usr/lib/libc++abi.dylib 0x7fff87095000 - 0x7fff870c4fd2 libsystem_m.dylib (3047.15) <471B9063-4C93-3157-A862-AD84E3620182> /usr/lib/system/libsystem_m.dylib 0x7fff870c6000 - 0x7fff870d7ff7 libsystem_asl.dylib (215) <0995D278-3165-324E-8B35-936EA612ACD1> /usr/lib/system/libsystem_asl.dylib 0x7fff88073000 - 0x7fff8808dfff libsystem_malloc.dylib (23) <987C72AA-A2B3-3AD8-8616-D8A04B7440EF> /usr/lib/system/libsystem_malloc.dylib 0x7fff88c56000 - 0x7fff88c58ff3 libsystem_configuration.dylib (589) /usr/lib/system/libsystem_configuration.dylib 0x7fff88ce4000 - 0x7fff88ce5ff7 libsystem_sandbox.dylib (272) /usr/lib/system/libsystem_sandbox.dylib 0x7fff88f00000 - 0x7fff88f01ff7 libDiagnosticMessagesClient.dylib (100) /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff88f02000 - 0x7fff88f0cfff libcommonCrypto.dylib (60047) <68F03BCA-58FD-39CC-878D-B7F6283102E5> /usr/lib/system/libcommonCrypto.dylib 0x7fff88f82000 - 0x7fff8900bff7 libsystem_c.dylib (995) <82F1BDE9-FD58-3749-9837-15ADC6909E0A> /usr/lib/system/libsystem_c.dylib 0x7fff89b93000 - 0x7fff89d4bffb libicucore.A.dylib (511.13) <552A1606-39B8-3A4F-A975-73838AC1FDD6> /usr/lib/libicucore.A.dylib 0x7fff8a265000 - 0x7fff8a267fff libquarantine.dylib (65) <8791F59F-9F9F-3A24-83C4-BFD04CF589EA> /usr/lib/system/libquarantine.dylib 0x7fff8a5ec000 - 0x7fff8a5f5ff3 libsystem_notify.dylib (121) <549072AF-B6C9-3F63-8027-72E70CAF91E4> /usr/lib/system/libsystem_notify.dylib 0x7fff8a5fc000 - 0x7fff8a62cfff libncurses.5.4.dylib (42) /usr/lib/libncurses.5.4.dylib 0x7fff8af11000 - 0x7fff8af63fff libc++.1.dylib (118) /usr/lib/libc++.1.dylib 0x7fff8c7e4000 - 0x7fff8c7e8ff7 libcache.dylib (61) /usr/lib/system/libcache.dylib 0x7fff8d234000 - 0x7fff8d24eff7 libdispatch.dylib (338.0.0.0.1) <280908EF-A853-3653-A5B0-ED2668057F26> /usr/lib/system/libdispatch.dylib 0x7fff8d262000 - 0x7fff8d263ff3 libSystem.B.dylib (1197) <3EE2A53C-6274-3FE4-AF73-E6BC8054D6EB> /usr/lib/libSystem.B.dylib 0x7fff8d6d1000 - 0x7fff8d6d6ff7 libunwind.dylib (35.3) <56390AC7-A945-3A4B-9E83-305EF4828104> /usr/lib/system/libunwind.dylib 0x7fff8e439000 - 0x7fff8e440ff7 libsystem_pthread.dylib (52) /usr/lib/system/libsystem_pthread.dylib 0x7fff8e441000 - 0x7fff8e625fff com.apple.CoreFoundation (6.9 - 839.13) <048EF287-A909-3CF5-B077-D885BCC0CE5F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8e9ba000 - 0x7fff8e9d5ff7 libsystem_kernel.dylib (2422.1.4.1.8) <49597BCD-66AE-3511-A739-ADCC5F15EBF5> /usr/lib/system/libsystem_kernel.dylib 0x7fff8ea31000 - 0x7fff8ea39fff libsystem_dnssd.dylib (519.0.71) <69EC92C2-E2E4-315E-AE65-B20E6BA117F8> /usr/lib/system/libsystem_dnssd.dylib 0x7fff8ea74000 - 0x7fff8eac2ff7 libcorecrypto.dylib (159) <9597C75C-2559-319C-B991-9A955C69C325> /usr/lib/system/libcorecrypto.dylib 0x7fff8eb14000 - 0x7fff8eb36fff libxpc.dylib (296.0.0.1.1) <4D58910D-3A78-3E94-A00F-C8184A51592B> /usr/lib/system/libxpc.dylib 0x7fff8ebaa000 - 0x7fff8ed57f37 libobjc.A.dylib (548) /usr/lib/libobjc.A.dylib 0x7fff8efcb000 - 0x7fff8efd0fff libmacho.dylib (845) <042598A7-4439-3CF6-8D51-FA41B43A52E7> /usr/lib/system/libmacho.dylib 0x7fff8f2d1000 - 0x7fff8f2e2ff7 libz.1.dylib (53) <372E2641-66CA-3B13-8BE6-3A4335F861A6> /usr/lib/libz.1.dylib External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 698403 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=74.5M resident=14.9M(20%) swapped_out_or_unallocated=59.6M(80%) Writable regions: Total=19.9M written=2144K(11%) resident=2816K(14%) swapped_out=0K(0%) unallocated=17.2M(86%) REGION TYPE VIRTUAL =========== ======= Kernel Alloc Once 4K MALLOC 11.6M MALLOC (admin) 16K STACK GUARD 56.0M Stack 8192K VM_ALLOCATE 8K __DATA 1452K __LINKEDIT 64.1M __TEXT 10.4M __UNICODE 544K shared memory 4K =========== ======= TOTAL 152.1M Model: MacBookPro10,1, BootROM MBP101.00EE.B02, 4 processors, Intel Core i7, 2.3 GHz, 8 GB, SMC 2.3f35 Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 1024 MB Graphics: NVIDIA GeForce GT 650M, NVIDIA GeForce GT 650M, PCIe, 1024 MB Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533642465238432D50422020 Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533642465238432D50422020 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xEF), Broadcom BCM43xx 1.0 (6.30.223.82.10) Bluetooth: Version 4.2.0b3 12469, 3 services, 21 devices, 3 incoming serial ports Network Service: Wi-Fi, AirPort, en0 Serial ATA Device: APPLE SSD SM256E, 251 GB USB Device: hub_device USB Device: FaceTime HD Camera (Built-in) USB Device: hub_device USB Device: hub_device USB Device: BRCM20702 Hub USB Device: Bluetooth USB Host Controller USB Device: Apple Internal Keyboard / Trackpad ---------- messages: 191741 nosy: Max.Kaye priority: normal severity: normal status: open title: Segmentation Fault using round() versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 24 06:46:19 2013 From: report at bugs.python.org (Antti Haapala) Date: Mon, 24 Jun 2013 04:46:19 +0000 Subject: [New-bugs-announce] [issue18290] json encoder does not support JSONP/JavaScript safe escaping Message-ID: <1372049179.79.0.237326954931.issue18290@psf.upfronthosting.co.za> New submission from Antti Haapala: JSON is not a strict superset of JavaScript (http://timelessrepo.com/json-isnt-a-javascript-subset). However, certain web technologies use JSON values as a part of JavaScript code (JSONP, inline tag, no < cannot be escaped; however only the string '' (or sometimes "} embedded in inline javascript. The only correct way to escape such content in inline html is to escape all / into \/. The \u2028, \u2029 problem is more subtle and can break not only inline javascript but also JSONP. Thus there an incorrect value injected by a malicious or unwitting user to the database might break the entire protocol. The current solution is to re-escape everything that comes out of JSON encoder. The best solution for python would be to make these 3 escapes default in the python json module (notice again that the current set of default escapes when ensure_ascii=False is chosen arbitrarily), or if not default, then at least they could be enabled by a switch. Furthermore, documentation should be updated appropriately, to explain why such escape is needed. ---------- components: Library (Lib) messages: 191742 nosy: Ztane priority: normal severity: normal status: open title: json encoder does not support JSONP/JavaScript safe escaping type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 24 15:11:12 2013 From: report at bugs.python.org (Paul) Date: Mon, 24 Jun 2013 13:11:12 +0000 Subject: [New-bugs-announce] [issue18291] codecs.open interprets space as line ends Message-ID: <1372079472.71.0.230881178227.issue18291@psf.upfronthosting.co.za> New submission from Paul: I hope I am writing in the right place. When using codecs.open with UTF-8 encoding, it seems characters \x12, \x13, and \x14 are interpreted as end-of-line. Example code: >>> with open('unicodetest.txt', 'w') as f: >>> f.write('a'+chr(28)+'b'+chr(29)+'c'+chr(30)+'d'+chr(31)+'e') >>> with open('unicodetest.txt', 'r') as f: >>> for i,l in enumerate(f): >>> print i, l 0 a\x12b\x13c\x14d\x15e The point here is that it reads it as one line, as I would expect. But using codecs.open with UTF-8 encoding it reads it as many lines: >>> import codecs >>> with codecs.open('unicodetest.txt', 'r', 'UTF-8') as f: >>> for i,l in enumerate(f): >>> print i, l 0 a\x12 1 b\x13 2 c\x14 3 d\x15e The characters \x12 through \x15 are described as "Information Separator Four" through "One" (in that order). As far as I can see they never mark line ends. Also interestingly, \x15 isn't interpreted as such. As a sidenote, I tested and verified that io.open is correct (but when reading loads of data it appears to be 5 times slower than codecs): >>> import io >>> with io.open('unicodetest.txt', encoding='UTF-8') as f: >>> for i,l in enumerate(f): >>> print i, l 0 a\x12b\x13c\x14d\x15e ---------- components: IO, Unicode messages: 191758 nosy: ezio.melotti, wpk priority: normal severity: normal status: open title: codecs.open interprets space as line ends type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 24 20:29:14 2013 From: report at bugs.python.org (R. Jayakrishnan) Date: Mon, 24 Jun 2013 18:29:14 +0000 Subject: [New-bugs-announce] [issue18292] IDLE Improvements: Unit test for AutoExpand.py Message-ID: <1372098554.92.0.798687151295.issue18292@psf.upfronthosting.co.za> New submission from R. Jayakrishnan: Continuing the IDLE unittest framework initiated in #15392. Writing test for AutoExpand.py ---------- components: IDLE, Tests messages: 191795 nosy: JayKrish priority: normal severity: normal status: open title: IDLE Improvements: Unit test for AutoExpand.py type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 24 21:04:53 2013 From: report at bugs.python.org (mpb) Date: Mon, 24 Jun 2013 19:04:53 +0000 Subject: [New-bugs-announce] [issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates Message-ID: <1372100693.76.0.99629035685.issue18293@psf.upfronthosting.co.za> New submission from mpb: At present (Python 2.7.[45] and 3.3.[12]), the cert_reqs parameter of ssl.wrap_socket can be one of: ssl.CERT_NONE ssl.CERT_OPTIONAL ssl.CERT_REQUIRED I would find the following additional modes to be useful: ssl.CERT_OPTIONAL_NO_VERIFY ssl.CERT_REQUIRED_NO_VERIFY In these cases, the server's certificate would be available via the .getpeercert () method, even if the certificate does not pass verification. The use case for these modes would be connecting to servers, some of which may use valid certificates, and others of which may be using self signed certificates. Another use case might be an "ssh-like" mode of operation. ssh will warn the user of possible man-in-the-middle attacks if a server's public key has changed. Thanks! ---------- components: Library (Lib) messages: 191796 nosy: mpb priority: normal severity: normal status: open title: ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates type: enhancement versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 24 23:04:42 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Jun 2013 21:04:42 +0000 Subject: [New-bugs-announce] [issue18294] zlib module is not completly 64-bit safe Message-ID: <1372107882.97.0.731855490225.issue18294@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch fixes different compiler warnings on Windows x64 in the zlib module. The module raises OverflowError if some values are longer than INT_MAX, but not all parameters are checked. ---------- files: zlib_64bit.patch keywords: patch messages: 191799 nosy: haypo, loewis, serhiy.storchaka priority: normal severity: normal status: open title: zlib module is not completly 64-bit safe versions: Python 3.4 Added file: http://bugs.python.org/file30693/zlib_64bit.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 24 23:19:05 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Jun 2013 21:19:05 +0000 Subject: [New-bugs-announce] [issue18295] Possible integer overflow in PyCode_New() Message-ID: <1372108745.44.0.114375127897.issue18295@psf.upfronthosting.co.za> New submission from STINNER Victor: On Windows x64, we get the following warning: ..\Objects\codeobject.c(106): warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\pythoncore.vcxproj] Code: unsigned char *cell2arg = NULL; Py_ssize_t total_args = argcount + kwonlyargcount + ((flags & CO_VARARGS) != 0) + ((flags & CO_VARKEYWORDS) != 0); PyObject *cell = PyTuple_GET_ITEM(cellvars, i); for (j = 0; j < total_args; j++) { PyObject *arg = PyTuple_GET_ITEM(varnames, j); if (!PyUnicode_Compare(cell, arg)) { ====> cell2arg[i] = j; <===== HERE used_cell2arg = 1; break; } } total_args is not checked for being smaller than 256. Related issue: #9566. ---------- components: Interpreter Core messages: 191805 nosy: haypo priority: normal severity: normal status: open title: Possible integer overflow in PyCode_New() versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 25 02:25:42 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 25 Jun 2013 00:25:42 +0000 Subject: [New-bugs-announce] [issue18296] test_os.test_trailers() is failing on AMD64 FreeBSD 9.0 dtrace 3.x Message-ID: <1372119942.09.0.162654139201.issue18296@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.x/builds/1560/steps/test/logs/stdio ====================================================================== FAIL: test_trailers (test.test_os.TestSendfile) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd/build/Lib/test/test_os.py", line 1962, in test_trailers self.assertEqual(data, b"abcde12345") AssertionError: b'abcde\x00\x00\x00...\x00\x0012345' != b'abcde12345' Warning -- threading._dangling was modified by test_os test test_os failed (I replaced a long list of \x00 with "...") I don't understand why test_trailers() of test_os tries to copy 4096 bytes using os.sendto(), whereas the input file only contains 5 bytes. ---------- messages: 191827 nosy: haypo priority: normal severity: normal status: open title: test_os.test_trailers() is failing on AMD64 FreeBSD 9.0 dtrace 3.x versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 25 07:03:53 2013 From: report at bugs.python.org (py.user) Date: Tue, 25 Jun 2013 05:03:53 +0000 Subject: [New-bugs-announce] [issue18297] In range.sample() correct the ValueError message for negative k Message-ID: <1372136633.71.0.576354132285.issue18297@psf.upfronthosting.co.za> New submission from py.user: >>> random.sample('ABC', -1) Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/random.py", line 302, in sample raise ValueError("Sample larger than population") ValueError: Sample larger than population >>> ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 191832 nosy: docs at python, py.user priority: normal severity: normal status: open title: In range.sample() correct the ValueError message for negative k type: enhancement versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 25 11:09:46 2013 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 25 Jun 2013 09:09:46 +0000 Subject: [New-bugs-announce] [issue18298] pythonw.exe fails with redirected stdett Message-ID: <1372151386.07.0.939463937551.issue18298@psf.upfronthosting.co.za> New submission from anatoly techtonik: ---cut test.py--- print("-1-") open("-2-", "w").write("-3-") ---cut test.py--- > C:\Python27\pythonw.exe test.py > -4- > type -4- -1- > C:\Python27\pythonw.exe test.py 2> -4- > type -4- close failed in file object destructor: sys.excepthook is missing lost sys.stderr > C:\Python27\python.exe test.py 2> -4- -1- >type -4- > This may also affect subprocess calls under pythonw.exe I am running Python 2.7.3 ---------- messages: 191839 nosy: techtonik priority: normal severity: normal status: open title: pythonw.exe fails with redirected stdett versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 25 14:31:30 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 25 Jun 2013 12:31:30 +0000 Subject: [New-bugs-announce] [issue18299] Change script_helper to use universal_newlines=True in _assert_python Message-ID: <1372163490.54.0.858843080501.issue18299@psf.upfronthosting.co.za> New submission from R. David Murray: A look at a random selection of tests that use script_helper indicates that using universal_newlines=True would either simplify or make no difference to the usage of the script_helper assert_python functions in the majority of the tests that use it. Even if there turn out to be a few uses where having bytes is required, it would probably be worth catering to the common case and making those exceptional cases use Popen directly. (Or alternatively provide assert_python_xxx_binary helpers.) ---------- keywords: easy messages: 191854 nosy: r.david.murray priority: normal severity: normal stage: needs patch status: open title: Change script_helper to use universal_newlines=True in _assert_python type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 25 14:40:40 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 25 Jun 2013 12:40:40 +0000 Subject: [New-bugs-announce] [issue18300] script_helper._asert_python should set TERM='' by default. Message-ID: <1372164040.52.0.568545505593.issue18300@psf.upfronthosting.co.za> New submission from R. David Murray: See issue 11390 for a discussion, but briefly: there is a bug in the readline library that causes it, on some systems, to emit a control sequence on stdout when readline is first initialized and TERM is set to xterm. The bug can be avoided by setting TERM='', and since assert_python is often used to test output, the bogus characters can cause tests to fail on just some systems. _assert_python should therefore set TERM='' unless the TERM environment variable is passed explicitly by the caller. While this issue probably has minimal impact on the earlier python versions (where only doctest is likely to trigger this bug, because it calls pdb which calls readline), on 3.4 readline is always initialized, and therefore the bug is more likely to cause unexpected test failures. ---------- messages: 191856 nosy: r.david.murray priority: normal severity: normal stage: needs patch status: open title: script_helper._asert_python should set TERM='' by default. type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 25 20:58:43 2013 From: report at bugs.python.org (py.user) Date: Tue, 25 Jun 2013 18:58:43 +0000 Subject: [New-bugs-announce] [issue18301] In itertools.chain.from_iterable() there is no cls argument Message-ID: <1372186723.21.0.67533324157.issue18301@psf.upfronthosting.co.za> New submission from py.user: http://docs.python.org/2/library/itertools.html#itertools.chain.from_iterable >>> class A: ... @classmethod ... def from_iterable(iterables): ... for it in iterables: ... for element in it: ... yield element ... >>> A.from_iterable(['ABC', 'DEF']) Traceback (most recent call last): File "", line 1, in TypeError: from_iterable() takes 1 positional argument but 2 were given >>> ---------- assignee: docs at python components: Documentation files: issue.diff keywords: patch messages: 191874 nosy: docs at python, py.user priority: normal severity: normal status: open title: In itertools.chain.from_iterable() there is no cls argument type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30702/issue.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 25 21:06:45 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 25 Jun 2013 19:06:45 +0000 Subject: [New-bugs-announce] [issue18302] test_multiprocessing: test.support.import_module() does not ignore the ImportError on SemLock Message-ID: <1372187205.63.0.099845572882.issue18302@psf.upfronthosting.co.za> New submission from STINNER Victor: test.support.import_module() catchs ModuleNotFoundError instead of ImportError since the following changeset: changeset: 84106:c4d7228421df user: Brett Cannon date: Wed Jun 12 20:12:30 2013 -0400 files: Lib/test/regrtest.py Lib/test/support.py Lib/test/test___all__.py Lib/xmlrpc/server.py Lib/zipfile.py description: Move test___all__ over to unittest.main() and use ModuleNotFoundError The problem is that multiprocessing.synchronize raises an ImportError if _multiprocess.SemLock does not exist: # Try to import the mp.synchronize module cleanly, if it fails # raise ImportError for platforms lacking a working sem_open implementation. # See issue 3770 try: from X_multiprocessing import SemLock except (ImportError): raise ImportError("This platform lacks a functioning sem_open" + " implementation, therefore, the required" + " synchronization primitives needed will not" + " function, see issue 3770.") As a result, test_multiprocessing is no more skipped on FreeBSD 6.4, but the following traceback is written: http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%203.x/builds/3771/steps/test/logs/stdio Re-running test 'test_multiprocessing' in verbose mode test test_multiprocessing crashed -- Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/multiprocessing/synchronize.py", line 27, in from _multiprocessing import SemLock ModuleNotFoundError: cannot import name SemLock During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/regrtest.py", line 1300, in runtest_inner the_module = importlib.import_module(abstest) File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/importlib/__init__.py", line 93, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1614, in _gcd_import File "", line 1595, in _find_and_load File "", line 1562, in _find_and_load_unlocked File "", line 609, in _check_name_wrapper File "", line 1058, in load_module File "", line 928, in load_module File "", line 274, in _call_with_frames_removed File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_multiprocessing.py", line 30, in test.support.import_module('multiprocessing.synchronize') File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/support.py", line 123, in import_module return importlib.import_module(name) File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/importlib/__init__.py", line 93, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1614, in _gcd_import File "", line 1595, in _find_and_load File "", line 1562, in _find_and_load_unlocked File "", line 609, in _check_name_wrapper File "", line 1058, in load_module File "", line 928, in load_module File "", line 274, in _call_with_frames_removed File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/multiprocessing/synchronize.py", line 32, in " function, see issue 3770.") ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770. ---------- messages: 191876 nosy: brett.cannon, haypo, sbt priority: normal severity: normal status: open title: test_multiprocessing: test.support.import_module() does not ignore the ImportError on SemLock versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 25 23:43:54 2013 From: report at bugs.python.org (miscjunk) Date: Tue, 25 Jun 2013 21:43:54 +0000 Subject: [New-bugs-announce] [issue18303] json.dumps() claims numpy.bool_ is not serializable Message-ID: <1372196634.42.0.973833785971.issue18303@psf.upfronthosting.co.za> New submission from miscjunk: When json.dumps() is called on a numpy.bool_ object, it crashes. To recreate: import numpy as np import json a = np.array([1,2,3,4,5,6]) a = a < 5 json.dumps(a) #crash json.dumps(a[0]) #crash json.dumps(a.tolist()) #this works! Example of error output Traceback (most recent call last): File "", line 1, in File "..\python-3.3.2.amd64\lib\json\__init__.py", line 236, in dumps return _default_encoder.encode(obj) File "..\python-3.3.2.amd64\lib\json\encoder.py", line 191, in encode chunks = self.iterencode(o, _one_shot=True) File "..\python-3.3.2.amd64\lib\json\encoder.py", line 249, in iterencode return _iterencode(o, 0) File "..\python-3.3.2.amd64\lib\json\encoder.py", line 173, in default raise TypeError(repr(o) + " is not JSON serializable") TypeError: False is not JSON serializable ---------- components: Extension Modules, Library (Lib) messages: 191887 nosy: miscjunk priority: normal severity: normal status: open title: json.dumps() claims numpy.bool_ is not serializable type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 26 05:48:17 2013 From: report at bugs.python.org (Bryce Nesbitt) Date: Wed, 26 Jun 2013 03:48:17 +0000 Subject: [New-bugs-announce] [issue18304] ElementTree gets awkward to use if there is an xmlns Message-ID: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za> New submission from Bryce Nesbitt: ElementTree offers a wonderful and easy API for parsing XML... but if there is a namespace involved it suddenly gets ugly. This is a proposal to fix that. First an example: ------------------ !/usr/bin/python # Demonstrate awkward behavior of namespaces in ElementTree import xml.etree.cElementTree as ET xml_sample_one = """\ """ root = ET.fromstring(xml_sample_one) for child in root.iter('thing'): print child.tag xml_sample_two = """\ """ root = ET.fromstring(xml_sample_two) for child in root.iter('{http://josm.openstreetmap.de/tagging-preset-1.0}thing'): print child.tag ------------------ Because of the namespace in the 2nd example, a {namespace} name keeps {namespace} getting {namespace} in {namespace} {namespace} the way. Online there are dozens of question on how to deal with this, for example: http://stackoverflow.com/questions/11226247/python-ignore-xmlns-in-elementtree-elementtree With wonderfully syntactic solutions like 'item.tag.split("}")[1][0:]' ----- How about if I could set any root to have an array of namespaces to suppress: root = ET.fromstring(xml_sample_two) root.xmlns_at_root.append('{namespace}') Or even just a boolean that says I'll take all my namespaces without qualification? ---------- components: Extension Modules messages: 191894 nosy: brycenesbitt priority: normal severity: normal status: open title: ElementTree gets awkward to use if there is an xmlns type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 26 08:33:59 2013 From: report at bugs.python.org (Sergey) Date: Wed, 26 Jun 2013 06:33:59 +0000 Subject: [New-bugs-announce] [issue18305] [patch] Fast sum() for non-numbers Message-ID: <1372228439.5.0.789865081817.issue18305@psf.upfronthosting.co.za> New submission from Sergey: Problem ======= Code: sum([[1,2,3]]*1000000, []) takes forever to complete. Suggestion ========== Patch sum() function so that it did not created 1000000 copies of result, but created just one. Attached patch does that. Before patch: $ ./python -mtimeit --setup="x=[[1,2,3]]*10000" "sum(x,[])" 10 loops, best of 3: 915 msec per loop After patch: $ ./python -mtimeit --setup="x=[[1,2,3]]*10000" "sum(x,[])" 1000 loops, best of 3: 469 usec per loop 200000% boost! :) Details ======= Built-in sum function could look like this: def sum(seq, start = 0): for item in seq: start += item return start But that would be bad, becaust in cases like: empty = [] result = sum(list_of_lists, empty) content of "empty" would be modified. So instead it looks like this: def sum(seq, start = 0): for item in seq: start = start + item return start it creates a copy of the entire partial result on EVERY "start + item". While instead it could look like this: def sum(seq, start = 0): start = start + seq[0:1] for item in seq[1:]: start += item return start create just ONE copy, and use it. That's what attached patch is doing. An alternative is something like this: def sum(seq, start = 0): start = copy.copy(start) for item in seq: start += item return start But I'm not sure how to make a copy of arbitrary object yet. ---------- components: Interpreter Core files: fastsum.patch keywords: patch messages: 191896 nosy: Sergey priority: normal severity: normal status: open title: [patch] Fast sum() for non-numbers type: performance versions: Python 2.7 Added file: http://bugs.python.org/file30705/fastsum.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 26 10:45:00 2013 From: report at bugs.python.org (John Jefferies) Date: Wed, 26 Jun 2013 08:45:00 +0000 Subject: [New-bugs-announce] [issue18306] os.stat gives exception for Windows junctions in v3.3 Message-ID: <1372236300.43.0.559187613539.issue18306@psf.upfronthosting.co.za> New submission from John Jefferies: If os.stat is executed on a Windows junction with Python 3.3 I see an exception: ------------ >>> import os >>> os.stat('C:\Windows\System32\config\systemprofile\SendTo') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [WinError 2] The system cannot find the file specified: 'C:\\Windows\\System32\\config\\systemprofile\\SendTo' ------------ whereas with Python 3.2 it works without error: ------------ >>> import os >>> os.stat('C:\Windows\System32\config\systemprofile\SendTo') nt.stat_result(st_mode=16895, st_ino=281474977136630, st_dev=0, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=1295885671, st_mtime=1295885671, st_ctime=1295885671) ------------ FTR. Some background: It's a pity that Python doesn't just treat Windows junctions as a normal soft link. But given that islink() returns False for a junction, I was able to work around that in Python 3.2 like this: ------------ if os.path.islink(fullname) or \ os.stat(fullname)[stat.ST_INO] != os.lstat(fullname)[stat.ST_INO]: # If it's not a link, it's probably a junction... ------------ Many thanks for looking. John ---------- components: Library (Lib) messages: 191899 nosy: John.Jefferies priority: normal severity: normal status: open title: os.stat gives exception for Windows junctions in v3.3 type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 26 16:27:09 2013 From: report at bugs.python.org (Vitaly Murashev) Date: Wed, 26 Jun 2013 14:27:09 +0000 Subject: [New-bugs-announce] [issue18307] Relative path in co_filename for zipped modules Message-ID: <1372256829.94.0.0966099631525.issue18307@psf.upfronthosting.co.za> New submission from Vitaly Murashev: Recently I found out that it not possible to debug python code if it is a part of zip-module. Python version being used is 3.3.0 Well known GUI debuggers like Eclipse+PyDev or PyCharm are unable to start debugging and give the following warning: --- pydev debugger: CRITICAL WARNING: This version of python seems to be incorrectly compiled (internal generated filenames are not absolute) pydev debugger: The debugger may still function, but it will work slower and may miss breakpoints. --- So I started my own investigation of this issue and results are the following. At first I took traditional python debugger 'pdb' to analyze how it behaves during debug of zipped module. 'pdb' showed me some backtaces and filename part for stack entries looks malformed. I expected something like 'full-path-to-zip-dir/my_zipped_module.zip/subdir/test_module.py' but realy it looks like 'full-path-to-current-dir/subdir/test_module.py' Source code in pdb.py and bdb.py (which one are a part of python stdlib) gave me the answer why it happens. The root cause are inside Bdb.format_stack_entry() + Bdb.canonic() Please take a look at the following line inside 'format_stack_entry' method: filename = self.canonic(frame.f_code.co_filename) For zipped module variable 'frame.f_code.co_filename' holds _relative_ file path started from the root of zip archive like 'subdir/test_module.py' And as relult Bdb.canonic() method gives what we have - 'full-path-to-current-dir/subdir/test_module.py' --- Looks like it is a bug in: - in python core subsystem which one is responsible for loading zipped modules - or in pdb debugger ---------- components: Interpreter Core, Library (Lib) messages: 191907 nosy: vmurashev priority: normal severity: normal status: open title: Relative path in co_filename for zipped modules type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 26 17:37:10 2013 From: report at bugs.python.org (David Edelsohn) Date: Wed, 26 Jun 2013 15:37:10 +0000 Subject: [New-bugs-announce] [issue18308] checkRecvmsgAddress wrong in test_socket.py (AIX failures) Message-ID: <1372261030.27.0.471709034157.issue18308@psf.upfronthosting.co.za> New submission from David Edelsohn: The recvmsg tests in test_socket.py check that the address returned by recvmsg matches the original address to which the socket was bound. For IPv6, sockaddr includes sin6_scope_id, in addition to the address and port. The test connects to host "::1", which is loopback, but is an under-specified address because the link scope is left ambiguous. The scope_id in the original bind call defaults to "0", which represents an ambiguous scoped address and allows the IPV6 protocol and implementation to choose the interface or site identifier. The recvmsg call returns the actual scope_id. The test incorrectly checks that the full sockaddr matches. sin6_scope_id may not match for IPv6 addresses. This generates bogus failures on AIX. (Microsoft has a good description about scope_id: http://msdn.microsoft.com/en-us/library/windows/desktop/ms739166%28v=vs.85%29.aspx) ---------- components: Tests messages: 191908 nosy: David.Edelsohn priority: normal severity: normal status: open title: checkRecvmsgAddress wrong in test_socket.py (AIX failures) type: behavior versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 26 18:00:50 2013 From: report at bugs.python.org (=?utf-8?q?Mathias_Fr=C3=B6hlich?=) Date: Wed, 26 Jun 2013 16:00:50 +0000 Subject: [New-bugs-announce] [issue18309] Make python slightly more relocatable Message-ID: <1372262450.0.0.792872111515.issue18309@psf.upfronthosting.co.za> New submission from Mathias Fr?hlich: Hi all, I want to move python a bit closer to be relocatable. One problem to solve is where python finds its modules. The usual lookup mechanism is to compile in a configure time determined prefix that is used as a last resort path if the paths are not set otherwise during application/interpreter startup. The most commonly known way to change the module path at startup time are probably the environment variables PYTHONPATH and PYTHONHOME. The python interpreter itself already tries to interpret argv[0] to get to this point, but it would be nice if an application embedded interpreter also finds its module path without providing this argv[0] directly to the python library. This should even work if being moved or being installed at a different path than the configure time prefix path. The proposal is to add an additional attempt to find the python modules just before we resort to the compiled in prefix by looking at the path to the python27.{so,dll}. Relative to this shared object python library file the python modules are searched in the usual way. If there are no python modules found relative to the python library file, the very last resort compiled in prefix is used as usual. For architectures where we cannot determine the path of the shared library file, nothing changes. I have attached a patch that tries to implement this. It should serve as a base for discussions. This change is tested on linux and behaves like expected. The windows code for this is copied over from an other project where I have this actively running. But this python code variant is not even compile tested on windows. thanks in advance Mathias ---------- components: Installation files: python-relative-path-lookup.diff keywords: patch messages: 191909 nosy: mathias priority: normal severity: normal status: open title: Make python slightly more relocatable versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file30706/python-relative-path-lookup.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 26 20:08:11 2013 From: report at bugs.python.org (py.user) Date: Wed, 26 Jun 2013 18:08:11 +0000 Subject: [New-bugs-announce] [issue18310] itertools.tee() can't accept keyword arguments Message-ID: <1372270091.7.0.0269629805126.issue18310@psf.upfronthosting.co.za> New submission from py.user: >>> import itertools >>> itertools.tee('x', n=2) Traceback (most recent call last): File "", line 1, in TypeError: tee() takes no keyword arguments >>> ---------- components: Library (Lib) messages: 191912 nosy: py.user priority: normal severity: normal status: open title: itertools.tee() can't accept keyword arguments type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 26 20:47:27 2013 From: report at bugs.python.org (mp) Date: Wed, 26 Jun 2013 18:47:27 +0000 Subject: [New-bugs-announce] [issue18311] Typo in SSL documentation Message-ID: <1372272447.34.0.872105507579.issue18311@psf.upfronthosting.co.za> New submission from mp: Under http://docs.python.org/3.4/library/ssl.html#ssl.SSLContext.set_npn_protocols "avertise" should be "advertise". This is in documentation for both 3.4 and 3.3 ---------- assignee: docs at python components: Documentation messages: 191913 nosy: docs at python, pfista priority: normal severity: normal status: open title: Typo in SSL documentation versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 27 03:27:44 2013 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 27 Jun 2013 01:27:44 +0000 Subject: [New-bugs-announce] [issue18312] "make distclean" deletes files under .hg directory Message-ID: <1372296464.66.0.963255474553.issue18312@psf.upfronthosting.co.za> New submission from Eric V. Smith: See: http://mail.python.org/pipermail/python-dev/2013-June/127068.html The find command: find $(srcdir) '(' -name '*.fdc' -o -name '*~' \ -o -name '[@,#]*' -o -name '*.old' \ -o -name '*.orig' -o -name '*.rej' \ -o -name '*.bak' ')' \ -exec rm -f {} ';' will walk into .hg (and other dot directories) and delete files there. The particular problem noted in the email was a filename beginning with '@'. Some suggestions are to change it to: find \( -type d -name .hg -prune \) -o ... or find $(srcdir)/[a-zA-Z]* ... Other suggestions are included in the thread starting at the above link. These include deleting the find command, or using "hg purge". I think that we have enough history of using and suggesting "make distclean" that we should just fix up the find command to do what it does now, but not recurse into any dot directories (.hg, .svn, .git, etc.). ---------- components: Build messages: 191928 nosy: eric.smith priority: normal severity: normal status: open title: "make distclean" deletes files under .hg directory type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 27 07:01:01 2013 From: report at bugs.python.org (py.user) Date: Thu, 27 Jun 2013 05:01:01 +0000 Subject: [New-bugs-announce] [issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword Message-ID: <1372309261.95.0.7034101172.issue18313@psf.upfronthosting.co.za> New submission from py.user: http://docs.python.org/3/library/itertools.html#itertools-recipes "def repeatfunc(func, times=None, *args):" >>> repeatfunc(lambda x: x, times=None, 1) File "", line 1 SyntaxError: non-keyword arg after keyword arg >>> >>> repeatfunc(lambda x: x, 1, times=None) Traceback (most recent call last): File "", line 1, in TypeError: repeatfunc() got multiple values for argument 'times' >>> ---------- assignee: docs at python components: Documentation messages: 191930 nosy: docs at python, py.user priority: normal severity: normal status: open title: In itertools recipes repeatfunc() defines a non-keyword argument as keyword type: enhancement versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 27 14:15:21 2013 From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=) Date: Thu, 27 Jun 2013 12:15:21 +0000 Subject: [New-bugs-announce] [issue18314] Have os.unlink remove junction points Message-ID: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> New submission from Kim Gr?sman: os.unlink currently raises a WindowsError (Access Denied) if I attempt to unlink an NTFS junction point. It looks trivial to allow Py_DeleteFileW [1] to remove junction points as well as proper symbolic links, as far as I can tell. For example, the ntfslink-python library [2] only checks if both FILE_ATTRIBUTE_DIRECTORY and FILE_ATTRIBUTE_REPARSE_POINT are set. RemoveDirectoryW is documented to handle junction points transparently, so it should just be a matter of passing the path on if it's a junction point or a symbolic link. My motivation for this is that I have used external tools to create junction points, and am now switching to symbolic links. When deleting a directory, I need to do: try: os.unlink(link_path) except WindowsError as detail: # BACKWARD COMPATIBILITY HACK if detail.winerror == 5: _delete_junction_point(link_path) else: raise which is a little funky. It seems like os.unlink semantics work just as well for junction points, even if they can't be created with os.symlink. Love it/hate it? [1] http://hg.python.org/cpython/file/44f455e6163d/Modules/posixmodule.c#l4105 [2] https://github.com/Juntalis/ntfslink-python/blob/2f6ff903f9b22942de8aa93a32a3d817124f359e/ntfslink/internals/__init__.py#L32 ---------- components: Windows messages: 191945 nosy: Kim.Gr?sman priority: normal severity: normal status: open title: Have os.unlink remove junction points type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 27 17:59:58 2013 From: report at bugs.python.org (Terrel Shumway) Date: Thu, 27 Jun 2013 15:59:58 +0000 Subject: [New-bugs-announce] [issue18315] bufsize parameter not documented in 2.7.5 Message-ID: <1372348798.45.0.272594255655.issue18315@psf.upfronthosting.co.za> New submission from Terrel Shumway: for line in fileinput.input(files,inplace,backup,"rU"): File "/usr/lib/python2.7/fileinput.py", line 253, in next line = self.readline() File "/usr/lib/python2.7/fileinput.py", line 346, in readline self._buffer = self._file.readlines(self._bufsize) TypeError: an integer is required According to the documentation, my code was correct. But somewhere along the line, someone added a 'bufsize' parameter and didn't update the docstrings. It's an easy fix, but I'll have to investigate when this broke. ---------- assignee: docs at python components: Documentation messages: 191952 nosy: Terrel.Shumway, docs at python priority: normal severity: normal status: open title: bufsize parameter not documented in 2.7.5 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 27 22:21:36 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 27 Jun 2013 20:21:36 +0000 Subject: [New-bugs-announce] [issue18316] Idle 2.7: update to simply cross-version patches Message-ID: <1372364496.41.0.313371812412.issue18316@psf.upfronthosting.co.za> New submission from Terry J. Reedy: In a commiters-list discussion of heuristics for what patches can go into non-Idle 2.7, Nick Coghlan offered "simplifying cross-version maintenance". (He also mentioned "addressing issues that arise due to changes in the underlying platforms", which is another issue I will open.) Because of PEP 434 and the subsequent application of most Idle patches to all current versions, cross-version consistency is even more important for idlelib than the rest of the repository. When backporting patches, both context and changed lines must match. My experience so far is that merge conflicts are normal. So I think the latitude for consistency patches to reduce these should be even wider than for the rest of the repository. On the other hand, the current lack of tests suggests more caution than for the rest of the repository. For this issue, I would like to at least change "except exception, e:" to "except exception as e:". This is about as safe as anything, and grepping 2.7 idlelib for "except .*, *." yields 23 hits where the ',' is not for multiple exceptions. 2.7 has about 80 print statements. While I would not change all in one patch (maybe 4), all in any file should be changed together when the future import is added at the top. Once this is done, forgetting to add parens or convert '>> file' results in a SyntaxError. So this is also pretty safe if the file compiles. Current uses of int() seem to be for str or float conversion, not a/b truncations. That is already done with a//b. There do not seem to be any unicode string literals. Have I forgotten any generic ways to make 2.7 code the same as 3.x? ---------- files: differ23.py messages: 191961 nosy: ncoghlan, roger.serwy, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle 2.7: update to simply cross-version patches versions: Python 2.7 Added file: http://bugs.python.org/file30714/differ23.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 28 00:01:26 2013 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 27 Jun 2013 22:01:26 +0000 Subject: [New-bugs-announce] [issue18317] gettext: DoS via crafted Plural-Forms Message-ID: <1372370486.3.0.302841036863.issue18317@psf.upfronthosting.co.za> New submission from Jakub Wilk: It is possible to craft a MO file with Plural-Forms taking arbitrary amounts of CPU and memory to evaluate. A test case is attached. I realize that opening unstrusted MO files is a rather unusual use case, but the module already contains some code to protect againt malicious Plural-Forms, so I thought you might want to fix this problem as well. ---------- components: Library (Lib) files: testcase.mo messages: 191963 nosy: jwilk priority: normal severity: normal status: open title: gettext: DoS via crafted Plural-Forms type: security Added file: http://bugs.python.org/file30715/testcase.mo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 28 00:43:29 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 27 Jun 2013 22:43:29 +0000 Subject: [New-bugs-announce] [issue18318] Idle: stop depending on console output Message-ID: <1372373009.47.0.618602359328.issue18318@psf.upfronthosting.co.za> New submission from Terry J. Reedy: It appears that Idle was originally written to run on *nix after being launched from a command-line console. Messages related to Idle code (warnings and exceptions) are sent back to the console, while messages related to user code go to the shell window. This makes Idle a hybrid text/gui application. Later, Idle was ported to run on Windows with the pythonw.exe no-console binary. When it is started normally for Windows, from anything but a console, there is no console. This has caused problems when Idle tries to write to the non-existent console. (I do not know the situation on modern Mac and *nix.) (Even when a console does exist, it will usually get buried and messages may not be seen.) Example: The warning system, monkey patched in both PyShell.py and run.py and documented in the former. (Edited quote from 3.3.) # Override warnings module to write to warning_stream. # Initialize to send IDLE internal warnings to the console. # ScriptBinding.check_syntax() will temporarily redirect the stream # to the shell window to display warnings when checking user's code. warning_stream = sys.__stderr__ # Typically None, at least on Windows. def idle_showwarning(... ... if file is None: file = warning_stream # Which may itself be None!!! try: file.write(... # AttributeError when file is still None except OSError: pass # if file (probably __stderr__) is invalid, skip warning. The patch for #18081 also catches AttributeError as a bandage. Issue goal: make Idle a true gui app by removing the dependence on a console, which may not exist. Proposed method: re-factor Idle startup to try to import tkinter first, rather than last. If this import fails, inform user with console message and/or the os-specific means to gui apps to tell users 'I cannot start because ...'. I know this exists on Windows because I have seen such messages. I presume same is true on other systems. If this import succeeds, setup traceback and warnings hooks to send internal messages to a gui messagebox rather than (or possibly in addition to) a console that may or may not be present. Or send the messages to the Shell window, but marked somehow as internal. The warnings hook might be used after importing non-Idle modules but before importing Idle modules, so startup is not bogged down on debug builds by DeprecationWarnings from non-Idle modules To be a good citizen for testing, all custom hooks should be undone before the PyShell import finishes and before PyShell.main exits (same for run.py). ---------- messages: 191966 nosy: ned.deily, roger.serwy, terry.reedy priority: normal severity: normal status: open title: Idle: stop depending on console output type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 28 00:53:23 2013 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 27 Jun 2013 22:53:23 +0000 Subject: [New-bugs-announce] [issue18319] gettext() cannot find translations with plural forms Message-ID: <1372373603.42.0.596981858746.issue18319@psf.upfronthosting.co.za> New submission from Jakub Wilk: gettext() cannot find translations for messages that have plural forms. I would expect that gettext(s) is equivalent to ngettext(s, s, 1) for such messages, as it is implemented in GNU gettext. >>> import gettext >>> with open('test.mo', 'rb') as mo: trans = gettext.GNUTranslations(mo) ... >>> trans.ngettext("egg", "eggs", 1) 'Ei' >>> trans.gettext("egg") 'egg' ---------- components: Library (Lib) files: test.mo messages: 191967 nosy: jwilk priority: normal severity: normal status: open title: gettext() cannot find translations with plural forms Added file: http://bugs.python.org/file30717/test.mo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 28 09:28:59 2013 From: report at bugs.python.org (cosmicduck) Date: Fri, 28 Jun 2013 07:28:59 +0000 Subject: [New-bugs-announce] [issue18320] idle, pydoc search python on wrong path at make altinstall with different exec- and prefix e.g. $HOME Message-ID: <1372404539.33.0.335439360663.issue18320@psf.upfronthosting.co.za> New submission from cosmicduck: Using Solaris 10 x86 Compiling actual 3.3.2 or 2.7.5 looks like work. Installing as non-root with make altinstall prefix='${HOME}/scripts/tools/python/python-3.3.2' exec-prefix='${HOME}/scripts/tools/python/python-3.3.2' installs looks like correctly to the target. Extends LD_LIBRARYPATH and PATH to ${HOME}/scripts/tools/python/python-3.3.2/lib and ${HOME}/scripts/tools/python/python-3.3.2/bin has been done. Python is started correctly with python3.3. If I start idle3.3 or pydoc3.3 I get error: /usr/local/bin/python3.3: bad interpreter: No such file or directory. So it looks like the she-bang is not correctly set for shell scripts to the path prefix and exec-prefix path. Correcting that by manually setup to ${HOME}/scripts/tools/python/python-3.3.2/bin fix that problem. But I guess it's better to modify the installation process by make to have not future problems. ---------- components: IDLE messages: 191977 nosy: cosmicduck priority: normal severity: normal status: open title: idle, pydoc search python on wrong path at make altinstall with different exec- and prefix e.g. $HOME versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 28 10:06:17 2013 From: report at bugs.python.org (Eduardo Robles Elvira) Date: Fri, 28 Jun 2013 08:06:17 +0000 Subject: [New-bugs-announce] [issue18321] Multivolume support in tarfile module Message-ID: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> New submission from Eduardo Robles Elvira: The patch attached provides implementation for multivolume support for tarfile module. It contains both the changes in the module and a battery of unit tests. It contains support for multivolume for both GNU and PAX formats. The main idea behind this proposal is that for dealing with new volumes, the user will provide a callback function. In this callback function the user typically calls to TarFile.open_volume(filename) with the appropiate filename. This is quite flexible in the sense that the callback function could even ask the user for the filename of the next volume (as tar command does), or do anything they need before returning or before calling to open_volume. Please feel free to comment on how to improve the implementation or the API. Documentation for the new feature will be provided at a later stage of the review process if the patch gets a good review. ---------- components: Library (Lib) files: cpython-tarfile-multivolume.patch keywords: patch messages: 191979 nosy: edulix priority: normal severity: normal status: open title: Multivolume support in tarfile module versions: Python 3.4 Added file: http://bugs.python.org/file30720/cpython-tarfile-multivolume.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 28 11:54:55 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 28 Jun 2013 09:54:55 +0000 Subject: [New-bugs-announce] [issue18322] test_stat nits Message-ID: <1372413295.3.0.80971149549.issue18322@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Patch with small fixes and improvements to test_stat. ---------- assignee: christian.heimes components: Tests files: test_stat.patch keywords: patch messages: 191985 nosy: christian.heimes, pitrou priority: normal severity: normal stage: patch review status: open title: test_stat nits type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file30723/test_stat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 28 13:26:57 2013 From: report at bugs.python.org (Laurent Gautier) Date: Fri, 28 Jun 2013 11:26:57 +0000 Subject: [New-bugs-announce] [issue18323] 'GzipFile' object has no attribute 'extrastart' Message-ID: <1372418817.06.0.791452748439.issue18323@psf.upfronthosting.co.za> New submission from Laurent Gautier: When creating a `gzip.GzipFile` using the named parameter `fileobj` rather than filename, iterating over it is broken: ``` AttributeError: 'GzipFile' object has no attribute 'extrastart' ``` The short example below is demonstrating the problem: ## --- import gzip, tempfile _data = (b'@WXOVW:25:85', b'ATACGCGGCT'+b'GATCGTAGCG', b'+', b'@@))CCCCBB'+b'???ECCEECC') data = gzip.zlib.compress(b'\n'.join(_data)) foo = tempfile.NamedTemporaryFile() foo.write(data) foo.flush() foo.seek(0) gzf = gzip.GzipFile(fileobj=foo) # this will trigger the AttributeError for x in gzf: print(x) ---------- components: Library (Lib) messages: 191989 nosy: Laurent.Gautier priority: normal severity: normal status: open title: 'GzipFile' object has no attribute 'extrastart' type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 28 21:16:22 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 28 Jun 2013 19:16:22 +0000 Subject: [New-bugs-announce] [issue18324] set_payload does not handle binary payloads correctly Message-ID: <1372446982.29.0.852040030503.issue18324@psf.upfronthosting.co.za> New submission from R. David Murray: In order to maintain model consistency without exposing the need for 'surrogateescape' to library users, it should be possible to pass binary data to set_payload and have it do the correct conversion to the expected storage format for the model. Currently, this does not work. The attached patch provides one example test out of a class of tests that should be written and made to pass. ---------- components: email files: set_qp_payload_test.patch keywords: easy, patch messages: 192012 nosy: barry, r.david.murray priority: normal severity: normal stage: test needed status: open title: set_payload does not handle binary payloads correctly type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30726/set_qp_payload_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 28 22:50:16 2013 From: report at bugs.python.org (Federico Schwindt) Date: Fri, 28 Jun 2013 20:50:16 +0000 Subject: [New-bugs-announce] [issue18325] test_kqueue fails in OpenBSD Message-ID: <1372452616.96.0.640334462237.issue18325@psf.upfronthosting.co.za> New submission from Federico Schwindt: test_kqueue fails in OpenBSD/amd64 -current: Traceback (most recent call last): File "/usr/obj/pobj/Python-3.3.2/Python-3.3.2/Lib/test/test_kqueue.py", line 79, in test_create_event ev = select.kevent(bignum, 1, 2, 3, sys.maxsize, bignum) OverflowError: signed integer is greater than maximum In OpenBSD, ident is an unsigned integer data is a signed integer. See http://bugs.python.org/issue12181 for details. ---------- components: Tests messages: 192018 nosy: Federico.Schwindt, neologix priority: normal severity: normal status: open title: test_kqueue fails in OpenBSD versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 29 15:05:36 2013 From: report at bugs.python.org (icedream91) Date: Sat, 29 Jun 2013 13:05:36 +0000 Subject: [New-bugs-announce] [issue18326] Not Clear Docs Message-ID: <1372511136.61.0.278425078947.issue18326@psf.upfronthosting.co.za> New submission from icedream91: I think the documents talking about list.sort() in page http://docs.python.org/3/library/stdtypes.html#list.sort is not clear enough. What asterisk means in "sort(*, key=None, reverse=None)", may be cmp argument from Python 2, or anything else? Or it is a typo? I think document should explain what this asterisk means. Thanks. ---------- assignee: docs at python components: Documentation messages: 192034 nosy: docs at python, icedream91 priority: normal severity: normal status: open title: Not Clear Docs versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 29 21:08:45 2013 From: report at bugs.python.org (Christian Heimes) Date: Sat, 29 Jun 2013 19:08:45 +0000 Subject: [New-bugs-announce] [issue18327] swapped arguments in compatible_for_assignment()? Message-ID: <1372532925.38.0.271653772611.issue18327@psf.upfronthosting.co.za> New submission from Christian Heimes: Coverity has found something fishy in our code base: CID 983564 (#1 of 1): Arguments in wrong order (SWAPPED_ARGUMENTS)swapped_arguments: The positions of arguments newto and oldto are inconsistent with the positions of the corresponding parameters for "compatible_for_assignment(PyTypeObject *, PyTypeObject *, char *)". Object/typeobject.c:3326 if (compatible_for_assignment(newto, oldto, "__class__")) { Objects/typeobject.c.3265 static int compatible_for_assignment(PyTypeObject* oldto, PyTypeObject* newto, char* attr) ---------- components: Interpreter Core messages: 192042 nosy: christian.heimes priority: normal severity: normal stage: test needed status: open title: swapped arguments in compatible_for_assignment()? type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 29 21:53:37 2013 From: report at bugs.python.org (Christian Heimes) Date: Sat, 29 Jun 2013 19:53:37 +0000 Subject: [New-bugs-announce] [issue18328] Use after free in pystate.c Message-ID: <1372535617.95.0.680763936377.issue18328@psf.upfronthosting.co.za> New submission from Christian Heimes: Coverity doesn't like the code in and I think it's right. Can somebody look into the matter and check Python 3.3, too? http://hg.python.org/cpython/file/ac7bc6700ac3/Python/pystate.c#l376 http://hg.python.org/cpython/file/ac7bc6700ac3/Python/pystate.c#l394 10. freed_arg: "tstate_delete_common(PyThreadState *)" frees "tstate". 395 tstate_delete_common(tstate); 11. Condition "autoInterpreterState", taking true branch CID 1019639 (#1 of 1): Use after free (USE_AFTER_FREE)12. use_after_free: Using freed pointer "tstate". 396 if (autoInterpreterState && PyThread_get_key_value(autoTLSkey) == tstate) 397 PyThread_delete_key_value(autoTLSkey); ---------- components: Interpreter Core messages: 192043 nosy: christian.heimes priority: normal severity: normal stage: test needed status: open title: Use after free in pystate.c type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 29 23:25:58 2013 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 29 Jun 2013 21:25:58 +0000 Subject: [New-bugs-announce] [issue18329] for line in socket.makefile() speed degradation Message-ID: <1372541158.63.0.507892499267.issue18329@psf.upfronthosting.co.za> New submission from ???? ?????????: Results or running attached program: $ python2.7 qwe.py TCP mode, makefile method. 198807.2 lines per second (189.6 MB/s). Delay is 5.03 seconds TCP mode, fdopen method. 1041666.7 lines per second (993.4 MB/s). Delay is 0.96 seconds UNIX mode, makefile method. 2040816.3 lines per second (1946.3 MB/s). Delay is 0.49 seconds UNIX mode, fdopen method. 1923076.9 lines per second (1834.0 MB/s). Delay is 0.52 seconds $ python3.2 qwe.py TCP mode, makefile method. 275482.1 lines per second (262.7 MB/s). Delay is 3.63 seconds TCP mode, fdopen method. 909090.9 lines per second (867.0 MB/s). Delay is 1.10 seconds UNIX mode, makefile method. 323624.6 lines per second (308.6 MB/s). Delay is 3.09 seconds UNIX mode, fdopen method. 1694915.3 lines per second (1616.4 MB/s). Delay is 0.59 seconds ---------------------------------------------- 1. in every case, socket.makefile() is MUCH slower than os.fdopen() when used as "for line in fileobject" 2. compare speeds between python 2.7 and python 3.2 in same operation. Especially, socketpair+makefile 3. Why not to return os.fdopen() for sockets when socket.makefile() called on unix systems? ---------- components: IO, Library (Lib) files: qwe.py messages: 192044 nosy: mmarkk priority: normal severity: normal status: open title: for line in socket.makefile() speed degradation type: performance versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file30731/qwe.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 30 00:09:24 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 29 Jun 2013 22:09:24 +0000 Subject: [New-bugs-announce] [issue18330] Fix idlelib.PyShell.build_subprocess_arglist use of __import__ Message-ID: <1372543764.27.0.834894616208.issue18330@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The purpose of the function is to create a command line for the user subprocess. Most of its body: ''' # Maybe IDLE is installed and is being accessed via sys.path, # or maybe it's not installed and the idle.py script is being # run from the IDLE source directory. del_exitf = idleConf.GetOption('main', 'General', 'delete-exitfunc', default=False, type='bool') if __name__ == 'idlelib.PyShell': command = "__import__('idlelib.run').run.main(%r)" % (del_exitf,) else: command = "__import__('run').main(%r)" % (del_exitf,) return [sys.executable] + w + ["-c", command, str(self.port)] ''' Question: is it really important to avoid binding the run module to 'run' in the user process? If so, maybe we should use importlib.import_module, as 'direct use of __import__ is entirely discouraged". The first command looks 'funny' because of the repetition of 'run'. The reason is that __import__('idlelib.run') returns idlelib, not idlelib.run. Perhaps it would work to delete .run in the import, or to use importlib.import_module. The second command incorrectly assumes that if __name__ == '__main__' (the alternative to 'idlelib.PyShell'), then the directory containing PyShell and run is the current working directory. This is true if PyShell is run from that directory, but F:\Python\dev\py33\PCbuild>python_d -m idlelib.PyShell F:\Python\dev\py33\PCbuild>python_d ../Lib/idlelib/PyShell.py both report "ImportError: No module named 'run'" and open a shell window and error message box a few seconds later. The shell closes when the messagebox is dismissed. It seems to me that the 'else' caters to a non-existent or impossible use case. PyShell has several 'from idlelib.X import Y' statements. If those work, then "from idlelib import run' must work, and so too must the function equivalent. ---------- messages: 192053 nosy: roger.serwy, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Fix idlelib.PyShell.build_subprocess_arglist use of __import__ type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 30 16:33:02 2013 From: report at bugs.python.org (Drekin) Date: Sun, 30 Jun 2013 14:33:02 +0000 Subject: [New-bugs-announce] [issue18331] runpy.run_path gives functions with corrupted .__globals__ Message-ID: <1372602782.77.0.618152195123.issue18331@psf.upfronthosting.co.za> New submission from Drekin: Let's have a simple script test.py: def f(): return x x = 2 print(f()) Now if we try to run it via runpy.run_path, we get the following: >>> import runpy >>> g = runpy.run_path("test.py") 2 >>> g["f"]() is None True >>> g["x"] is 2 True >>> g["f"].__globals__["x"] is None True Is the behaviour of f.__globals__ after return from run_path intended and why? ---------- components: Library (Lib) messages: 192072 nosy: Drekin priority: normal severity: normal status: open title: runpy.run_path gives functions with corrupted .__globals__ type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 30 18:47:57 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Jun 2013 16:47:57 +0000 Subject: [New-bugs-announce] [issue18332] _posix_listdir may leak FD Message-ID: <1372610877.27.0.117914198257.issue18332@psf.upfronthosting.co.za> New submission from Christian Heimes: Under rare circumstances listdir() could leak a FD: - HAVE_FDOPENDIR is defined - dup(fd) succeeds - fdopendir() fails and sets dirp to NULL - if (dirp == NULL) goto exit - the dupped fd isn't closed because exit just handles dirp != NULL. Proposed fix: if (dirp != NULL) { ... } else if (fd != -1) { close(fd); } CID 992693 (#1 of 1): Resource leak (RESOURCE_LEAK) leaked_handle: Handle variable "fd" going out of scope leaks the handle ---------- components: Extension Modules messages: 192077 nosy: christian.heimes priority: normal severity: normal stage: needs patch status: open title: _posix_listdir may leak FD type: resource usage versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 30 19:00:56 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Jun 2013 17:00:56 +0000 Subject: [New-bugs-announce] [issue18333] Memory leak in _pickle.c:Unpickler_set_memo() Message-ID: <1372611656.54.0.917364518453.issue18333@psf.upfronthosting.co.za> New submission from Christian Heimes: Unpickler_set_memo() has a memory leak when it is called with an empty dictionariy as argument - PyDict_Check(obj) is true - PyDict_Size(obj) returns 0 - _Unpickler_NewMemo(new_memo_size) calls PyMem_MALLOC(0) - PyMem_MALLOC(0) returns a valid pointer although 0 bytes have been requested - later on an error occurs: goto exit - because new_memo_size == 0, PyMem_FREE(new_memo) is never executed CID 983308 (#1 of 1): Resource leak (RESOURCE_LEAK) leaked_storage: Variable "new_memo" going out of scope leaks the storage it points to. ---------- components: Extension Modules messages: 192079 nosy: christian.heimes priority: normal severity: normal stage: needs patch status: open title: Memory leak in _pickle.c:Unpickler_set_memo() type: resource usage versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________